security
Lockdown Check — Row-Level Security
The RLS check whose absence caused CVE-2025-48757 — it fires before build.
What you get
Fires before build
The Lockdown Check runs before your build even starts. If row-level security isn't enforced where it should be, the deploy stops — the gap never reaches production.
The check behind a real CVE
The absence of exactly this check caused CVE-2025-48757. ZipLoom makes it a standard gate on every deploy.
Table by table, not a spot check
The check reads your Postgres schema and verifies RLS is enabled on every table holding user data — not a sample. One table left open is all it takes; that single unchecked setting is how CVE-2025-48757 left 170+ Lovable databases publicly readable.
How the Lockdown Check works
- 1
ZipLoom inspects your database schema and policies.
- 2
It verifies row-level security is enforced where tables expose user data.
- 3
If RLS is missing on a table that needs it, the finding blocks the deploy.
What this check inspects
Whether row-level security is enabled on every table, not a sample — one table left open is the whole exposure.
Whether each RLS policy actually filters by the requesting user, since a policy that returns true for everyone is enabled but useless.
Tables reachable through the public API role, including ones added after your last review.
Views and functions that can bypass the policies on the tables underneath them.
What it means when this fails
A failure here means any person with your public API key can read rows belonging to other users. This is the single most common catastrophic mistake in AI-built apps — the exact flaw that left more than 170 Lovable-built databases publicly readable under CVE-2025-48757.
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.
- 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
Snyk Team
Per contributing developer, 5-seat minimum (~$1,500/yr entry). Code + dependency scanning; does not deploy your app.
GitHub Code Security
CodeQL scanning, Dependabot, dependency review. Billed per active committer; GitHub repos only.
Semgrep Team
SAST with a strong free OSS engine; rules and triage are yours to maintain.
ZipLoom Solo — all 28 features included
Deploy, security scan, and monitoring in one flat price. Guild $40/mo · Studio $70/mo · Business $299/mo.
Related features