ShipGuardScan a site

Supabase Storage Bucket Policies for Vibe-Coded Apps

Updated 2026-10-17

Avatars and marketing images can live in public buckets. Invoices, uploads and user documents should not. Generated apps frequently create one public bucket and store everything in it.

Make private data private

Set sensitive buckets to private, then grant access per user with policies on storage.objects.

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

Use signed URLs for downloads

Serve private files with short-lived signed URLs created after an authorization check, instead of public object URLs.

Checklist

  • Only truly public assets in public buckets
  • Uploads stored under a per-user folder
  • select/insert/update/delete policies on storage.objects
  • Signed URLs for private downloads
  • Upload size and MIME limits configured

Copy-paste fix prompt

List my Supabase storage buckets and how the app uses each. Make every bucket that holds user content private, store objects under `<user_id>/...`, add storage.objects policies scoped to auth.uid(), and switch downloads to createSignedUrl with a short expiry.

FAQ

Is listing buckets with the anon key a vulnerability?

It reveals bucket names and whether they are public, which helps attackers target them. On its own it does not prove files are readable; check object policies.

Can I keep a bucket public but hide file names?

Unguessable paths reduce casual discovery, but public means anyone with the URL can read it. Use private buckets for anything sensitive.

Check your deployed app in ~25 seconds

Free passive scan: leaked keys, Supabase exposure, public config files and headers.

Run a free scan

Related