Apps on Supabase, Firebase and similar platforms let the browser talk to the database directly. That is fine only if the database enforces who sees what, because anyone can call the same API without your UI. How row-level security works, the gaps that catch people (views, functions, storage), and a ten-minute test.
Your UI is not a security boundary. If the app queries the database from the browser with a publishable key, anyone can copy that key from the page and send their own queries. What comes back depends entirely on the database's rules.
Requests with the publishable key run as the anon Postgres role; signed-in users as authenticated. Policies decide what each role may do, row by row.
Supabase's documentation is blunt: a table in an exposed schema without RLS "is readable and writable by any role with a grant on it."
RLS enabled with no policies denies everything through the API. That is the safe failure.
Tables created in SQL need alter table ... enable row level security; do not assume the default.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
For user-owned rows, a select policy using ((select auth.uid()) = user_id) lets each user read only their own. Write separate policies for insert, update and delete, with a with check clause on insert and update so nobody can write a row carrying someone else's user_id. Wrapping auth.uid() in a select lets Postgres evaluate it once per statement instead of per row, and an index on user_id keeps policies fast.
Create two test accounts, A and B, and some data as A.
As B, from the browser console or a script using the publishable key and B's token, try to select, update and delete A's rows directly through the API.
Repeat with no token at all.
As B, try to insert a row with A's user_id.
Anything that succeeds is a leak. Fix it and keep the script as a test.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Which API Keys Are Safe in Your Frontend? A Field Guide for Apps Built Fast
Everything in a browser bundle or mobile app is public, including any variable your framework inlines at build time. Which keys are designed to be public and what actually protects you when they are, which must never ship, and what to do in the first hour after one leaks.
Read
Too Many Connections: Database Pooling for Serverless and Edge Apps
Postgres gives every connection its own process and a fixed maximum, while serverless platforms create a new instance, and a new connection, for each concurrent request. The result is the classic launch-day error. How the limits are set on RDS and Supabase, what a pooler does, and the transaction-mode catch.
Read
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.