/rls-checker

name: memstack-security-rls-checker
description: "Use this skill when the user says 'check RLS', 'audit RLS', 'RLS policies', 'row level security', 'Supabase security audit', or needs to verify table-level access control. Audits Supabase Row Level Security policies across all tables. Do NOT use for non-Supabase projects or writing RLS policies from scratch."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

🔒 RLS Checker: Auditing Row Level Security...

*Audit Supabase Row Level Security policies across all tables in a project.*

Activation

When this skill activates, output:

`🔒 RLS Checker: Auditing Row Level Security...`

Then execute the protocol below.

Context Guard

| Context | Status | |---------|--------| | **User asks to check/audit RLS** | ACTIVE: full audit | | **User mentions Supabase security** | ACTIVE: full audit | | **User asks about table permissions** | ACTIVE: full audit | | **User is writing RLS policies** | DORMANT, they know what they're doing | | **Non-Supabase project** | DORMANT: not applicable |

Protocol

Step 1: Discover Tables

Find all Supabase tables referenced in the project. Search in priority order:

1. **Migration files**: most authoritative source:

   find . -path "*/migrations/*.sql" -o -path "*/supabase/migrations/*.sql" | head -50

Look for `CREATE TABLE` statements.

2. **Generated types**: comprehensive if available:

   types/database.ts, types/supabase.ts, src/types/database.types.ts, database.types.ts

Parse the `Tables` interface for all table names.

3. **Client usage**: catches tables missed by above:

   grep -r "\.from(['\"]" --include="*.ts" --include="*.tsx" --include="*.js"

Extract table names from `.from('table_name')` calls.

4. **Storage buckets**: separate RLS surface:

   grep -r "storage\.from\|createBucket\|storage-api" --include="*.ts" --include="*.tsx" --include="*.sql"

Compile a deduplicated list of all tables and storage buckets.

Step 2: Extract RLS Policies

For each table, find its RLS configuration:

1. **Search migration SQL for RLS statements:**

• `ALTER TABLE <name> ENABLE ROW LEVEL SECURITY`: RLS is on
• `CREATE POLICY` statements: extract policy name, operation (SELECT/INSERT/UPDATE/DELETE/ALL), and USING/WITH CHECK expressions
• `ALTER TABLE <name> FORCE ROW LEVEL SECURITY`: RLS enforced even for table owners

2. **Check for intentionally unprotected tables:**

• Tables with `GRANT SELECT ON <table> TO anon` without RLS are intentionally public
• Look for comments like `-- public table`, `-- no RLS needed`, or `-- rls:skip` in migration SQL
• Tables marked with `-- rls:skip` should be classified as ✅ OK (Intentional) in the report, not flagged as missing RLS. This lets teams explicitly document tables that rely on application-level authorization (e.g., service-role-first architectures).
• If no `-- rls:skip` marker exists and no RLS is enabled, flag normally.

3. **Check Supabase dashboard-configured policies:**

• Policies created via the Supabase Dashboard do NOT appear in migration SQL files. They exist only in the live database.
• If a table has no RLS in migration files but is referenced in application code, note in the report: "⚠️ Policy may exist in Supabase Dashboard, verify via `supabase inspect db policies` or the Dashboard UI."
• Search for Supabase CLI config files (`supabase/config.toml`, `.supabase/`) that might indicate whether the project uses Dashboard-managed policies.
• Recommend teams capture all Dashboard-created policies in migration files for auditability:

     supabase db dump --schema public --data-only=false | grep -A5 "CREATE POLICY"

4. **Check Supabase dashboard seed/init files** for policy definitions that may not be in migrations.

Step 3: Analyze Policies

For each table with RLS enabled, evaluate policy quality:

**Check 1, Operation Coverage:** Flag tables missing policies for any CRUD operation:

• Has SELECT but no INSERT → partial coverage (WARNING)
• Has SELECT but no UPDATE/DELETE → partial coverage (WARNING)
• Has no policies at all despite RLS enabled → locked out (CRITICAL)

**Check 2, User Isolation:** Verify policies filter by authenticated user:

• `auth.uid()` in USING clause: standard user isolation (OK)
• `auth.uid()` in WITH CHECK clause: write isolation (OK)
• No `auth.uid()` reference: overly permissive (WARNING)
• Hardcoded UUIDs instead of `auth.uid()`: security risk (CRITICAL)
• `current_setting('app.*')` instead of `auth.uid()`: anti-pattern (WARNING). This relies on the application explicitly setting a PostgreSQL session variable before every query. If the variable is unset, the policy may fail open or closed unpredictably. Prefer `auth.uid()` which Supabase populates automatically from the JWT. Flag with:

  grep -rn "current_setting" --include="*.sql"

**Check 3, Multi-Tenant Isolation:** For tables with `organization_id` or `team_id` columns:

• Policy should JOIN against a membership table to verify org access
• Direct `organization_id = <value>` without membership check is insufficient (WARNING)
• Example of correct pattern:

  CREATE POLICY "org_isolation" ON documents
    USING (organization_id IN (
      SELECT org_id FROM organization_members
      WHERE user_id = auth.uid()
    ));

**Check 4, Service Role Bypass:** Search codebase for service role usage that bypasses RLS:

grep -r "service_role\|serviceRole\|supabaseAdmin\|SUPABASE_SERVICE_ROLE" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env*"

• Server-side API routes using service role: acceptable if intentional (INFO)
• Client-side code with service role key: critical vulnerability (CRITICAL)
• Service role in `.env` committed to git: critical vulnerability (CRITICAL)

**Check 5, Storage Bucket Policies:** For each storage bucket f