supabase-security

Supabase Access Control

With no API between the browser and the database, Postgres is the entire security perimeter. There is nowhere else to put a check a determined client cannot route around. Every rule here follows from that.

Built on Supabase's own linter. The audit script bundles Splinter — the SQL linter behind the dashboard's Security Advisor and the get_advisors MCP tool — and adds four checks it does not have. Splinter is Supabase's work, vendored unmodified at vendor/splinter.sql; see Credits.

The one-paragraph model

The anon key says which project. The JWT says which user. Neither says what you may do — that is schema exposure, GRANT, RLS, and (for per-column rules) triggers.

Teams get breached by believing the anon key is a credential. It is not. It is public by design and ships in your JS bundle. In CVE-2025-48757 (CVSS 9.3), 170+ production apps were fully readable and writable by anyone holding the public key — not because the key leaked, but because RLS was off. The key was doing exactly what it was designed to do.

The enforcement layers, and their order

This ordering causes more confusion than anything else in Supabase. Learn it before writing a policy.

1. GRANT           role → table/column    no predicates, no rows
2. RLS USING       which existing ROWS may be touched
3. BEFORE trigger  sees OLD, NEW and the caller; may alter NEW
4. RLS WITH CHECK  validates the resulting NEW row
5. Constraints

Note steps 3 and 4: WITH CHECK runs after BEFORE triggers, so a trigger that rewrites NEW is still subject to the policy.

Three consequences, each of which has caused a production incident:

Each layer only narrows the one above it. RLS can never grant a privilege the GRANT layer withheld. If you revoke a column, a policy saying "admins may update everything" becomes unreachable — the privilege check rejects the statement before any row is considered. This is Postgres-documented; Supabase does not document it anywhere.