supabase-audit-authenticated

Create a test user (with explicit permission) to audit what authenticated users can access vs anonymous users. Detects IDOR, cross-user access, and privilege escalation.

By yoanbernabeu · 352 installs

npx skills add yoanbernabeu/supabase-pentest-skills --skill supabase-audit-authenticated

Source repository · Upstream listing

Authenticated User Audit 🔴 CRITICAL: PROGRESSIVE FILE UPDATES REQUIRED You MUST write to context files AS YOU GO , not just at the end. Write to .sb pentest context.json IMMEDIATELY after each test Log to .sb pentest audit.log BEFORE and AFTER each action DO NOT wait until the skill completes to update files If the skill crashes or is interrupted, all prior findings must already be saved This is not optional. Failure to write progressively is a critical error. This skill creates a test user (with explicit permission) to compare authenticated vs anonymous access and detect IDOR vulnerabilities. ⚠️ IMPORTANT: User Consent Required DO NOT proceed without explicit user consent. When to Use This Skill After completing anonymous access tests To detect IDOR (Insecure Direct Object Reference) vulnerabilities To test cross user data access To verify RLS policies work for authenticated users To find privilege escalation issues Prerequisites Signup must be open (or use invite flow) Anon key available Anonymous audit completed (recommended) Why Authenticated Testing Matters Many vulnerabilities only appear with authentication: Vulnerability Anonymous Authenticated RLS bypass (no RLS) ✓ Detectable ✓ Detectable IDOR ✗ Not visible ✓ Only visible Cross user access ✗ Not visible ✓ Only visible Privilege escalation ✗ Not visible ✓ Only visible Overly permissive RLS Partial ✓ Full detection Test User Creation Email Format Example: pentest a7b3c9d2@security audit.local Password Generation Strong password with: 32+ characters Uppercase, lowercase, numbers, symbols Cryptographically random Example: Xk9$mP2 vL5@nQ8&jR4 wY7!hT3%bU6^ The password is displayed ONCE and saved to evidence. Tests Performed 1. User Creation & Login 2. Authenticated vs Anonymous Comparison For each table: Test Anonymous Authenticated Finding SELECT 0 rows 1,247 rows 🔴 Auth only exposure Own data N/A Only own row ✅ RLS working Other users' data N/A All rows 🔴 Cross user access 3. IDOR Testing 4. Cross User Access 5. Storage with Authentication 6. Realtime with Authentication Output Format Context Output RLS Policy Examples Correct: Users see only their own data Incorrect: All authenticated users see everything Correct fix: Cleanup Options Option 1: Manual deletion (Dashboard) Option 2: Via service role key (if available) Option 3: Leave for later The test user uses a non functional email domain ( security audit.local ) and cannot be used maliciously. MANDATORY: Evidence Collection 📁 Evidence Directory: .sb pentest evidence/05 auth audit/authenticated tests/ Evidence Files to Create File Content test user created.json Test user details (password saved securely) anon vs auth comparison.json Side by side comparison idor tests/[table].json IDOR test results privilege escalation.json Privilege escalation tests Evidence Format Add to curl commands.sh MANDATORY: Progressive Context File Updates ⚠️ This skill MUST update tracking files PROGRESSIVELY during execution, NOT just at the end. Critical Rule: Write As You Go DO NOT batch all writes at the end. Instead: 1. Before user creation → Log consent and action to .sb pentest audit.log 2. After user created → Immediately save user details to context and evidence 3. After each comparison test → Update .sb pentest context.json with results 4. After each IDOR test → Save evidence immediately This ensures that if the skill is interrupted, crashes, or times out, all findings up to that point are preserved. Required Actions (Progressive) 1. Log user creation: 2. Save test user to context immediately: 3. Log each finding as discovered: FAILURE TO UPDATE CONTEXT FILES PROGRESSIVELY IS NOT ACCEPTABLE. Related Skills supabase audit auth signup — Test if signup is open first supabase audit tables read — Compare with anonymous results supabase audit rls — Deep dive into RLS policies supabase audit functions — Test function access with auth supabase report — Include auth only findings in report