Supabase storage buckets: public or private?

01What “public bucket” actually means in Supabase

Supabase Storage keeps file metadata in two tables, storage.buckets and storage.objects, and access is controlled by RLS policies on them, just like your own tables (Supabase docs).

So a public bucket is not automatically listable, but its file URLs are guessable more often than people think: avatars/USER_ID.png, invoices/2026-10.pdf. If a file name can be predicted, a public bucket serves it to anyone.

02Step 1: list your buckets

select id, public, file_size_limit, allowed_mime_types
from storage.buckets
order by public desc;

For each public bucket, ask: would I be fine with every file in here showing up in a search engine? If not, make it private (update storage.buckets set public = false where id = 'documents';) and switch the app to signed URLs.

Also set limits. file_size_limit and allowed_mime_types stop a stranger from uploading a 5 GB file or an HTML page to your bucket:

update storage.buckets
set file_size_limit = 5242880,               -- 5 MB
    allowed_mime_types = array['image/png','image/jpeg','image/webp']
where id = 'avatars';

03Step 2: review the policies on storage.objects

select policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'storage' and tablename = 'objects';

Red flags:

• bucket_id = 'documents' as the whole condition, for select. Every signed-in user can read every document. Anyone can sign up, so that is nearly public.
• Roles {public} or {anon} on insert. Strangers can upload into your bucket.
• An insert policy without an owner check in with_check. User A can drop files into user B’s folder.
• A select policy on storage.buckets for anon. Strangers can list every bucket name. Usually harmless, sometimes revealing.

04Step 3: owner-folder policies that actually hold

Store each user’s files under a folder named after their user id, for example documents/2b7f…/contract.pdf. Then compare the first folder with auth.uid():

create policy "own files: read"
on storage.objects for select to authenticated
using (bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid())::text);

create policy "own files: upload"
on storage.objects for insert to authenticated
with check (bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid())::text);

create policy "own files: update"
on storage.objects for update to authenticated
using (bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid())::text)
with check (bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid())::text);

create policy "own files: delete"
on storage.objects for delete to authenticated
using (bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid())::text);

In the client, build the path from the session, never from user input: `${user.id}/${file.name}`. Upserting a file that already exists needs select and update as well as insert.

05Step 4: serve private files with signed URLs

const { data, error } = await supabase.storage
  .from('documents')
  .createSignedUrl(`${user.id}/contract.pdf`, 60); // seconds
// data.signedUrl works for 60 seconds, then expires

The select policy decides who may create the link, and the expiry limits how long a forwarded link works. Keep expiries short for sensitive files and create links when the user clicks, not when the page loads.

06Step 5: test it as two users and a stranger

1. Sign in as user B and upload a test file to their folder.
2. Sign in as user A and try supabase.storage.from('documents').list(B_USER_ID). Expect an empty list.
3. As A, try download(`${B_USER_ID}/test.txt`). Expect an error.
4. Signed out, open https://YOUR_REF.supabase.co/storage/v1/object/public/documents/B_USER_ID/test.txt. Expect an error unless the bucket is meant to be public.
5. Signed out, check the bucket list:

curl "https://YOUR_REF.supabase.co/storage/v1/bucket" \
  -H "apikey: YOUR_PUBLIC_KEY" -H "Authorization: Bearer YOUR_PUBLIC_KEY"
# [] is what you want; a list of buckets means anon can see them

Delete the test file afterwards. For the same idea applied to tables, see the RLS checker guide.

07Common Supabase storage mistakes

• Making a bucket public to fix an error. AI builders often do this when an image won’t load. The image loads, and so does every other file in the bucket. Fix the select policy or use a signed URL instead.
• Trusting the file name from the client. If the path comes from a form field, user A can write B_USER_ID/avatar.png. Build the path from the session and enforce it in with_check.
• Policies for authenticated with no owner check. “Signed-in users can read documents” means anyone who signs up can read them.
• Long-lived signed URLs stored in the database. A one-year link saved in a row is a public link with extra steps. Create links on demand.
• Using the service role key to upload from the browser. It skips every storage policy, and it ships to every visitor. See what to do if it leaked.
• No size or type limits. Without allowed_mime_types, a public bucket can end up hosting someone else’s HTML or scripts on your project’s domain.

08What Preflight checks in Supabase Storage

The free scan asks your project for its bucket list with the public key, signed out, and reports whether strangers can list your buckets and how many are marked public. It does not list or download files. The $29 Proof Report runs step 5 for you: test user B uploads a marked canary file, test user A tries to list and download it, and the public URL is tried too. The canary is labelled so you can spot and remove it.

?Questions people ask

• Is a public Supabase bucket safe?

  For files meant for everyone, such as logos and product images, yes. Anyone with a file’s URL can download it without any policy check, so never put user documents or private uploads there.

• Can people list files in a public bucket?

  Only if a select policy on storage.objects allows it. “Public” controls downloads by URL, not listing. Check your policies anyway: many apps add a broad select policy.

• How do I make files private per user in Supabase?

  Use a private bucket, store files under a folder named after the user id, and add policies comparing (storage.foldername(name))[1] with auth.uid(). Serve files with signed URLs.

• Do signed URLs expire?

  Yes, after the number of seconds you pass to createSignedUrl. Anyone holding the link can use it until then, so keep expiries short.

• Why does my upload fail after adding policies?

  Most often the path does not start with the user id, or an upsert also needs select and update policies. Check the path your client builds.

→Related guides

• Supabase RLS checkerTest row level security as no one, then as two users. SQL and curl included.
• Lovable security scanWhat Lovable’s Quick and Deep scans cover, and how to test the live app yourself.
• Supabase anon key exposed?Why the anon or publishable key is meant to be public, and what actually leaks.
• Supabase security checklist24 checks with SQL, grouped, each marked with whether Preflight tests it.
• Supabase service_role key leakedConfirm the leak, rotate without downtime, and check what was touched.
• Bolt.new security: before you publishWhat Bolt.new checks for you, what it can’t see, and how to test the live app.
• Vibe coding security checklist20 checks for apps built with AI tools, from data leaks to headers and email.