How to secure your database: Supabase RLS, Firebase Rules, and what AI builders get wrong
SHORT ANSWER
If you built your app with an AI tool and it uses Supabase or Firebase, your database is likely more open than you think. The AI turns off Row Level Security or writes permissive rules to get things working, and never tightens them. The anon key in your frontend is public by design, so your database rules are the only thing protecting your data. Here is exactly what to check.
Supabase: Row Level Security (RLS)
What is RLS?
Row Level Security is Postgres's built-in way to control who can read and write each row. When RLS is off on a table, anyone with your anon key (which is in your frontend JavaScript) can read, insert, update, or delete every row.
The 3 mistakes AI tools make with RLS
1. RLS is disabled entirely. The table works, the app works, and every row is public. Check: Supabase dashboard → Table Editor → look for tables marked "RLS disabled."
2. Policy uses true or only checks authentication.
-- This lets EVERYONE read every row:create policy "open" on users for select using (true); -- This lets ANY SIGNED-IN USER read every row:create policy "authenticated" on users for select using (auth.role() = 'authenticated');Signing up is free. "Authenticated" is not "authorized."
3. No policy at all after enabling RLS. RLS is enabled, but no policies exist. This blocks all access, which breaks the app, so the developer disables RLS again. The fix: add a policy that checks ownership.
The correct pattern
-- Users can only read their own row:create policy "own rows" on users for select using (auth.uid() = id); -- Users can only update their own row:create policy "own update" on users for update using (auth.uid() = id);Every table that holds user data needs a policy like this for SELECT, INSERT, UPDATE, and DELETE.
How to verify it works
# This should return 0 rows (or only public data):curl "https://YOUR_PROJECT.supabase.co/rest/v1/users?select=*" \ -H "apikey: YOUR_ANON_KEY"If it returns user records with emails, phones, or addresses, your RLS is off or too open.
Firebase: Security Rules
The 3 mistakes AI tools make with Firebase rules
1. Read/write open to everyone.
{ "rules": { ".read": true, ".write": true }}Firebase warns you about this in the console, but AI-generated code often ships with it.
2. Authentication without ownership.
{ "rules": { "users": { ".read": "auth != null" } }}Any signed-in user can read every user's data.
3. Firestore rules with broad collection access.
match /users/{userId} { allow read: if request.auth != null;}Same problem in Firestore syntax.
The correct pattern
{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } }}Or in Firestore:
match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId;}Quick checklist for any database
- Can an unauthenticated user read any table? (They shouldn't, unless it's truly public data.)
- Can a signed-in user read another user's rows? (They shouldn't.)
- Can a signed-in user write to another user's rows? (They definitely shouldn't.)
- Are admin-only tables protected by role checks, not just authentication?
- Is the service_role key (Supabase) or admin SDK key (Firebase) kept server-side only?
How to scan your database rules automatically
- Connect your GitHub repo or upload a zip on SetRepo. Add your live URL if the app is deployed.
- A free Quick scan checks for: Supabase RLS status, Firebase security rules, exposed service keys, public-prefixed secrets, and your live site's headers.
- Each finding comes with a fix prompt you can paste into your AI tool.
- A Deep scan adds an AI review of your access rules and data flow — catching things like a policy that checks authentication but not ownership.
Continue your website review
Use the website security walkthrough to check the live site and access controls, then record the results in the pre-launch checklist. Start a free live URL scan for public-facing checks.
FAQ
Is my Supabase anon key a security risk?
No. It's designed to be public. Your Row Level Security policies are what protect your data. The anon key without RLS is the problem.
My app works fine without RLS. Why bother?
It works for you because you're the only one using it. Without RLS, anyone who finds your Supabase URL and anon key (both are in your frontend) can query your entire database.
Does SetRepo check my live database?
No. It checks your code and configuration files for RLS settings, security rules, and exposed keys. It never connects to your database directly.
What does it cost?
The Quick scan is free with no credit card. A Deep scan is a one-time payment, and there are monthly plans if you scan often. See setrepo.com/pricing.