Supabase RLS Audit + Cross-Tenant Leak Test

"Can one customer see another customer's data?" On Supabase, the answer lives in your RLS policies, grants and functions. One using (true), one policy that trusts user_metadata, or one SECURITY DEFINER function in public is enough to leak every tenant's rows through the public API.

This skill makes your coding agent answer that question with evidence, not guesses.

What it does

1. Audit — 20 read-only checks Reads only Postgres catalogs, never your data. Catches:

tables without RLS; permissive or role-less policies; policies that scope neither tenant nor user; trust in user-editable metadata; SECURITY DEFINER functions and views that bypass RLS, and functions with a mutable search_path; leftover write grants and dangerous default privileges (including Postgres 17's new MAINTAIN privilege); public storage buckets and loose storage policies; roles that bypass RLS, unindexed tenant columns and slow per-row auth.uid() calls. It merges the results with Supabase's Security Advisor.

2. Leak test — proof, not suspicion On staging, a branch or a local database, the agent signs in as a real user of tenant A, exactly like the Data API does. Then, in every table with your tenant column, it tries to:

read tenant B's rows; update them; delete them; insert into tenant B. It repeats the read with a forged user_metadata pointing at tenant B, and once more as anonymous. Every write is rolled back automatically. Each table gets PASS, LEAK (with exactly what crossed) or INCONCLUSIVE; it never reports a false "safe".

3. Code review Looks for service keys reachable by the browser, Edge Functions with verify_jwt = false, service-key functions that don't check tenant membership, client-side writes, migration drift and secrets in git history.

4. Report with fixes A prioritized report a founder reads in 30 seconds and an engineer can act on. Every finding comes with evidence and ready-to-adapt fix SQL, plus a reference secure multi-tenant pattern.

5. CI guard — keep it fixed A GitHub Action that, on every pull request touching supabase/, starts a throwaway Supabase database in the runner. It applies your migrations, re-runs the checks and the leak test, and fails the PR on critical or high findings or any leak.

No secrets needed; it never connects to your projects. Reviewed exceptions go in an allowlist with a reason. Safety by design Database checks are read-only. The leak test refuses to run without explicit setup, never runs on production, and rolls back every write. The agent proposes fixes and applies nothing without your approval. What's inside SKILL.md: the full audit workflow for your agent. queries/audit.sql: the 20 checks. queries/leak_test.sql: the automated cross-tenant leak test. references/: what each check means, fix templates, the secure pattern and the report template. ci/: the guard script and the GitHub Actions workflow.

Frameworks & tools

Specifically built for Supabase projects using PostgreSQL, RLS, and Auth. Supports GitHub Actions for CI integration and works with local Supabase CLI environments.

Why this beats prompting it yourself

Writing a reliable cross-tenant leak test that covers forged JWT metadata and transactional rollbacks is complex. This skill uses a standardized battery of 20+ specific RLS checks and a proven testing harness that prevents false positives by verifying isolation with actual data operations.

Use cases

• Auditing a Supabase SaaS project before a public launch.
• Verifying that new database migrations haven't introduced RLS regressions.
• Investigating if a specific user can access another customer's data.
• Hardening Edge Functions and storage bucket policies against unauthorized access.

Known limitations

The automated leak test cannot run on production databases for safety reasons. It requires a staging, branch, or local database environment to execute write-based isolation tests.

"Can one customer see another customer's data?" On Supabase, the answer lives in your RLS policies, grants and functions. One using (true), one policy that trusts user_metadata, or one SECURITY DEFINER function in public is enough to leak every tenant's rows through the public API.

This skill makes your coding agent answer that question with evidence, not guesses.

What it does

1. Audit — 20 read-only checks Reads only Postgres catalogs, never your data. Catches:

• tables without RLS;
• permissive or role-less policies;
• policies that scope neither tenant nor user;
• trust in user-editable metadata;
• SECURITY DEFINER functions and views that bypass RLS, and functions with a mutable search_path;
• leftover write grants and dangerous default privileges (including Postgres 17's new MAINTAIN privilege);
• public storage buckets and loose storage policies;
• roles that bypass RLS, unindexed tenant columns and slow per-row auth.uid() calls.

It merges the results with Supabase's Security Advisor.

2. Leak test — proof, not suspicion On staging, a branch or a local database, the agent signs in as a real user of tenant A, exactly like the Data API does. Then, in every table with your tenant column, it tries to:

• read tenant B's rows;
• update them;
• delete them;
• insert into tenant B.

It repeats the read with a forged user_metadata pointing at tenant B, and once more as anonymous. Every write is rolled back automatically. Each table gets PASS, LEAK (with exactly what crossed) or INCONCLUSIVE; it never reports a false "safe".

3. Code review Looks for service keys reachable by the browser, Edge Functions with verify_jwt = false, service-key functions that don't check tenant membership, client-side writes, migration drift and secrets in git history.

4. Report with fixes A prioritized report a founder reads in 30 seconds and an engineer can act on. Every finding comes with evidence and ready-to-adapt fix SQL, plus a reference secure multi-tenant pattern.

5. CI guard — keep it fixed A GitHub Action that, on every pull request touching supabase/, starts a throwaway Supabase database in the runner. It applies your migrations, re-runs the checks and the leak test, and fails the PR on critical or high findings or any leak.

• No secrets needed; it never connects to your projects.
• Reviewed exceptions go in an allowlist with a reason.

Safety by design

• Database checks are read-only.
• The leak test refuses to run without explicit setup, never runs on production, and rolls back every write.
• The agent proposes fixes and applies nothing without your approval.

What's inside

• SKILL.md: the full audit workflow for your agent.
• queries/audit.sql: the 20 checks.
• queries/leak_test.sql: the automated cross-tenant leak test.
• references/: what each check means, fix templates, the secure pattern and the report template.
• ci/: the guard script and the GitHub Actions workflow.

Tested

• Every check and the leak test are covered by an automated test suite, run against a Postgres database seeded with real-world RLS mistakes.
• The leak test and the CI guard were run on real Supabase stacks, Postgres 15 and 17:
  • a deliberately broken app fails with exactly its 2 seeded leaks;
  • the secure pattern passes with zero false positives.
• The CI workflow was also run on GitHub against a production SaaS schema: it passes the clean schema and blocks a pull request that adds a table without RLS.
• A write test that can't run (for example on a read-only connection) reports INCONCLUSIVE, never a false PASS.