Your Lovable app looked done. Then real users arrived.

Row-level security (RLS) is a database feature: it lets you attach policies directly to a table so the database itself decides, row by row, which rows a given query is allowed to touch. Instead of trusting the application layer to filter results correctly, the database enforces the rule underneath every query, no matter which route or client sent it. That's a stronger guarantee than checking permissions in app code — but it comes with a catch. The hosted database Lovable sets up for you turns it on by default for tables you create by hand in its dashboard, but tables created by a generator's migrations often arrive with it off — and a table with RLS on and no correct policy is exposed the same way.

Turning it on isn't one setting for the whole project. You enable it per table, then write a separate policy for each operation you want to allow — select, insert, update, delete — each scoped to whichever role should have it. Skip a table, or write a policy whose condition is effectively always true, and that table is exposed exactly as if RLS were never touched. The hosted platform's API layer talks to the database using the same public key your front end ships to every browser, so once RLS is the only thing standing between a request and a row, a missing or wrong policy leaves that data open to anyone who reads the key out of your front-end bundle.

This kind of gap is easy to miss precisely because it's invisible during normal testing. A missing or overly permissive policy behaves identically to a correct one as long as every request comes from someone who's supposed to see their own data — the case a builder naturally tests while building. RLS problems only surface when two different identities want two different things, which is a scenario that's easy to never actually try before real users arrive. The app looks complete because every visible check passes; the missing wall simply never gets tested.