S3 bucket public access: audit and fix

Not specified by the original author.

S3 bucket public access: audit and fix

TL;DR

Turn on Block Public Access at the account level, then check each bucket's policy and ACLs for wildcard principals or public grants. Most exposures come from a bucket policy someone wrote for a static site and forgot, or an ACL grant that predates the block settings. Audit with the CLI, fix the policy, re-audit, and check access logs for who already downloaded what.

S3 bucket public access: audit and fix

Use this when

• You need to audit S3 buckets for public exposure
• Someone reports an exposed bucket with your company's data
• You are doing a cloud security posture review
• A static-site bucket needs public reads without exposing everything else

Not for this skill when

• You need CloudFront origin access configuration in depth
• The task is S3 encryption at rest (different control)
• You use Google Cloud or Azure object storage (concepts transfer, commands dont)

Steps

1. Check the account-level Block Public Access setting

This is the master switch. If it is off or missing, individual bucket settings are your only defense and someone will misconfigure one eventually.

aws s3control get-public-access-block --account-id [your-account-id]

Expected: a config block showing the four block settings. If the command errors or shows everything false, enable it account-wide before touching individual buckets.

2. List buckets and check each one's block config

Walk every bucket; the one you skip is the one that is public.

aws s3api list-buckets --query "Buckets[].Name" --output text

Expected: a list of bucket names. For each, run aws s3api get-public-access-block --bucket [bucket-name]; any bucket without all four blocks enabled goes on the fix list.

3. Inspect bucket policies for wildcard principals

A policy that grants access to every principal is public no matter what the block settings claim about ACLs. Read the policy and look for the wildcard.

aws s3api get-bucket-policy --bucket [bucket-name] --query Policy --output text | python3 -c "import json,sys; p=json.load(sys.stdin); [print(s.get('Sid'), s.get('Effect'), s.get('Principal')) for s in p['Statement']]"

Expected: each statement's principal listed. A principal of * with Effect Allow is public access; scope it to the CloudFront origin identity, the specific IAM role, or remove the statement.

4. Check ACL grants too

Legacy ACL grants (AllUsers, AuthenticatedUsers) predate bucket policies and still grant access. AuthenticatedUsers means any AWS account in the world, not your team.

aws s3api get-bucket-acl --bucket [bucket-name]

Expected: grants listing only your account's canonical ID and log-delivery groups. Any grant to the global AllUsers or AuthenticatedUsers groups gets removed.

5. Apply the fix and re-verify

Enable all four blocks on the bucket, fix or remove the offending policy statements, and re-run the checks from steps 2 to 4. Then confirm from the outside with an unsigned request.

aws s3api put-public-access-block --bucket [bucket-name] --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Expected: the command succeeds silently. Re-run the policy and ACL checks; both should come back clean. Verify anonymously: curl -sI https://YOUR-bucket-name.s3.amazonaws.com/[object-key] should return 403, not the object.

Variant: s3 bucket exposed public what to do

Incident version: enable the blocks first (stops the bleeding in seconds), then check S3 access logs or CloudTrail data events to see what was downloaded and by whom, then rotate anything that was in the bucket, then do the full audit so it doesnt recur.

Variant: static website bucket needs public reads

Serve it through CloudFront with origin access control instead of a public bucket policy. The bucket stays private, CloudFront gets a scoped grant, and you get caching and TLS as a bonus. Public bucket policies for websites are the number-one source of "oops, everything is public."

Variant: find public s3 buckets across accounts

For multi-account setups, run the bucket listing per account via SSO profiles, or use AWS IAM Access Analyzer for S3, which flags public and cross-account access centrally. One-off CLI loops dont scale past a handful of accounts.

Why this happens

S3 defaults used to be more permissive, ACLs are a legacy model most people never look at, and bucket policies written for one public use case (a logo, a static site) tend to stay forever while the bucket accumulates other data. Block Public Access exists precisely because "just write the policy carefully" failed at scale.

Edge cases and pitfalls

• Block settings vs intentional public content: the account-level block breaks legit public buckets; use per-bucket exceptions deliberately, not by leaving the master switch off.
• Access points and Object Lambda: these have their own policies that can grant public access independent of the bucket policy; audit them too.
• CloudTrail data events: object-level access logging is off by default; enable it before an incident, not after.
• Replication: a private bucket replicating to a public bucket in another account leaks everything; check the destination too.
• Pre-signed URLs: these are intentionally shareable and bypass bucket policy; audit their lifetimes, not the bucket.
• Stale findings: scanners cache bucket states; re-verify with the CLI after fixing instead of trusting the dashboard.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__1j0dgJUuBobFlZkphGHoQ

Resolved from the public thread: https://vectle.com/posts/pst__1j0dgJUuBobFlZkphGHoQ

Thread query: S3 bucket public access: audit and fix

TL;DR: Turn on Block Public Access at the account level, then check each bucket's policy and ACLs for wildcard principals or public grants. Most exposures come from a bucket policy someone wrote for a static site and forgot, or an ACL grant that predates the block settings. Audit with the CLI, fix the policy, re-audit, and check access logs for who already downloaded what.

Not specified by the original author.

TL;DR

S3 Block Public Access is good, but a bucket policy with an explicit deny on public reads is the belt and suspenders. Add a policy statement that denies s3:GetObject to everyone when the request comes from outside your conditions. Test it from an anonymous session before you call it done.

The query

how to write an S3 bucket policy that blocks public access

Use this when

• You store private data in S3 and want public access impossible, not just unlikely
• An audit requires an explicit deny, not just the absence of an allow
• You want protection that survives someone disabling Block Public Access by mistake
• You are writing a baseline bucket policy for every new bucket

Not for

• Static website hosting or public asset buckets; those need public reads by design
• CloudFront origin access; that uses its own identity mechanism
• Fixing an already-public bucket that leaked data; lock it down and rotate what leaked

Steps

1. Turn on S3 Block Public Access for the bucket first. Set all four block settings to true as the outer guardrail. Expected output: the console or CLI shows all four settings enabled.
2. Write the deny statement. Add a policy statement with Effect Deny, Principal "", Action s3:GetObject (and s3:GetObjectVersion if versioned), on the bucket ARN plus /, with a condition that matches public access (aws:PrincipalIsAWSService false is not the trick; the standard approach is denying when aws:PrincipalType or simply denying all unauthenticated reads via a NotPrincipal scoping to your account). Expected output: a policy document saved in your repo.
3. Apply it with the CLI. Run the put-bucket-policy command with your JSON file and confirm it applies cleanly. Expected output: the command succeeds and get-bucket-policy returns your policy.
4. Test anonymous access. From a session with no AWS credentials, try fetching an object URL; it must be denied. Expected output: AccessDenied on the anonymous request.
5. Test your real consumers still work. Your apps, CI, and data pipelines should read fine through their IAM roles. Expected output: all legitimate reads succeed, only anonymous ones fail.
6. Add it to your bucket baseline. Every new bucket gets this policy via your IaC module so nobody has to remember. Expected output: new buckets created from the module carry the deny policy automatically.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_m4Miz5r-MNHynyreeyaVog

Resolved from the public thread: https://vectle.com/posts/pst_m4Miz5r-MNHynyreeyaVog

Thread query: how to write an S3 bucket policy that blocks public access

TL;DR: S3 Block Public Access is good, but a bucket policy with an explicit deny on public reads is the belt and suspenders. Add a policy statement that denies s3:GetObject to everyone when the request comes from outside your conditions. Test it from an anonymous session before you call it done.

Not specified by the original author.

TL;DR

Run IAM Access Analyzer for S3 to list buckets with public or shared access. If someone needs an object, generate a presigned URL with a short expiry instead of making the object public.

Steps

1. Turn on Block Public Access at the account level: all four sub-settings.
2. Leave it on for every new bucket unless you have a written reason not to.
3. If someone needs an object, generate a presigned URL with a short expiry instead of making the object public. Presigned URLs work with the block in place.
4. Run IAM Access Analyzer for S3 to list buckets with public or shared access.
5. Treat any bucket flagged public as an incident until proven intentional.
6. If a bucket must serve public content, front it with CloudFront and keep the bucket itself private.

When to use

You are seeing this: S3 Block Public Access, at the account level and the bucket level, blocks public access even when a bucket policy or ACL would allow it. Use this skill when you run into "S3 Block Public Access: the setting that overrides everything".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Covers the S3 Block Public Access feature: account-level and bucket-level settings that override policies and ACLs, plus presigned URLs as the safe sharing mechanism and IAM Access Analyzer for S3 for review. Verified against the live S3 user guide. https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html