S3 Block Public Access Silently Overrides an Explicit Bucket Policy Grant

Symptom

A caller that should have access under an explicit Amazon S3 bucket policy statement receives an Access Denied response, even though the policy document was accepted without a syntax or validation error when it was saved.

The pattern is easy to misdiagnose: the statement is present, the principal is named correctly, the action and resource ARNs match, and the console or CLI reported no error when the policy was applied. Engineers re-check the JSON, rewrite the statement, and still see the same denial, because the policy document is not the only control deciding the outcome.

False Assumption

The failure is caused by treating a successfully saved bucket policy as proof that the granted access is actually in effect.

Amazon S3’s policy editor and the put-bucket-policy API validate that a policy is well-formed JSON and grammatically valid IAM policy syntax. Neither check confirms that the resulting access will be permitted once every other control in the account is evaluated. Teams that treat a successful save as equivalent to working access skip the step that actually explains most denials against an apparently correct policy.

Root Cause

Amazon S3 Block Public Access settings, applied at the account level, the bucket level, or both, can silently negate a bucket policy statement that grants public or broad access, without generating any error on the policy itself.

Block Public Access is evaluated independently of the policy document. A statement can be syntactically valid and logically consistent with the intended grant, while one or more Block Public Access flags (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) suppress the access at request time. Because these settings live outside the policy document, a reviewer reading only the bucket policy has no visual indication that the grant is being overridden elsewhere. This account/bucket-level interaction sits within the access evaluation model AWS documents in its general security guidance; the exact flag-by-flag behaviour for a given account should be re-confirmed against the current dedicated AWS Block Public Access reference before this root cause is treated as final, since the verified source used here covers the Well-Architected Security Pillar generally rather than that specific reference page.

Impact

The immediate impact is wasted diagnostic effort: engineers repeatedly edit a bucket policy that was never the actual blocker, while the real control sits on a separate, easily overlooked configuration surface.

Downstream effects include delayed data pipeline runs, blocked cross-account integrations, and failed automation that depends on timely S3 access. There is a second, more serious impact in the opposite direction: if an engineer resolves the denial by disabling Block Public Access broadly, rather than correcting the actual scope mismatch, every bucket that relied on that account-level control becomes exposed at the same time, not only the one bucket under investigation.

Diagnosis

Diagnosis is a read-only comparison between what the bucket policy grants and what Block Public Access currently permits, before any file is edited.

1. Retrieve the bucket-level Block Public Access configuration with get-public-access-block.
2. Retrieve the account-level Block Public Access configuration for the account that owns the bucket.
3. Retrieve the current bucket policy status with get-bucket-policy-status to see whether S3 currently treats the bucket as public.
4. Save a timestamped copy of the current bucket policy document before making any change, so the exact prior state can be restored.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowReadForPartnerAccount", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:root"}, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/shared/*" } ] }

This statement is syntactically correct and looks sufficient on its own. If RestrictPublicBuckets or an equivalent account-level control is enabled and the sharing pattern falls inside its scope, requests from the named partner account can still be denied, and the policy document gives no indication why.

Correction

The correction is to reconcile the Block Public Access baseline with the intended access before touching the bucket policy again, rather than continuing to edit the policy statement.

1. Confirm with the data owner what access the bucket is actually meant to allow, and to which principals.
2. Compare that intent against the retrieved bucket-level and account-level Block Public Access settings.
3. Where the mismatch concerns a single bucket needing broader access, adjust the bucket-level Block Public Access setting for that bucket only; avoid changing the account-level setting for a single-bucket fix.
4. Apply the reviewed, corrected bucket policy with put-bucket-policy, using the previously saved backup file as the rollback reference.

Validation

Validation confirms that only the intended principals now succeed and every other principal still receives a denial.

• Re-run get-bucket-policy-status and confirm the reported public state matches the agreed intent.
• Test the specific read or write operation as the intended principal in a non-production context and confirm a success response.
• Test the same operation as a principal that should remain excluded and confirm it still receives a denial.
• Review AWS IAM Access Analyzer for S3 findings for the bucket and confirm no unresolved public or cross-account finding remains outside the approved scope.

Rollback

Rollback restores the exact bucket policy and Block Public Access configuration captured during diagnosis, and is available at every stage of the correction.

If validation fails, or if any unintended principal gains access, restore the bucket policy from the saved backup file with put-bucket-policy, and restore the prior Block Public Access configuration values with put-public-access-block. Re-run the validation checks immediately after rollback to confirm the environment matches its state before the change began. Treat an account-level Block Public Access change as requiring a second approver and a documented rollback owner, given the number of buckets a single account-level setting affects.

Prevention

Prevent recurrence by making Block Public Access state visible alongside every bucket policy review, rather than reviewing the policy document in isolation.

• Record the intended Block Public Access baseline for each bucket alongside its policy, so future reviewers see both controls together.
• Route bucket policy changes and Block Public Access changes through the same change process, with account-level settings requiring an explicit, separate approval.
• Add a scheduled or event-driven check of IAM Access Analyzer for S3 findings so an unintended public or cross-account grant is flagged before it is reported as a denial or, worse, an exposure.
• Treat any request to disable Block Public Access outright as a signal to re-open the diagnosis, not as an approved fix.