7 S3 Bucket Exposure Prevention Controls That Work

S3 bucket exposure prevention is a layered problem: one switch stops most leaks, and layered detection catches the rest. Amazon S3 Block Public Access is that switch. It overrides ACLs, bucket policies, and access point policies, so public grants are rejected even when someone writes them on purpose. AWS recommends turning on all four Block Public Access settings for the account and for every bucket, and S3 always enforces the most restrictive combination across levels. That combination rule does quiet work: an organization-level policy protects every member account even when a local administrator relaxes local settings, and bucket-level settings still apply when the account baseline is weaker. Treat bucket controls as a first-week item in any cloud security baseline for your first 90 days, not a cleanup project for later.

Why buckets still leak

The mechanism of exposure has barely changed in a decade: a bucket policy with a wildcard principal, a legacy ACL granting the AllUsers group, or an access point that re-exposes a locked-down bucket. What changed is the default posture. New S3 buckets have not been public by default since 2023, but the installed base of older buckets kept whatever permissions were configured before that switch. Estate-wide sweeps keep finding that installed base. One research sweep reported 847 misconfigured AWS S3 buckets across organizations in 43 countries, exposing more than 2.1 billion records.

Misconfigurations also arrive through pipelines rather than consoles. Infrastructure-as-code templates with permissive defaults get copied between environments, staging buckets promoted to production inherit relaxed policies, and vendor onboarding grants routinely exceed what the integration needs. That is why prevention belongs at the account layer, where a template cannot opt out, and why detection must assume the bucket layer will drift.

The four blocking settings

Block Public Access is four independent switches, and each closes a different path to public data. At the organization level they apply as one unified policy; at account and bucket level you can combine them as needed.

Two properties make this group genuine prevention instead of audit. The settings block future public grants, not just report on existing ones, and the strictest setting in force wins regardless of which layer it came from. Existing policies and ACLs are left in place, which lets you harden an estate without breaking workloads mid-flight — audit first, then clean up the leftovers.

Seven controls, in order

1. Enable all four settings at the account level. One configuration covers current and future buckets and access points in every Region, so nothing created later slips past it.
2. Enforce at organization level where possible. Member accounts then inherit the policy and cannot relax account-level settings, which removes per-team exceptions entirely.
3. Apply bucket-level settings anyway. Bucket settings keep protecting the resource even when account context is weaker, and all-four-buckets satisfies Security Hub Foundational Security Best Practices control S3.8.
4. Deny tampering in IAM. A bucket policy can grant someone permission to turn blocking off, so put a Service Control Policy or permissions boundary in front of s3:PutAccountPublicAccessBlock and s3:PutBucketPublicAccessBlock.
5. Turn on server access logging and CloudTrail data events. Without object-level trails you cannot reconstruct who read a bucket during an incident — this is Security Hub control S3.9 territory, and the logging bucket needs its own care.
6. Verify continuously with your own credentials. IAM Access Analyzer for S3 flags public and shared buckets, and AWS Config rules alert when a bucket drifts from the expected posture; point-in-time console reviews are not a control.
7. Retire ACLs. With object ownership set to bucket owner enforced, ACLs stop being an exposure path and IAM becomes the only permission model you audit.

Where blocking falls short

Block Public Access closes public paths; it does nothing about authorized-but-overbroad principals, credentials committed into objects, or deleted buckets whose names an attacker re-registers to serve poisoned artifacts. Detective tooling can also be blinded. Trusted Advisor’s S3 check could be silenced by bucket policies that denied the inspector permission to read the bucket ACL, the block configuration, or the policy status. Fog Security demonstrated exactly that in May 2025, keeping public buckets green in the console, and AWS shipped a comprehensive fix in late June 2025 after an incomplete first patch.

The lesson generalizes: any detector that reads state through permissions you control can be denied. Verify with a break-glass role the bucket policy cannot touch, and alert on the absence of a policy status result, not only on a public one. Apply the same distrust downstream — teams that feed bucket contents into AI pipelines treat stored objects the way they treat prompt injection defenses for cloud LLM applications: as hostile input until validated.

Sources

• Amazon Web Services — Blocking public access to your Amazon S3 storage
• Fog Security — Mistrusted Advisor: Evading Detection with Public S3 Buckets
• SecurityWeek — AWS Trusted Advisor Tricked Into Showing Unprotected S3 Buckets as Secure
• HackWire — 2.1 Billion Records Exposed in AWS S3 Misconfiguration Sweep