Attempt to read data from exposed tables to verify actual data exposure and RLS effectiveness.

Table Data Access Test 🔴 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 table tested Log to .sb pentest audit.log BEFORE and AFTER each test 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 attempts to read data from exposed tables to determine what information is actually accessible. When to Use This Skill After listing tables, to verify actual access To test RLS policy effectiveness To assess the severity of data exposure To document exactly what data can be retrieved Prerequisites Tables listed (auto invokes supabase audit tables list if needed) Anon key available How It Works The skill performs SELECT queries on each exposed table: Important: This is READ ONLY. No data is modified or deleted. Test Modes Mode Description Queries Quick First 5 rows from each table ?limit=5 Sample Random sample across tables ?limit=10&order=random Count Just row counts, no data HEAD request Usage Basic Read Test Quick Count Only Specific Table Output Format Severity Assessment Status Severity Criteria 🔴 DATA EXPOSED P0 Sensitive data (PII, secrets, financial) accessible 🟠 PARTIAL ACCESS P1 More data than expected, but not critical 🟡 UNEXPECTED P2 Accessible but low risk data ✅ BLOCKED RLS properly preventing access ✅ EXPECTED Public data, appropriate access Data Classification The skill identifies sensitive data types: Type Patterns Severity if Exposed PII email, phone, name, address P0 Financial amount, total, card, payment P0 Secrets key, secret, token, password P0 Auth user id, session, jwt P1 Metadata created at, updated at P2 Context Output Audit Log Entry Remediation Examples For User Tables For Settings Tables For Content Tables Common Issues ❌ Problem: All tables return 403 ✅ Solution: RLS may be too restrictive or anon key invalid. This is actually good from a security standpoint. ❌ Problem: Empty results but no error ✅ Solution: RLS is filtering all rows. Table structure is exposed but no data. ❌ Problem: Timeout on large tables ✅ Solution: Use count mode or reduce limit. 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 testing each table → Log the action to .sb pentest audit.log 2. After each table tested → Immediately update .sb pentest context.json with results 3. After each finding → Log the severity to .sb pentest audit.log This ensures that if the skill is interrupted, crashes, or times out, all findings up to that point are preserved. Required Actions (Progressive) 1. Update .sb pentest context.json with results: 2. Log to .sb pentest audit.log : 3. If files don't exist , create them before writing. FAILURE TO UPDATE CONTEXT FILES IS NOT ACCEPTABLE. MANDATORY: Evidence Collection 📁 Evidence Directory: .sb pentest evidence/03 api audit/data samples/ Evidence Files to Create File Content data samples/[table] sample.json Sample data from each accessible table data samples/[table] blocked.json Proof of blocked access (403 response) Evidence Format (Data Exposed) Evidence Format (Properly Blocked) Add to curl commands.sh Related Skills supabase audit tables list — List tables first supabase audit rls — Deep dive into RLS policies supabase report — Generate full report

supabase-audit-tables-read