Glossary / AI & Vibe Coding
Row-Level Security (RLS)
Row-level security is a database rule set that decides which rows each user is allowed to read or write. Instead of the application deciding access, the database enforces it per row, so a user can only ever touch their own data even if the client is compromised.
What is row-level security (RLS)?
Row-level security is a database rule set that decides which rows each user is allowed to read or write. Instead of the application deciding access, the database enforces it per row, so a user can only ever touch their own data even if the client is compromised.
Key takeaways
- RLS makes the database, not the app, decide which rows each user can touch.
- The public anon key is safe only if RLS is on and every table has a scoped policy.
- An app works identically whether RLS is on or off, so nothing in the demo warns you.
- Deny by default; each policy must justify exactly which rows it exposes and to whom.
Why it matters
Modern app builders and backend-as-a-service platforms put a public key in the browser and rely on RLS to keep data safe. If RLS is off or misconfigured, that public key becomes a direct, unauthenticated door to your entire database. It is the single most common critical flaw in vibe-coded apps.
Common mistakes we see
The dangerous thing about RLS is that an app works perfectly whether it is on or off. Nothing in the demo tells you the door is open. We repeatedly find apps built on Supabase or Firebase where the developer assumed the anon key was a secret to protect, when in fact it is meant to be public and the actual protection, RLS or security rules, was never enabled. The result is that anyone who opens the browser console can read every row in every table. The second mistake is enabling RLS but writing a policy like "authenticated users can read" without scoping to the owner, which lets any logged-in user read everyone else data. Our approach is deny-by-default: every table starts locked, and each policy has to justify exactly which rows it exposes and to whom. Then we verify it the way an attacker would, from the client with the public key, before launch. If you cannot read someone else data with that key, the door is shut.
How RLS goes wrong
RLS never enabled
The developer treats the anon key as the secret and never turns on the actual protection, so anyone can read every row from the browser console.
Policy too broad
A rule like "authenticated users can read" with no owner scope, which lets any logged-in user read everyone else data.
Verify your RLS is real
- RLS is enabled on every table, not just the obvious ones.
- Each policy is scoped to the row owner, not just "authenticated".
- You tested from the client with the public key and could not read another user data.
- Storage buckets have their own rules, not just the tables.
Example
A booking app enables RLS but forgets a policy on the payments table. Because the default with RLS on is deny-all, payments silently stop loading. The opposite case, RLS off, is worse: every customer card detail is one console query away.
Related terms
Check your app for backend exposure
Our free, passive SaaS security check detects backend config and flags the RLS risk, without touching your data.
Check your app for backend exposure
