Access control and data isolation
Row-level security off on a new table
A table created by a migration or SQL has no row-level security, so the anonymous key can read and write every row through the public API.
Termsrow-level security (database rules that decide which rows each signed-in user may read or write) · two-user test (sign in as one user, create a row, then try to read or change it as another user; pass is nothing comes back) · publishable and secret keys (the publishable key may sit in the browser because row-level security limits it; the secret key bypasses those rules and must stay on the server) · API (the interface other software calls; tested directly, without the UI in between)
criticalseverity if found in a releasesources verified 2026-09-21
Why AI-assisted code produces it
Supabase documents that a table in an exposed schema without RLS is readable and writable by any role with a grant. CVE-2025-48757 (CVSS 9.3) described exactly this on generated sites, and a 2026 incident exposed 1.5 million tokens the same way.
CVE-2025-48757 (CVSS 9.3, critical): an insufficient database row-level security policy in Lovable through 2025-04-15 allowed remote unauthenticated attackers to read or write arbitrary database tables of generated sites.
Source: NIST National Vulnerability Database, 2025-05-30 · verified 2026-09-21
A table in an exposed schema without row-level security is readable and writable by any role with a grant on it; the service_role key bypasses RLS and must stay server-side.
Source: Supabase docs, 2026-09 · verified 2026-09-21
A Supabase key exposed in client-side JavaScript combined with missing row-level security policies gave read and write access to a social platform's database: about 1.5 million API tokens, 35,000 email addresses and private messages. Reported 31 January 2026, patched within hours.
Source: Wiz Research, 2026-02-02 · verified 2026-09-21
How we detect it
Query the catalog for every exposed table's RLS flag on each release; then test as a second user.
Most associated with
Tools: Cursor, GitHub Copilot, Claude Code, Windsurf, Lovable, Bolt
Stacks: Supabase
Checklist items that catch it
Every table exposed to the client has row-level security enabled
automated Query the database catalog for tables in exposed schemas and their RLS flag (Supabase, Postgres) or list collections against rules (Firebase).
Every exposed table reports RLS enabled; the list of exemptions is empty or each exemption is a public read-only table named in the release notes.
Policies deny cross-tenant reads and writes when tested as another user
automated For every table or collection, sign in as user A, create a row, then as user B attempt select, update and delete on it through the client API.
User B receives zero rows on select and a permission error on update and delete, for every table.
Dots: Starter, Growth, Scale. The item runs on every release for the plans marked.
More in access control and data isolation
- critical
- critical
- critical
- critical
- critical
Check your codebase for this pattern
The coverage audit lists which catalogue patterns apply to your critical flows. 5 business days, $1,200, credited to a first month.