Building With Supabase or Firebase? The Row-Level Security Checklist Before You Launch

UpGuard's research into 16,326 exposed Supabase databases is a reminder that the fastest way to build an app is also the fastest way to leak data. Backend-as-a-service platforms let the browser talk to the database directly — which is only safe if the database itself enforces who can see what.

Why This Keeps Happening

With platforms like Supabase, the public API key ships in your front-end code by design. Security comes from row-level security (RLS) policies on each table. Skip them, and anyone with the key — which is everyone who opens your site — can read the table. AI app builders make it easy to create tables quickly; they don't always make it obvious that each one needs a policy.

The Pre-Launch Checklist

• Enable row-level security on every table, including ones you think are unimportant.
• Write explicit policies: users read and write only their own rows; admin-only tables have no public access at all.
• Never put the service-role or admin key in front-end code, environment files committed to Git, or client bundles.
• Never store plaintext passwords — use the platform's authentication, which hashes them.
• Check storage buckets too: files have their own access rules separate from tables.
• Test as an anonymous user: open the API with only the public key and try to read every table. Anything that returns data is exposed.

Test It, Don't Assume It

The single most valuable step is the last one. Make the anonymous-access test part of your release process, so a new table added next month doesn't quietly reopen the problem.

AI-Built Apps Need a Human Review

AI tools are good at generating working features and bad at noticing what's missing. Before any app holds customer data, have someone who understands the security model review access rules, keys and data storage. A few hours of review is far cheaper than a breach notice.