rls-auth-boundary-auditor

Audits Supabase RLS policies and migrations for tenant isolation gaps before deployment.

6|Updated Jul 10, 2026
One-click install
npx skills add https://github.com/Mozurok/fhorja.dev --skill rls-auth-boundary-auditor-mozurok
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rls-auth-boundary-auditor
Source: https://github.com/Mozurok/fhorja.dev/tree/main/.claude/skills/rls-auth-boundary-auditor
Command: npx skills add https://github.com/Mozurok/fhorja.dev --skill rls-auth-boundary-auditor-mozurok

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Multi-tenant Supabase applications can leak data between tenants when Row-Level Security policies are incomplete or misconfigured, and these flaws often ship to production unnoticed. This Skill audits migration files and policy DDL before deploy, catching tenant isolation failures like missing WITH CHECK clauses, absent FORCE ROW LEVEL SECURITY, and unguarded SECURITY DEFINER functions. ## Core Features & Use Cases - Per-table policy posture audit: Enumerates every tenant-scoped table in the migration set and verifies RLS enablement, FORCE ROW LEVEL SECURITY, and per-operation policy coverage (SELECT, INSERT, UPDATE, DELETE). - Follow-the-data tracing: Traces foreign keys, join tables, materialized views, and audit tables to confirm the policy chain is unbroken across every relationship. - Migration-shaped remediation: Produces concrete CREATE POLICY, ALTER TABLE, and CREATE OR REPLACE FUNCTION statements using actual column names, plus an RLS_AUDIT.md report with severity-ranked findings. - Use Case: Before merging a migration that adds a new tenant-scoped table, run the audit to confirm the table has policies with proper tenant predicates and that no join table creates a leakage path. ## Quick Start Audit the Supabase migrations in this task for tenant isolation gaps and produce a remediation plan for any RLS policy findings.

Frequently Asked Questions about rls-auth-boundary-auditor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit Supabase RLS policies before deploying a migration?▼

Run this audit against your migration files to enumerate every tenant-scoped table and verify RLS enablement, FORCE ROW LEVEL SECURITY, and per-operation policy coverage. It outputs a posture table with PASS, GAP, or FAIL verdicts and concrete SQL remediation for each gap.

What RLS misconfigurations does a Supabase security audit catch?▼

It catches USING clauses without WITH CHECK, RLS enabled without FORCE ROW LEVEL SECURITY, policies lacking tenant predicates, unprotected join and audit tables, SECURITY DEFINER functions without RLS-aware guards, and unjustified service_role bypass usage.

Why is missing WITH CHECK on an INSERT policy a critical finding?▼

Without WITH CHECK, a user can insert rows owned by another tenant that they cannot read back, creating phantom orphans and cross-tenant write paths. This is classified as a P1 finding requiring immediate remediation with a matching WITH CHECK expression.

Does this audit work with custom JWT claims instead of auth.uid()?▼

Yes, the audit accepts the declared auth model as input, including custom JWT claims like auth.jwt() ->> 'org_id' or hybrid approaches. Policy WHERE clauses are evaluated against whichever tenant identifier your auth model uses.

When should I not run an RLS boundary audit?▼

Skip it when the project is single-tenant, when RLS is intentionally disabled with documented rationale, or when the current migration set has already been audited. General non-database security review belongs to a separate security-review skill.