Stack · Supabase

Regression testing for Supabase backends

Row-level security is the authorization layer, and the publishable key in the browser is safe only because of it. A table without a policy, or with a permissive one, is the single most documented failure on this stack.

Termsrow-level security (database rules that decide which rows each signed-in user may read or write) · 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) · 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) · critical flow (a path a user takes that costs money or trust if it breaks: sign-up, checkout, invite, export) · verdict (a one-word release result (pass, pass with findings, fail) with the findings and the checklist version behind it) · CI (the pipeline that builds and tests every change before it can be merged or deployed) · client bundle (the JavaScript your app sends to the browser or ships inside the mobile app; anyone can read it)

What Supabase changes in a codebase

Postgres exposed to the browser through an auto-generated API. Row-level security is the authorization layer, and the publishable key is safe only because of it.

Every release that adds a table, a column or a policy is a release that can open data. The checklist queries the catalog for the RLS flag on every exposed table and then proves each policy with a second user, on every release, not at go-live.

Defaults, from the docs verified 2026-09-21

Verified defaults for Supabase
Default, from the docs	Why it matters for release testing	Source
"A table in an exposed schema without RLS is readable and writable by any role with a grant on it."	AC-01 queries the catalog for every exposed table's RLS flag on every release.	docs verified 2026-09-21
The publishable key: "Anyone can read it, so it only reaches what Row Level Security allows"; "enable it on every table before you deploy."	The key in the bundle is by design; the table without a policy is the failure. AC-02 proves each policy with a second user.	docs verified 2026-09-21
The secret key "bypasses Row Level Security, so it must never leave your control. Never put one in a browser, a shipped application, or source control." A secret key in a browser returns HTTP 401 based on the User-Agent header.	SC-01 scans bundles and SC-02 scans history for the secret key; the User-Agent check does not cover mobile apps or scripts.	docs verified 2026-09-21
Production checklist: "Ensure you have enabled row level security (RLS) on all tables"; enable email confirmations; use the Security Advisor; CAPTCHA is available on signup, sign-in and password reset.	The vendor's go-live list maps to AC-01, AU-03 and AU-04; the checklist re-runs them every release.	docs verified 2026-09-21
"Database backups are not available for download for Free Plan projects."	DM-02 requires a restorable backup before any destructive migration; on the free plan that has to be produced another way.	docs verified 2026-09-21

Each row was read on the linked page on the date shown. Docs change; the date tells you how current the row is. Supabase documentation.

Failure patterns most associated

critical
API key shipped in the client bundle
A key meant for the server ends up in JavaScript the browser downloads, so anyone can read it and call the service as the app.
critical
Service-role key used from the front end
The database's bypass-everything key is used in client code, so row-level rules no longer protect anything.
critical
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.
critical
Policy that allows everything
Row-level security is enabled but the policy condition is true for everyone, so isolation exists in name only.
critical
List endpoint returns other tenants' rows
A list or search endpoint filters by the wrong column or none, so a user sees records belonging to other accounts.
critical
Object fetched by id without an ownership check
An endpoint checks that the caller is logged in, then returns whatever id was requested.
critical
Admin gate enforced only in the UI
The admin page hides its buttons from ordinary users, but the underlying route or action accepts calls from anyone logged in.
critical
Role or flag read from the request
The server decides what a user may do from a role, plan or isAdmin value that arrived in the request body, query string or client state.

All 30 patterns tagged Supabase in the catalogue

How the checklist adapts

AC-01 queries the catalog for every exposed table's RLS flag; exemptions are named in the release notes.
AC-02 creates rows as user A and attempts select, update and delete as user B through the client API, per table.
SC-01 and SC-02 scan for the secret key; the User-Agent block does not cover mobile apps or scripts.
DM-02 requires a restorable backup before destructive migrations, which on the free plan has to be produced manually.

Release checklist, five of the published items

v1.0 · verified on 2026-09-21

IdCheck and howPass criterionSeverity if failedStarter · Growth · Scale

AC-01

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).

Pass when

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.

critical

AC-02

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.

Pass when

User B receives zero rows on select and a permission error on update and delete, for every table.

critical

SC-01

No secret keys in client bundles

automated Scan the built client assets (JS, source maps, HTML) for known key prefixes and for every value present in the server environment file.

Pass when

Zero matches for key prefixes (sk_, service_role, AKIA, whsec_, private keys) and zero server-only env values found in client assets.

critical

SC-02

No secrets in repository history

tool Run a secret scanner (gitleaks or equivalent) over the full git history, not only the working tree.

Pass when

Scanner reports zero unrevoked findings; any historical finding has a rotation record.

critical

AU-03

Auth endpoints cannot be used out of order

manual Call register, verify, reset and invite endpoints out of sequence and with ids or tokens taken from public files.

Pass when

No endpoint creates a verified account or resets a credential without the intended prior step.

critical

Read the full checklist

Which plan fits

Growth $5,900/mo

Growth for daily releases with an API; Starter for a web app on weekly releases.

For 8-15 engineers, daily releases, web plus API or one mobile platform. Limits, cadence and what is not included.

Email about Growth Start with the audit

Questions

Supabase regression testing

A per-release run of AC-01 (RLS flag on every exposed table), AC-02 (two-user test per table), SC-01 (secret key not in any bundle), AU-03 and AU-04 (auth endpoints in order and rate-limited), plus the general items. The two-user test is automated in the suite we maintain in your repository.

Supabase RLS security checklist

Enable RLS on every exposed table; write policies that use the caller's id, not a constant; test each policy as a second user; keep the secret key out of browsers, apps and source control; re-run all of it on every release. Items AC-01, AC-02, SC-01, SC-02.

Supabase production checklist

Supabase publishes its own; ours re-runs the parts that change with each release (tables, policies, auth settings, backups) rather than checking them once.

How to test Supabase row level security policies?

Sign in as user A and create a row in each table. Sign in as user B and, through the client API with the publishable key, attempt select, update and delete on that row. Pass is zero rows on select and a permission error on the writes, for every table. Repeat on every release.

Get a risk list for your codebase

5 business days, $1,200, credited to the first month.

Get a risk list for your codebase See plans