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