supabase rls security auditor

    1

    Audit and secure Supabase PostgreSQL RLS policies to prevent data leaks and privilege escalation.

    $5

    Secure checkout via Stripe

    Money-back guarantee

    Converts to your local currency at checkout

    Security scanned

    Works with the AI Agents you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIMuseMuseDotsDots+21 more

    supabase rls security auditor

    Example session with this skill installed

    Audit my 'documents' table. It has a 'team_id' column. I want to make sure users can only see and edit files belonging to their team based on a 'team_id' claim in their JWT.

    • Read your context and instructions
    • Compiled the supabase rls security

    I have audited the provided context for the documents table. Based on the introspection, RLS is enabled, but the current policy only validates read access, leaving write operations exposed.

    Vulnerability Audit: documents

    IssueSeverityRoot CauseRemediation
    Missing Write ValidationCriticalNo WITH CHECK clause exists for UPDATE or INSERT operations.Add WITH CHECK logic referencing JWT claims.
    Role Over-permissionMediumGRANT ALL is active for the authenticated role on the documents table.Restrict grants to specific required operations.
    Claim DependencyLowPolicy relies on auth.jwt() ->> 'team_id' which must be enforced via Database Webhooks or Triggers.Ensure custom claims are signed and immutable.

    Remediation Script

    -- 1. Fix the permissive Select policy
    DROP POLICY IF EXISTS "Team access" ON documents;
    CREATE POLICY "Team access" ON documents
      FOR ALL
      TO authenticated
      USING (team_id = (auth.jwt() ->> 'team_id')::uuid)
      WITH CHECK (team_id = (auth.jwt() ->> 'team_id')::uuid);
    
    -- 2. Harden table grants
    REVOKE ALL ON documents FROM authenticated;
    GRANT SELECT, INSERT, UPDATE, DELETE ON documents TO authenticated;
    

    Verification Test

    -- Test: Attempt to insert record for a different team
    BEGIN;
      -- Simulate user from Team A
      SET LOCAL role = authenticated;
      SET LOCAL "request.jwt.claims" = '{"sub": "user-uuid", "team_id": "aaaa-aaaa-aaaa-aaaa"}';
      
      -- This should FAIL
      INSERT INTO documents (team_id, name) VALUES ('bbbb-bbbb-bbbb-bbbb', 'Stolen Data');
    ROLLBACK;
    

    Next steps

    • Execute the remediation script in your Supabase SQL Editor.
    • Verify that your auth provider (e.g., Supabase Auth or a custom trigger) is correctly populating the team_id claim in the JWT.
    • Run the provided Verification Test to confirm the fix prevents cross-tenant inserts.

    Connects securely to your tools. The creator never sees your data.

    About this skill

    The problem

    Leaky Supabase authorization leads to tenant data exposure and privilege escalation. Default RLS policies often fail to account for WITH CHECK clauses or SECURITY DEFINER search path vulnerabilities.

    What it does

    • Analyzes pg_policies and information_schema to map effective access for anon and authenticated roles.
    • Identifies missing RLS enforcement on sensitive tables and broken tenant isolation in USING clauses.
    • Audits SECURITY DEFINER functions for search_path hygiene and privilege escalation risks.
    • Generates copy-paste SQL remediation scripts including CREATE POLICY, REVOKE, and ALTER TABLE.
    • Provides specific SQL test cases to verify exploits and validate the resulting fixes.

    Frameworks & tools

    Supabase, PostgreSQL, Row Level Security (RLS), PostgREST.

    Why this beats prompting it yourself

    General LLMs often hallucinate schema facts or assume a policy is secure just because it "looks" correct. This skill follows a strict evidence-based protocol, requiring introspection of auth.uid() shapes and JWT claims before declaring a security posture.

    Use cases

    • Auditing a multi-tenant SaaS for cross-tenant data leakage.
    • Hardening database functions that require elevated privileges without exposing the entire schema.
    • Generating a security threat model for a new Supabase project before production launch.
    • Verifying that service_role is the only role capable of bypassing specific business logic.

    Known limitations

    Requires read access to system catalogs or provided DDL/policy exports. Cannot detect vulnerabilities in external middleware sitting in front of Supabase.

    Requires active database introspection or provided DDL/policy exports. Cannot detect vulnerabilities in external middleware sitting in front of Supabase.

    How to use

    1. 1

      Connect your agent to the Agensi MCP

      Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup

    2. 2

      Sign in to Agensi

      Your agent shows a sign-in link. Sign in and click Allow.

    3. 3

      Ask for what you need

      Your agent loads this skill and uses it on your task. It always asks before any payment.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill goes through the trust checks below.

    Security scanned

    Checked by our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    Money-back guarantee

    Doesn't do what its page promises? You get your money back.

    Trust & safety

    Security scan

    Security scan passed 2 months ago

    Permissions

    No special permissions declared or detected

    Listed2 months ago

    What's inside

    Frequently Asked Questions

    The auditor performs a deep trace of USING and WITH CHECK clauses against your specific schema and JWT claims to find logical bypasses that generic prompts miss.

    It requires read access to system catalogs like pg_policies and information_schema, or you can provide the DDL and policy exports directly in the chat.

    Yes, it specifically audits SECURITY DEFINER functions for search_path hygiene and privilege escalation risks, which are common sources of Supabase leaks.

    Every finding includes a root cause analysis, a specific SQL exploit path to verify the leak, and a copy-paste remediation script.

    New in Agents & Orchestration