S3 PutBucketPolicy Ignores Block Public Access State

The Trap

PutBucketPolicy accepts a resource policy with "Principal": "*" and no scoping conditions regardless of the bucket’s or account’s Block Public Access configuration. S3 only enforces BlockPublicPolicy, IgnorePublicAcls, BlockPublicAcls and RestrictPublicBuckets at data-plane request time, on GetObject, ListBucket and similar calls. The write path is entirely separate from the enforcement path, so a dangerous policy can sit committed and inert for months.

The Default State

Buckets created through the S3 console since 2023 get all four BPA flags set to true automatically. Buckets provisioned through CloudFormation, Terraform or the CLI without an explicit aws_s3_bucket_public_access_block resource, or an equivalent PutPublicAccessBlock call, inherit only whatever the account-level setting provides. Many accounts migrated before the account-level default existed, or had it disabled during a one-off migration and never re-enabled it. Engineers writing the wildcard policy see the PutBucketPolicy call succeed and assume the platform would have rejected an unsafe configuration if one existed.

The Blast Radius

Detection tooling built around CloudTrail alerts on PutBucketPolicy events misses the actual exposure entirely, because the triggering action is a later PutAccountPublicAccessBlock or per-bucket BPA change, not a policy write. The moment account-level BPA is disabled, every wildcard policy already resting in the account activates simultaneously across every affected bucket, with no corresponding policy-change event that day. Static analysis run at deploy time reports the bucket as compliant, since BPA was enabled during the scan, and nobody re-scans after unrelated account-level toggles.

The Lead Mechanic Fix

Treat account-level BPA as a locked control-plane setting rather than a per-project toggle. Apply it explicitly with aws s3control put-public-access-block --account-id ACCOUNT_ID --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true, then deny s3:PutAccountPublicAccessBlock and s3:PutBucketPublicAccessBlock in a Service Control Policy scoped to everyone except a named break-glass role. Because SCPs cannot inspect the content of a resource policy document, pair this with continuous evaluation from IAM Access Analyzer for S3, which flags external access based on actual policy effect at any time, not just at write time, closing the gap that PutBucketPolicy leaves open.