Lockdown Check — Row-Level Security

What you get

How The Lockdown Check Works

1. 1

   ZipLoom reads your migration files on every deploy and, once you connect a Supabase project, the live database: its security advisor, policies and functions.

2. 2

   It checks that row-level security is switched on for every table the public API exposes, and that no policy lets everyone in.

3. 3

   If RLS is off on a table the public API exposes, or a policy lets signed-out visitors write to every row, the finding blocks the deploy.

What this check inspects

• Whether row-level security is enabled on every table in your public schema, read live from your Supabase project rather than sampled — one table left open is the whole exposure.

• Whether any RLS policy simply returns true for everyone — row-level security switched on, but nothing filtered. One that lets signed-out visitors write blocks the deploy; one that only lets everyone read is flagged for you to confirm.

• Tables left open to the public API role without row-level security, including ones added in the dashboard since your last review — the live check runs on every production deploy.

• Views that bypass the policies on the tables underneath them, and functions in your public schema that run with elevated privileges and that signed-out visitors can call.

• Supabase Auth settings that weaken every policy: long-lived sessions, refresh-token rotation switched off, short passwords and unconfirmed sign-ups.

Questions

Why isn't a working login enough?

Logging in controls who gets a session; row-level security controls what that session can read. Without it, an authenticated user — or anyone with the public key — can request another user's rows directly from the database and get them.

Does ZipLoom change my policies?

No. It reports which tables and policies are unsafe and what the fix is. You (or your AI tool) apply the change, then the scan confirms it on the next deploy.

Do I have to connect my Supabase project?

No. The migration-file check runs on every deploy without it. Connecting adds the live check: in Settings you paste a Supabase access token, which ZipLoom stores encrypted and uses only for read requests. A Supabase token has account-wide reach, so we recommend a dedicated Supabase account for it, and you can remove the connection at any time.

How does ZipLoom know which database a project uses?

From the Supabase URL in the project's settings in ZipLoom, in its environment variables or its Secrets Vault (NEXT_PUBLIC_SUPABASE_URL, SUPABASE_URL or VITE_SUPABASE_URL). A project is checked only when that URL points at a Supabase project you have connected. If there is no URL, or it points at one you have not connected, the live check does not run for that project and the deploy log says so.

What if a table is meant to be public?

Switch row-level security on and add a read policy that says so. The live check then reports the always-true read policy for you to confirm, without blocking. A table with row-level security switched off entirely is treated as open to everyone and blocks the deploy, and so does a policy that lets signed-out visitors write to every row.

What if ZipLoom can't reach Supabase?

The deploy continues: the live check fails open rather than holding your release. The deploy log says the database was not checked, and the evidence record for that deploy says the check could not run — it is never recorded as a pass. ZipLoom retries briefly when Supabase is rate limiting or returning errors before giving up.

What if I'm not on Supabase Postgres?

The check targets Postgres row-level security as used by Supabase. Other databases are covered by the broader code and posture checks; tell us what you're on and we'll tell you honestly what's covered.

What it replaces