Supabase Storage and API Posture

Supabase is safe when public keys stay public, service-role keys stay server-only, and RLS policies actually fence data. The risky middle is Storage: a bucket can be public on purpose for static assets, or accidentally public for invoices, avatars, profile documents, backups, and exports.

Your Supabase project URL and anon key ship to every browser by design, so anything the anon role can reach, a stranger can reach too. Storage buckets are either public or private: files in a public bucket can be downloaded by anyone who has the URL, and Storage access policies decide whether anonymous clients can list what a bucket contains. A public bucket for marketing images is fine. A public or anon-listable bucket holding invoices, avatars, or exports turns user files into something anyone can enumerate and download.

Anonymous object listing can expose filenames, tenant hints, upload paths, and sometimes the direct object URLs customers assume are private. Even when file contents need a separate request, listing turns a private data lake into an index attackers can scrape.

Keep public buckets limited to static assets. Put user uploads, invoices, profile files, backups, exports, and attachments in private buckets. Gate downloads through authenticated server routes or Storage RLS, issue short-lived signed URLs, and verify anon clients cannot list object metadata unless that listing is intentionally public.