← Cloud bucket exposure checker
Every major provider defaults a newly created bucket or container to private, and AWS has gone further than a default: since 2018 it offers Block Public Access, an account-level switch that overrides any bucket policy or ACL underneath it and can only be turned off deliberately. Despite that, publicly listable buckets keep turning up in security research and breach disclosures years later -- including the two cited on this checker's own page: 14 million Verizon customer records exposed through a vendor's misconfigured S3 bucket in 2017, and a Pentagon contractor's exposed monitoring archive the same year. The defaults are not the problem; what overrides them is.
A bucket's effective access is not one switch, it's several, layered:
| Layer | What it is | How it goes wrong |
|---|---|---|
| ACL (S3, legacy) | A per-object or per-bucket grant list, older than bucket policies | A grant to the AllUsers group made years ago, before Block Public Access existed, quietly persists |
| Bucket policy (S3, GCS IAM) | A JSON document naming who can do what | A statement written for a static-website-hosting tutorial grants s3:GetObject to Principal: "*" -- and a later edit, meant to widen read access for one prefix, is copy-pasted without scoping the Resource field, granting s3:ListBucket too |
| Account/container-level toggle | AWS's account-wide Block Public Access; Azure's per-account "Allow Blob public access" plus a separate per-container public-access level | Two independent settings that both have to agree "private" -- an admin who checks only one assumes the other matches |
Any layer that permits the request wins for an actual anonymous visitor, regardless of what the other layers say -- which is exactly why reading each setting in the console is a different question from sending the real request and seeing what comes back.
The single most common route to an exposed bucket is not an admin deliberately choosing "public"
for private data -- it's a bucket that was supposed to allow some public access
(a static website, a public dataset, a CDN origin, a CI artifact download) getting a policy or
ACL broad enough to also permit listing every other object inside it. A policy statement written
to let anyone GetObject a website's HTML and images does not need
ListBucket at all -- but templates copied from tutorials, and IaC modules reused
across projects, often grant both together because nobody removed the unneeded permission before
applying it to a bucket that also holds internal files.
Forgotten buckets compound it: a staging or migration bucket created for a one-time job, given a wide-open policy to make the job easier, and never revisited once the job finished. Nothing about a bucket's public-listing state changes on its own after that -- it stays exactly as wide as the last edit left it until someone checks again.
A free tool that runs exactly the check above -- one real, read-only request to a bucket or container's own anonymous listing endpoint across AWS S3, Google Cloud Storage, or Azure Blob Storage -- is at the cloud bucket exposure checker. It never fetches any object's own content, only the listing, and it sends nothing about the bucket or the result to this site. As with any tool that sends requests to infrastructure you name, only run it against a bucket or container you own or are authorised to test.