Your Supabase storage bucket is public. Is that a problem?

Someone opened your app, spent a minute poking at it, and sent you a message: your Supabase storage bucket is public, and anyone can list what is in it.

That is two separate claims. One of them is probably a setting you chose on purpose and should keep. The other is the one worth an afternoon.

Here is the part that guide after guide gets wrong: public and listable are two different switches, and the alarming one is not the switch everybody tells you to flip. Making a bucket private closes the first. It can leave the second standing wide open, and a bucket that has never been public in its life can be listable this afternoon.

Is a public Supabase storage bucket a security problem?

On its own, no. It means one specific thing, and that thing is very often what you wanted.

Marking a bucket public gives every file in it a URL that works without a login. That is the whole feature. It is how the avatar on a comment loads for a reader who has no account, how your logo appears in an email, how a product photo shows up for someone who is still deciding whether to sign up.

A public bucket is closer to an unlisted phone number than to an unlocked door. The line connects for anyone who dials it, and there is no directory to look the number up in. Whether that is fine depends on one question, which is how easily somebody could arrive at the number without being told it.

Supabase makes new buckets private and puts a warning on the toggle, so a public bucket is something somebody switched on: you, or your builder, getting an upload feature to work.

What the public toggle actually turns on

One row of the table below, and nothing else on it.

Supabase's own troubleshooting page states it about as plainly as it can be stated: a public bucket means there is a public URL you can use to download the file, and every other operation still has to satisfy the policies on that bucket.

So the public toggle is a smaller control than its name suggests. Three of those four rows are decided somewhere else entirely, under Storage → Policies, and the message you received was almost certainly about the second one.

Why a private bucket can still be listable

Because listing is granted by an access policy, and the policy most people paste in grants it to everybody.

Every read from Storage passes through Row Level Security on a table called storage.objects. Listing a bucket is a read, filed under SELECT, exactly like downloading a file is. Supabase's own quickstart shows a policy in this shape, which is where copies of it tend to come from:

create policy "Public Access"
  on storage.objects for select
  using ( bucket_id = 'public' );

Read what that says. Any request at all may read anything in that bucket. It does not ask who is asking, and it does not ask whether the file has anything to do with them. Reading covers downloading a file, and it covers handing over the list of files, because those are the same permission wearing two hats.

The bucket's own public toggle never comes into it. A policy like that on a private bucket makes the bucket listable, and the dashboard will go on truthfully describing it as private.

The word doing the damage is "any". A request carrying the publishable key that ships inside your app's code satisfies that policy perfectly, and that key is meant to be readable by everyone, which is precisely why the policy is supposed to be the part doing the work. This is the same shape as the problem next door, where Row Level Security is switched on and permitting everything anyway.

What someone gets from a list of your files

Names, mostly. Which is a great deal more than it sounds.

Filenames tend to describe their contents, because a person chose them while thinking about what was inside: invoice-march-acme.pdf, passport-front.jpg, payroll-final-v2.xlsx. A list of those is a fair summary of your business, and a count of them says roughly how many customers you have. If the bucket is also public, every name on that list is a working link.

Back to the phone number. Being unlisted is worth something right up until the directory gets published, and afterwards it never mattered how hard the number was to guess.

The way this surfaces is ordinary. A document belonging to one customer turns up in front of another one. Somebody quotes the name of a file back to you that they had no way of knowing. A folder of uploads gets copied wholesale by an automated crawler that was reading every Supabase project it could find.

Our free scan asks your Storage for a listing using nothing except the key that is already in your app's code, and tells you which buckets answered with contents. It reads names and never downloads a file. It takes about 20 seconds and needs no account: scan your app.

How to tell which one you have

Two checks in the Supabase dashboard, and the second is the one the message was really about.

Storage → Buckets. The public ones are labelled as public. For each one, ask whether every single file in it is something you would be content to show a stranger. Not most files. Every file, including whatever gets uploaded there next week by a feature you have not built yet.

Storage → Policies. Read each SELECT policy that touches the bucket. A condition that mentions only the bucket name lets anyone read it. A condition comparing the file's owner to the person making the request is doing real work. An empty policy list on a private bucket means nothing gets read at all, which is restrictive and safe.

If your app has to show a private file to the right person, the tool for that is a signed link: your server asks Supabase for a URL that works for a set number of minutes and then stops working. That keeps the file private and still gets it onto the page.

When public is the right answer

More often than a security article usually admits, and it is worth saying so.

If the file is meant for everyone, public is correct, and working around it buys you a slower app and more code to maintain. Avatars, logos, cover images, anything a signed-out visitor is supposed to see: put them in a public bucket and stop thinking about it.

The one thing to do even there is keep the listing off. A public bucket of avatars is a feature. The same bucket handing over the complete list of everyone who has ever uploaded one is a different thing that you did not ask for.

If the file belongs to one particular person, it goes in a private bucket with a policy that checks who is asking, and reaches the page through a signed link. The test is a single question: who is this file for? Everyone, or one named account.

What to do this week

Open Storage → Policies in your project and read what is in there, before you change a single toggle. That one screen is what decides whether the second half of the message you got was true. The 10-minute security checklist covers it next to the rest of what a newly launched app tends to leave open, and if a bucket did turn out to be readable, what a stranger can reach in your database is the next thing to read, since the policy that hands over a file list is the same shape as the one that hands over a table.