Database and row level security
These guides are about data that the client can reach. On Supabase, tables in the public schema are on the API, and row level security is what decides who can read a row. Firebase rules and storage policies do the same job for Firestore, Storage, and file buckets. Lovable's own Supabase notes call missing policies a common way app data gets exposed, so that guide sits here too.
Guides
Supabase tables without row level security
Tables in the public schema are reachable through the Supabase API. With row level security off, the publishable key is enough to read and change every row.
Lovable apps, RLS, keys, and auth
Lovable's own Supabase guide says missing row level security policies are the most common way app data gets exposed, and that secret keys must stay out of the client.
Open storage buckets
A public bucket, or a storage policy of allow-all, lets anyone with the URL read files other users uploaded.
Firebase rules left open
Firestore or Storage rules that allow any read and write make the database public. The client SDK will do whatever the rules allow.
Questions
Does turning on row level security without a policy lock the table?
On Supabase, enabling row level security with no policy means the anon and authenticated roles cannot read or write through the API. That is safer than leaving it off, and it will also break the app until you add the policy you actually want. Write the policy, then test it as a second user.
Will a secret key still read every row after I add policies?
Yes. Supabase documents that the secret key bypasses row level security. Policies apply to the publishable key and to signed-in users. Keep the secret key in server code only.
Is a public storage bucket the same bug as a public table?
It is the same kind of mistake. Anyone with the file URL can read the object. User uploads belong in a private bucket, with a policy that checks the owner, and the file should not be served as HTML from your own origin.
Firebase says the client API key is fine to ship. What is the control?
The web config is meant to live in the client. Firestore and Storage rules are the control. Rules that allow any read and write, or that are still in test mode, make the database public to the client SDK.