Uploaded files in a public storage bucket
What it looks like
-- Supabase
insert into storage.buckets (id, name, public)
values ('uploads', 'uploads', true);
// Firebase storage.rules
match /{allPaths=**} {
allow read: if true;
}What happens
Anyone who has or guesses a file link can download customer uploads such as ID scans, contracts or invoices, with no login.
Where it shows up
Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.
Check it yourself
Uses your builder's dashboard and your browser. No tools to install.
- In the Supabase dashboard open Storage and look for the Public label on each bucket; in Firebase open Storage, then the Rules tab.
- Upload a test file through your app as a signed-in user, then copy the file's link from the Network tab in developer tools (right-click, Inspect).
- Open that link in a private window where you are signed out.
- In Supabase, open Advisors, then Security Advisor, and read any warning about public buckets that allow listing.
A bad result is a file that was meant to be private opening without a login, or a rule that reads allow read: if true.
What we check
We test each bucket signed out and as a second account, try to list its contents, and check whether file paths follow a guessable pattern such as a user id plus the original filename. The report shows which buckets served private files and how their paths could be found.
Fix direction
Keep private uploads in a private bucket and hand out short-lived signed URLs from the server; reserve public buckets for assets meant for everyone, such as logos. Supabase's docs describe both bucket types and the RLS policies on storage.objects (row rules on the file table) that govern uploads and downloads.
Mechanism documented in: Storage Buckets (verified 2026-09-21); Storage Access Control (verified 2026-09-21).
Covered by
Pre-launch check ($490, 48 hours) and Security sweep ($290, 24 hours)
Both include a re-check after your fixes.
Related patterns
- Firebase rules left in test modeData accessCritical
Anyone with the app's public Firebase config, which sits in its JavaScript, can read, overwrite or delete the entire database and storage bucket without signing in.
- Row Level Security disabled on a tableData accessCritical
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
- Record ids accepted without an ownership checkData accessCritical
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
Questions
is my supabase storage bucket public
Open Storage in the Supabase dashboard; each bucket shows a Public label when it is. Supabase's docs state that in a public bucket anyone who has the file's URL can download it, while uploads and deletes still go through access rules. If customer documents live in a bucket marked Public, move them to a private one and serve them with signed URLs.
can anyone download files from a public supabase bucket
Yes, if they have the link. Public means the download needs no login; listing the bucket is blocked unless a policy allows it, and the Security Advisor warns when one does. Whether that is a problem depends on the content: fine for logos, not fine for uploaded ID documents. Run the signed-out test in the self-check on your own upload.
how to make uploaded files private in a lovable app
Ask the builder to create a private bucket, add RLS policies on storage.objects so users can read and write only their own paths, and serve downloads through signed URLs that expire. Lovable's Supabase integration exposes bucket settings in the dashboard, and Supabase's Storage Access Control docs describe the policy shape. Re-run the private-window test afterwards.
Back to the catalogue, or run the self-check for your stack.