Your cloud storage bucket is answering to strangers

At some point, someone needed a file to be reachable. A logo for the website, a data export a partner had to download, a backup that needed to land somewhere quickly. The fastest way to unblock the job was to flip the storage bucket — the folder in the cloud where the file lived — to “public”, so anyone with the link could get it. The job got done. The setting stayed exactly where it was.

A bucket set to public isn’t a private folder with an awkward link. It’s a folder facing the open internet, and its contents are readable by anyone who finds the address — no password, no account, no trace left behind. What often sits in these buckets is worse than a logo: database backups, customer records, scanned documents, internal exports that were only ever meant for one recipient.

This is the quiet failure, and it has a particularly nasty edge: you don’t have to be targeted to be caught. Attackers don’t guess bucket names one by one. They use search indexes — services such as GrayhatWarfare, and general scanners like Shodan — that catalogue exposed buckets by the thousand and let anyone search them by company or domain name. Your bucket doesn’t need to be interesting. It just needs to be listed, and open, and someone running a search that happens to match.

Why it stays invisible

Nothing about a public bucket looks wrong from the inside. Your application keeps reading and writing to it exactly as before. The file that needed sharing is still shared. There’s no error, no warning, no bill that spikes — the only thing that changed is that the door is open to the entire internet, and an open door makes no sound.

The exposure is also easy to create by accident and easy to forget. “Make it public” is often a single toggle, reached for under time pressure to unblock a task, by someone who fully intended to tighten it again afterwards and never got the reminder. And because the person who opened it rarely owns the bucket long-term, the knowledge that it’s open tends to leave with them. The bucket outlives the reason it was opened, and outlives the memory that it ever was.

Find it yourself

You can check whether your buckets are exposed, and start closing them, in about ten minutes. Do both halves: look from the outside, then from the inside.

From the outside — this needs no cloud login at all:

1. Go to a public-bucket search index such as buckets.grayhatwarfare.com.
2. Search your company name, your domain, and any product or project names you’ve used to name storage.
3. Anything that comes up is, by definition, already visible to strangers. Note the bucket names — you’ll need them for the next step.

From the inside, for Amazon Web Services (AWS) S3:

1. Sign in to the AWS console and open S3.
2. Look above the bucket list for the External access summary, which lists any bucket open to the public (older consoles showed this as an Access column reading “Public” or “Objects can be public”). AWS moves these labels around, but whatever the console calls it, you’re scanning for any bucket it flags as public.
3. Open that bucket, go to Permissions, and make sure Block all public access is switched on under Block public access (bucket settings).

For Microsoft Azure, open each storage account’s Configuration page and check that Allow Blob anonymous access is Disabled — Microsoft now calls public access “anonymous” access, and new accounts have it disabled by default. If it’s enabled, check each container’s Anonymous access level is Private. For Google Cloud Storage, look in the bucket list’s Public access column for any bucket marked “Public to internet”, which flags the allUsers permission.

The fix

Good looks like every bucket private by default, with public access switched on only for the rare folder that genuinely needs to serve files to the world — a website’s public images, say — and nothing sensitive living in it.

For AWS, the strongest single move is to turn on Block Public Access at the account level, not just per bucket. That sets a ceiling: even if someone later flips an individual bucket to public, the account-wide block overrides it, so a future mistake can’t reopen the door. Azure and Google Cloud have equivalent account- or project-level controls to disallow public access outright — reach for those rather than fixing one bucket at a time.

Before you lock a bucket down, do one careful check: confirm nothing your live systems depend on is being served from it publicly, so you don’t break a working site in the act of securing it. Where something legitimately needs to be shared, prefer a time-limited signed link — a URL that works for a set window and then expires — over leaving the whole bucket open.

To keep it from drifting back, lean on the account-level block as your standing guard, and put a twice-a-year note in the diary to re-run the outside-in search against your own names. It’s a small ritual, and it means the honest answer to “is anything of ours sitting open on the internet?” is one you’ve actually checked, rather than one you’re hoping is fine.