How do I test RLS?

What RLS is and why testing it matters

Row-level security (RLS) is the Postgres-level rule set that decides which rows a given request can read or write, based on who's logged in. A missing or misconfigured policy is one of the most common real-world Lovable security gaps — it's invisible until someone actually tries to access data they shouldn't.

How to test it

1. Create two test accounts (or one account plus a logged-out session).

2. As account A, create some data — a post, an order, a profile field.

3. Log in as account B and try to view or edit account A's data directly — through the normal UI first, then (if you're comfortable) by inspecting the network request and adjusting the ID.

4. As a logged-out visitor, try to load pages/API calls that should require login.

5. Ask Lovable to list every table and its current RLS status rather than trying to infer it from the UI:

   List every table in the database, whether RLS is enabled, and summarise what each policy allows. Flag any table with no RLS or with a policy that looks too permissive.

6. For anything flagged, ask for a fix and re-test the same scenario afterwards.

What usually goes wrong

• A table created without RLS enabled at all — depending on configuration this can mean fully open or fully blocked; either is usually wrong.
• A policy written against auth.uid() that's correct for read but forgotten for insert/update/delete (RLS is per-operation).
• Roles checked from a column on the user's own row instead of a separate user_roles table, letting a user potentially edit their own role.
• Policies that work for the builder's own admin-like test account but were never tried as a genuine second user.

See also /questions/is-my-supabase-anon-key-safe-to-expose and /questions/how-do-i-test-admin-permissions.