Supabase RLS vs Firebase Security Rules
Updated 2026-10-17
Both platforms let browsers talk to the database directly with a public key, and both put the security boundary in declarative rules. This comparison describes common default patterns and where security responsibility sits. Platforms change quickly; verify current behaviour in each vendor's documentation.
| Area | Supabase RLS | Firebase Security Rules |
|---|---|---|
| Language | SQL policies on Postgres tables | Rules DSL per collection/document path |
| Identity | auth.uid(), auth.jwt() | request.auth.uid, request.auth.token |
| Classic mistake | RLS disabled or `using (true)` | `allow read, write: if true` |
| Storage | storage.objects policies | Separate Cloud Storage rules |
| Testing | Query with anon key / SQL tests | Emulator + rules unit tests |
Mental model
RLS adds a WHERE clause to every query for a role; Firebase rules evaluate each read/write request against a path. In both, a missing rule for a sensitive resource is the main risk.
Testing
Supabase: run queries as anon and as two test users. Firebase: use the emulator suite and rules unit tests.
FAQ
Is the Firebase apiKey secret?
No. Like the Supabase anon key it identifies the project; Security Rules and App Check protect data.
Can a scanner detect open Firebase rules?
Only by attempting reads, which goes beyond a passive scan. ShipGuard reports Firebase usage but does not test rules.
Check your deployed app in ~25 seconds
Free passive scan: leaked keys, Supabase exposure, public config files and headers.
Run a free scan