Supabase Storage Buckets Are Public Until You Add Policies

Supabase distinguishes between a “public bucket” (unauthenticated file reads are allowed) and a “private bucket” (reads require an authorized request). Many developers create a public bucket for simplicity, not realizing that this exposes every file to anyone who guesses or discovers the URL. Even in a private bucket, upload and delete operations require explicit RLS-style policies — they do not inherit from your table-level policies. The [Supabase GitHub discussion on public bucket consequences](https://github.com/orgs/supabase/discussions/3937) confirms: “Users can read objects in public buckets without any authorization. RLS policies are still required for other operations such as object uploads and deletes.” **Scope-limited upload policy (users can only write to their own folder):** ```sql CREATE POLICY "User can upload own files" ON storage.objects FOR INSERT WITH CHECK ( bucket_id = 'user-files' AND auth.uid()::text = (storage.foldername(name))[1] ); CREATE POLICY "User can access own files" ON storage.objects FOR SELECT USING ( bucket_id = 'user-files' AND auth.uid()::text = (storage.foldername(name))[1] ); ``` ## Why it matters User-uploaded documents, invoices, profile photos, and any other files stored in Supabase Storage may be exposed to other users or the public if bucket policies are not explicitly set. This is a GDPR and CCPA exposure risk, not just a UX issue. ## Suggested next action Review every Supabase Storage bucket in your project. For user-specific files, use private buckets with scoped upload/read policies. Never rely on “obscurity” of the URL as a security control.

Supabase Storage Buckets Are Public Until You Add Policies

Sources

Confidence check

Evidence

Discussion