Cloud Bucket Exposure Checker

Sends one real, read-only HTTP GET request -- a cloud provider's own anonymous listing endpoint -- to an AWS S3, Google Cloud Storage, or Azure Blob Storage bucket you choose, and checks whether the response is a real, well-formed listing document, not just whether the status code is 200. A publicly listable bucket lets anyone on the internet enumerate every object name with no credentials -- and if the bucket also allows public object reads, every listed name is directly downloadable. Only point it at a bucket you own or are authorised to test.

See this checker vs. manually checking in the cloud console — the case a quick console glance misses. Already found a publicly listable bucket? How to fix it, per provider.

A clean report here only covers listing. See public listing vs. public read for why a bucket can still hand out object content even when this checker reports it private, and the exact setting that closes each on S3, GCS, and Azure.

1. Run the CLI against your bucket

Node.js, no dependencies to install:

node check.mjs https://your-bucket.s3.amazonaws.com/ --json
node check.mjs --provider gcs --bucket your-bucket --json
node check.mjs --provider azure --bucket your-container --account your-storage-account --json

Get check.mjs, probe.mjs, and engine.mjs from the repo — plain Node, nothing to install. It only ever talks to the bucket you name; nothing goes through this site, and it never fetches any individual object's content, only the listing.

2. Paste the JSON output here

Paste the JSON from step 1 and click Check.

Common questions

What can someone actually do with a publicly listable bucket?

Anyone can enumerate every object name in the bucket with no credentials at all -- and object names alone are often sensitive on their own: customer IDs, internal filenames, database backup dates, employee names in a photo path. If the same bucket is ALSO configured to allow public object reads (a separate setting this tool does not test), every listed name becomes directly downloadable. This is the mechanism behind a long list of real breaches -- Verizon (14 million customer records, 2017), a Pentagon contractor's exposed social-media-monitoring archive, and dozens of Have I Been Pwned entries -- and it is exactly why AWS now turns "Block Public Access" on by default for every new bucket. More background: why cloud buckets end up publicly listable despite that default.

Why does this only check listing, and not whether the files themselves are downloadable?

Finding out a bucket allows public listing is the exposure this tool checks; downloading what is inside it is a different, higher-liability action a real authorised penetration test would take. This tool sends exactly one request -- the listing endpoint -- and never issues a GET against any individual object key it finds, the same restraint git-exposure-check documents for not requesting a repository's packed objects once HEAD/config already confirm exposure. A bucket can also be configured so objects are publicly readable even when listing is blocked (a direct link still works); that is a real, separate exposure this tool does not detect, because it never has an object key to test without a listing to find one in.

Why does this need a CLI instead of just checking a bucket name I type into the page?

A cloud provider's bucket-listing endpoint does not send permissive CORS headers by default, so a browser tab cannot reliably read the response even though the request itself would go out -- the same CORS restriction git-exposure-check and cors-misconfig-check document for checking an arbitrary third-party endpoint from inside a page. A small local CLI with no such restriction, run from your own machine, gets a definitive answer every time.

Does a clean report mean my bucket has no exposure at all?

No. This checks one specific, well-documented exposure class -- anonymous public LISTING at the one bucket or container you point it at. It does not check public object-read access, bucket policies for authenticated-but-not-owner roles, object ACLs on individual files, server-side encryption, versioning, or logging, and it only checks the one bucket you name, not every bucket in an account. Treat a clean report as evidence about this one exposure class on this one bucket, not a full cloud security assessment.

Why only AWS S3, Google Cloud Storage, and Azure Blob Storage?

Those three are the object-storage services most commonly left publicly listable by an accidental misconfiguration, and each publishes a stable, documented anonymous-listing response shape this tool can classify without guessing: AWS S3 and Google Cloud Storage share an S3-compatible XML API (a ListBucketResult root element), and Azure Blob Storage has its own EnumerationResults schema. A provider without a documented anonymous-listing endpoint in this same request-response shape is out of scope rather than guessed at.