Check for publicly exposed cloud storage buckets

20 min Impact: high Effort: medium ✓ Scan-verified — no manual checkbox

A misconfigured cloud storage bucket (AWS S3, Google Cloud Storage, Azure Blob) set to public when it shouldn't be can expose every file inside it — user uploads, internal documents, backups — to anyone who finds or guesses the bucket name.

An S3, GCS, or Azure Blob storage bucket named after your domain, left with public read access, is a common and often accidental way to expose backups, user uploads, or internal files.

How to fix it

1

Identify every cloud storage bucket your site uses

Check your codebase and asset URLs for S3, GCS, or Azure Blob references.
2

Review each bucket's public access settings

In your cloud provider's console, check whether the bucket (and its contents) is set to public, and whether that's actually intentional.
3

Restrict anything that shouldn't be public

Set buckets containing user data, internal files, or backups to private, and serve any legitimately public assets (like site images) through a signed-URL or CDN pattern instead.
4

Check bucket listing specifically

Even a bucket with private files can leak a full list of filenames if bucket LISTING itself is left public — restrict this separately from individual file access.

Common mistakes

A bucket can have individual files set to correctly require authentication while STILL allowing anyone to list every filename in it — these are two separate permission settings, both need checking.

How you'll know it's done

Every cloud storage bucket's public/private setting matches what it should actually be, and bucket listing is disabled unless deliberately public.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →

Check for publicly exposed cloud storage buckets

How to fix it

Common mistakes

How you'll know it's done

Related checks

H.I.V.E. checks this automatically