Supabase row-level security for founders: the ten-minute check before launch

Most apps built with Lovable, Bolt or Cursor use Supabase underneath. Supabase is excellent, and it has one rule that AI builders routinely skip: row-level security has to be turned on and written per table, or every user can read every other user's data with the public key that ships in the browser.

The ten-minute check

1. Open your Supabase project and go to Table Editor.
2. For each table that holds user data (profiles, orders, messages, documents), look for the RLS badge. If it says "RLS disabled", that table is open.
3. If RLS is enabled, click Policies. A single policy that says true for select is the same as disabled.
4. Open your app in a private window, sign in as a test user, open the browser's developer tools, and look at the network requests to /rest/v1/. If a request for orders returns orders that aren't yours, you have your answer.

What correct looks like

Every table with user data has RLS enabled and policies that compare the row to auth.uid(): users can select and update their own rows; admins are identified by a role, not by an email check in the frontend. Storage buckets have the same treatment; a public bucket named "private-documents" is a common find.

Why the AI didn't do this

The builder is optimizing for a working demo, and open tables make demos work. Security policies make demos fail in ways that look like bugs, so the model learns to leave them off. It isn't malicious; it is the wrong objective.

What it costs to fix

For a typical prototype with ten to thirty tables, writing and testing policies is one to three days of senior work, including testing each policy with real user tokens rather than the service key. At JetBuild it is part of the $2,000 audit and critical fixes, and the report tells you which tables were exposed so you can decide whether users need to be told.