S3 Bucket Exposure Checker

Enter an S3 bucket name. This sends two plain, unsigned GET requests to the bucket's own REST endpoint — a ListBucket request and a GetBucketAcl request — and reports whether anonymous listing is enabled, and whether the ACL grants read or write access to AllUsers (anyone on the internet, no AWS account required) or AuthenticatedUsers (any AWS account holder anywhere — a commonly misunderstood setting). Object file contents are never fetched by this tool — only the key (file) names S3's own listing response already returns, and ACL grant metadata. See why S3 buckets end up publicly exposed for the common causes and the fix for each, or how this compares to checking by hand. Only run this against a bucket you own or are authorised to test.

Run the check

Enter a bucket name, then click Check.

Prefer a CLI, or hit a CORS wall in the browser?

S3 buckets don't send permissive CORS headers by default, so a browser tab often cannot read a cross-origin response at all — you'll see a generic network error with no HTTP status. The CLI has no such restriction and is the one path guaranteed to complete: 

node check.mjs my-company-backups --json

Get check.mjs, probe.mjs, and analyze.mjs from the repo — exit code 1 if a finding is confirmed, so you can gate a deploy or a nightly audit on it.

Common questions

Does this tool show me the actual file contents in the bucket?

No, never. This tool only sends a ListBucket request (which returns object KEY NAMES, exactly the same names S3's own listing response includes) and a GetBucketAcl request (which returns grant metadata, never file content). It never fetches an object's bytes, and the report only ever displays key names and ACL grants -- never anything read from inside a file.

Why would a bucket end up publicly listable or writable in the first place?

Most commonly: a bucket created before S3's 2018 default-private ACL change and never revisited, a public-read ACL applied intentionally for static website hosting and left in place after the bucket started holding other data too, or S3 Block Public Access being disabled account-wide or bucket-wide for one legitimate reason and never re-enabled. AWS's own blog and IAM Access Analyzer exist specifically because this remains a common, ongoing misconfiguration.

How is this different from AWS's own tools (Trusted Advisor, IAM Access Analyzer)?

AWS's own tools check from the INSIDE -- they need you to be logged into the AWS account that owns the bucket. This tool checks from the OUTSIDE, the same unsigned, anonymous request any stranger on the internet can send with no AWS account or credentials at all -- useful for a quick self-check with no console access, or for a security researcher auditing a bucket they don't own an account for.

Is it safe to point this at a bucket name?

This tool sends only two ordinary, unsigned GET requests to the bucket name you give it -- the same requests any anonymous visitor, or curl, or the AWS CLI's --no-sign-request flag already makes. It never writes, uploads, or deletes anything, and it does not upload the bucket name or anything it finds to our servers when run in the browser. Still, only run this against a bucket you own or are authorised to test, the same caution you'd apply to any request tool aimed at someone else's infrastructure.

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

It means the two requests this run made were both cleanly denied. It does not check bucket policies that grant access under conditions this tool's plain unsigned request would not trigger, does not check object-level ACLs on individual files, and only checks the one bucket name you give it. Treat a clean report as evidence about what this run actually found, not a full audit of the bucket or the account.