DEV Community: Frank Gilroy

The Firebase security rules checklist for AI-built apps

Frank Gilroy — Fri, 13 Nov 2026 21:27:23 +0000

Your Firebase web config, apiKey included, is public by design: it ships in your JavaScript and anyone can read it. The only thing between that config and your users' data is your security rules, and AI tools often leave them in test mode or loosen them until the app "works". Here's how to check them in about ten minutes.

1. Find test-mode and allow-all rules

From your project folder:

grep -nE "if true|request.time <|\"\.(read|write)\": *true" firestore.rules storage.rules database.rules.json

Any hit is an open door. allow read, write: if request.time < timestamp.date(...) is the default test-mode rule: everything is public until that date, and when it passes the app breaks and someone "fixes" it with if true.

2. "Signed in" is not "allowed"

allow read, write: if request.auth != null; lets every user who signs up read and change every other user's documents. Tie each document to its owner:

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null && request.auth.uid == userId;
}

Where the owner is a field, check it on both sides: resource.data.ownerId == request.auth.uid for reads and updates, and request.resource.data.ownerId == request.auth.uid for creates.

3. Lock the fields users must not change

If users can update their own profile document, they can also set role: "admin" or credits: 999999 on it unless your rules forbid it:

allow update: if request.auth.uid == userId
  && !request.resource.data.diff(resource.data).affectedKeys().hasAny(['role', 'plan', 'credits']);

4. Check the Realtime Database too

If you use it, database.rules.json with ".read": true or ".write": true at the root opens the whole database. Scope it per user:

{
  "rules": {
    "users": {
      "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" }
    }
  }
}

5. Check Storage rules

Storage has its own rules file, and AI tools often leave it wide open. Scope uploads to the user's own folder and limit size and type:

match /b/{bucket}/o {
  match /uploads/{userId}/{fileName} {
    allow read: if request.auth != null && request.auth.uid == userId;
    allow write: if request.auth != null && request.auth.uid == userId
      && request.resource.size < 5 * 1024 * 1024
      && request.resource.contentType.matches('image/.*');
  }
}

6. Keep admin credentials out of the browser and the repo

The web config is fine to ship. A service-account key (a JSON file with "type": "service_account" and a private_key) is not: it bypasses every rule. It belongs only on a server or in Cloud Functions. Check your history too:

git log --all --oneline -S '"private_key"'

If that prints anything, delete the key in the Google Cloud console (IAM → Service accounts → Keys) and create a new one. Removing the file from the repo is not enough.

7. Prove it from the outside

Signed out, a private collection must refuse to list:

curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/<collection>?pageSize=5"

You want 403 PERMISSION_DENIED. If you get documents back, anyone on the internet can too. The Rules Playground in the Firebase console lets you test signed-in cases, such as user A reading user B's document.

Check your repo automatically. Leakproof's free scanner flags Firebase rules left in test mode or set to if true, admin keys in client code, secrets in public env vars and more. It runs locally:

npx github:beingRealFrank/leakproof

Want someone to go through all of this, plus your live project, and send fix PRs? See the fixed-price audits.

Written with AI assistance. Found a mistake? Open an issue at https://github.com/beingRealFrank/leakproof/issues.

The Supabase RLS checklist for apps built with Lovable, Bolt or Cursor

Frank Gilroy — Fri, 13 Nov 2026 18:56:37 +0000

AI app builders make Supabase apps fast. They also make it easy to ship a database anyone can read.

Your frontend holds the anon key, and that's by design: anyone can see it. The only thing between that key and your users' data is Row Level Security (RLS). Here's how to check yours in about ten minutes.

1. Find tables with RLS off

Run this in the Supabase SQL editor:

select schemaname, tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Every row returned is a table the anon key can read and write through the REST API, whatever your UI shows. Fix:

alter table public.<table> enable row level security;

With RLS on and no policies, nobody can access the table except your server using the service_role key. Then add only the access you need.

2. Find policies that let everyone in

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true');

using (true) on a select policy means "anyone can read every row". That's fine for a product catalog and a leak for anything per-user. On insert/update/delete/all it means anyone can change anyone's data. The usual fix is an ownership check:

drop policy "<name>" on public.todos;
create policy "owners only" on public.todos for all to authenticated
  using (auth.uid() = user_id)
  with check (auth.uid() = user_id);

3. Prove it from the outside

Policies are easy to misread. Test with the same key an attacker has (your anon key, from your site's JS):

curl "https://<project>.supabase.co/rest/v1/<table>?select=*&limit=5" \
  -H "apikey: <anon key>"

Signed out, this should return [] or an error for any private table. Then sign in as test user A and confirm you can't see user B's rows.

4. Keep the service_role key out of the browser

The service_role key ignores RLS entirely. It belongs only in server code (API routes, server actions, edge functions). Search your code for SERVICE_ROLE and make sure none of it is in a 'use client' file, a NEXT_PUBLIC_ / VITE_ variable, or committed to git. If it ever was, rotate it.

5. Watch for the service_role shortcut in server actions

A common generated pattern: a server action creates a service_role client "to make it work", then updates a row by id. RLS no longer applies, so any signed-in user can change any row by sending a different id. Use the user's own Supabase client on the server (so RLS applies), or add .eq('user_id', user.id) to every query.

6. Check storage buckets

select id, public from storage.buckets;

A public bucket serves any file to anyone with its URL, with no policy check. Fine for avatars, not for invoices, uploads or exports. Make those private and use createSignedUrl().

7. Check views and functions

Views run with their creator's permissions by default, so a view over a protected table can leak it. On Postgres 15+ use create view ... with (security_invoker = true). Functions marked security definer also bypass RLS, so make sure they check auth.uid() themselves.

Automate the repo side. I made a free, MIT-licensed scanner, Leakproof, that reads your migrations and code and flags tables without RLS, allow-all policies, service_role keys in client code, secrets behind public env prefixes, public buckets and unauthenticated server actions. It runs locally with nothing uploaded:

npx github:beingRealFrank/leakproof

Disclosure: I also offer fixed-price audits of AI-built apps. The checklist and scanner are free either way.

Written with AI assistance.