
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.
- Installs
- 425
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/yoanbernabeu/supabase-pentest-skills --skill supabase-audit-authenticated- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads supabase-audit-authenticated automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
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.jsonIMMEDIATELY after each test- Log to
.sb-pentest-audit.logBEFORE 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
╔═══════════════════════════════════════════════════════════════════╗
║ 🔐 USER CREATION CONSENT REQUIRED ║
╠═══════════════════════════════════════════════════════════════════╣
║ ║
║ This skill will CREATE A TEST USER in your Supabase project. ║
║ ║
║ The user will be created with: ║
║ • Email: pentest-[random]@security-audit.local ║
║ • Password: Strong random password (32+ chars) ║
║ • Purpose: Testing authenticated access vs anonymous ║
║ ║
║ At the end of the audit, you will be asked if you want to ║
║ DELETE the test user (recommended). ║
║ ║
║ Do you authorize the creation of a test user? ║
║ Type "yes, create test user" to proceed. ║
║ ║
╚═══════════════════════════════════════════════════════════════════╝
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
pentest-[8-char-random]@security-audit.local
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
# Create user
curl -X POST "$SUPABASE_URL/auth/v1/signup" \
-H "apikey: $ANON_KEY" \
-H "Content-Type: application/json" \
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
# Login and get JWT
curl -X POST "$SUPABASE_URL/auth/v1/token?grant_type=password" \
-H "apikey: $ANON_KEY" \
-H "Content-Type: application/json" \
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
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
# As test user, try to access other user's data
curl "$SUPABASE_URL/rest/v1/orders?user_id=eq.[OTHER_USER_ID]" \
-H "apikey: $ANON_KEY" \
-H "Authorization: Bearer [TEST_USER_JWT]"
# If returns data: IDOR vulnerability!
4. Cross-User Access
# Get test user's ID from JWT
TEST_USER_ID=$(echo $JWT | jq -r '.sub')
# Try to access data belonging to a different user
curl "$SUPABASE_URL/rest/v1/profiles?id=neq.$TEST_USER_ID" \
-H "Authorization: Bearer [TEST_USER_JWT]"
# If returns other users' profiles: Cross-user access!
5. Storage with Authentication
# Test authenticated storage access
curl "$SUPABASE_URL/storage/v1/object/list/documents" \
-H "apikey: $ANON_KEY" \
-H "Authorization: Bearer [TEST_USER_JWT]"
# Compare with anonymous results
6. Realtime with Authentication
// Subscribe to table changes as authenticated user
const channel = supabase.channel('test')
.on('postgres_changes', {
event: '*',
schema: 'public',
table: 'orders'
}, payload => console.log(payload))
.subscribe()
// Does it receive OTHER users' order changes?
Output Format
═══════════════════════════════════════════════════════════
AUTHENTICATED USER AUDIT
═══════════════════════════════════════════════════════════
─────────────────────────────────────────────────────────
Test User Creation
─────────────────────────────────────────────────────────
Status: ✅ User created successfully
Test User Details:
├── Email: pentest-a7b3c9d2@security-audit.local
├── User ID: 550e8400-e29b-41d4-a716-446655440099
├── Password: [Saved to evidence - shown once]
└── JWT obtained: ✅
─────────────────────────────────────────────────────────
Anonymous vs Authenticated Comparison
─────────────────────────────────────────────────────────
Table: users
├── Anonymous access: 0 rows
├── Authenticated access: 1,247 rows ← ALL USERS!
└── Status: 🔴 P0 - Data hidden from anon but exposed to any auth user
Table: orders
├── Anonymous access: 0 rows (blocked)
├── Authenticated access: 1 row (own orders only)
└── Status: ✅ RLS working correctly
Table: profiles
├── Anonymous access: 0 rows
├── Authenticated access: 1,247 rows ← ALL PROFILES!
├── Own profile only expected: ❌ NO
└── Status: 🔴 P0 - Cross-user profile access
─────────────────────────────────────────────────────────
IDOR Testing
─────────────────────────────────────────────────────────
Test: Access other user's orders by ID
├── Request: GET /orders?user_id=eq.[other-user-id]
├── Auth: Test user JWT
├── Response: 200 OK - 15 orders returned
└── Status: 🔴 P0 - IDOR VULNERABILITY
Proof:
curl "$URL/rest/v1/orders?user_id=eq.other-user-uuid" \
-H "Authorization: Bearer [test-user-jwt]"
# Returns orders belonging to other-user-uuid!
Test: Access admin endpoints
├── Request: GET /functions/v1/admin-panel
├── Auth: Test user JWT (regular user)
├── Response: 200 OK - Admin data returned!
└── Status: 🔴 P0 - PRIVILEGE ESCALATION
─────────────────────────────────────────────────────────
Storage with Authentication
─────────────────────────────────────────────────────────
Bucket: documents
├── Anonymous: ❌ 0 files (blocked)
├── Authenticated: ✅ 523 files visible ← ALL USERS' FILES!
└── Status: 🔴 P1 - Auth users see all documents
Bucket: user-uploads
├── Anonymous: ❌ 0 files
├── Authenticated: 3 files (own files only)
└── Status: ✅ RLS working correctly
─────────────────────────────────────────────────────────
Summary
─────────────────────────────────────────────────────────
New Findings (Auth-only):
├── 🔴 P0: users table - all users visible to any auth user
├── 🔴 P0: profiles table - cross-user access
├── 🔴 P0: IDOR in orders - can access any user's orders
├── 🔴 P0: Privilege escalation in admin-panel
└── 🟠 P1: documents bucket - all files visible to auth users
Comparison:
├── Issues found (Anonymous): 3
├── Issues found (Authenticated): 8 ← 5 NEW ISSUES!
└── Auth-only vulnerabilities: 5
Recommendation:
These issues were NOT visible in anonymous testing!
Always test with authenticated users.
─────────────────────────────────────────────────────────
Cleanup
─────────────────────────────────────────────────────────
⚠️ Test user still exists in database.
Do you want to delete the test user?
Email: pentest-a7b3c9d2@security-audit.local
[This requires service_role key or manual deletion]
═══════════════════════════════════════════════════════════
Context Output
{
"authenticated_audit": {
"timestamp": "2025-01-31T12:00:00Z",
"test_user": {
"email": "pentest-a7b3c9d2@security-audit.local",
"user_id": "550e8400-e29b-41d4-a716-446655440099",
"created_at": "2025-01-31T12:00:00Z",
"deleted": false
},
"comparison": {
"tables": {
"users": {
"anon_access": 0,
"auth_access": 1247,
"expected_auth_access": "own_row_only",
"severity": "P0",
"finding": "All users visible to any authenticated user"
},
"orders": {
"anon_access": 0,
"auth_access": 1,
"expected_auth_access": "own_rows_only",
"severity": null,
"finding": "RLS working correctly"
}
},
"idor_tests": [
{
"test": "access_other_user_orders",
"vulnerable": true,
"severity": "P0",
"proof": "curl command..."
}
],
"privilege_escalation": [
{
"endpoint": "/functions/v1/admin-panel",
"vulnerable": true,
"severity": "P0"
}
]
},
"summary": {
"anon_issues": 3,
"auth_issues": 8,
"auth_only_issues": 5
}
}
}
RLS Policy Examples
Correct: Users see only their own data
-- This RLS policy is correct
CREATE POLICY "Users see own data"
ON users FOR SELECT
USING (auth.uid() = id);
-- Result:
-- Anonymous: 0 rows
-- Authenticated: 1 row (own data)
Incorrect: All authenticated users see everything
-- This RLS policy is WRONG
CREATE POLICY "Authenticated users see all"
ON users FOR SELECT
USING (auth.role() = 'authenticated'); -- ❌ Too permissive!
-- Result:
-- Anonymous: 0 rows
-- Authenticated: ALL rows ← VULNERABILITY!
Correct fix:
-- Fix: Add user ownership check
CREATE POLICY "Users see own data"
ON users FOR SELECT
USING (auth.uid() = id); -- ✅ Only own row
Cleanup Options
Option 1: Manual deletion (Dashboard)
Supabase Dashboard → Authentication → Users → Find test user → Delete
Option 2: Via service_role key (if available)
curl -X DELETE "$SUPABASE_URL/auth/v1/admin/users/[USER_ID]" \
-H "apikey: $SERVICE_ROLE_KEY" \
-H "Authorization: Bearer $SERVICE_ROLE_KEY"
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
{
"evidence_id": "AUTH-TEST-001",
"timestamp": "2025-01-31T12:00:00Z",
"category": "auth-audit",
"type": "authenticated_testing",
"test_user": {
"email": "pentest-a7b3c9d2@security-audit.local",
"user_id": "550e8400-...",
"password": "[STORED SECURELY - DO NOT COMMIT]"
},
"comparison_test": {
"table": "users",
"anonymous": {
"curl_command": "curl '$URL/rest/v1/users' -H 'apikey: $ANON_KEY'",
"response_status": 200,
"rows_returned": 0
},
"authenticated": {
"curl_command": "curl '$URL/rest/v1/users' -H 'apikey: $ANON_KEY' -H 'Authorization: Bearer $JWT'",
"response_status": 200,
"rows_returned": 1247
},
"finding": {
"severity": "P0",
"issue": "All users visible to any authenticated user",
"expected": "Only own row should be visible",
"impact": "Full user enumeration for any authenticated user"
}
}
}
Add to curl-commands.sh
# === AUTHENTICATED TESTING ===
# NOTE: Replace [JWT] with test user's JWT
# Compare anonymous vs authenticated access
curl -s "$SUPABASE_URL/rest/v1/users?select=*&limit=5" -H "apikey: $ANON_KEY"
curl -s "$SUPABASE_URL/rest/v1/users?select=*&limit=5" -H "apikey: $ANON_KEY" -H "Authorization: Bearer [JWT]"
# IDOR test - access other user's data
curl -s "$SUPABASE_URL/rest/v1/orders?user_id=eq.[OTHER_USER_ID]" \
-H "apikey: $ANON_KEY" \
-H "Authorization: Bearer [JWT]"
# Cross-user profile access
curl -s "$SUPABASE_URL/rest/v1/profiles?id=neq.[TEST_USER_ID]" \
-H "apikey: $ANON_KEY" \
-H "Authorization: Bearer [JWT]"
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:
- Before user creation → Log consent and action to
.sb-pentest-audit.log - After user created → Immediately save user details to context and evidence
- After each comparison test → Update
.sb-pentest-context.jsonwith results - 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)
-
Log user creation:
[TIMESTAMP] [supabase-audit-authenticated] [CONSENT] User authorized test user creation [TIMESTAMP] [supabase-audit-authenticated] [CREATED] Test user pentest-xxx@security-audit.local -
Save test user to context immediately:
{ "authenticated_audit": { "test_user": { "email": "...", "user_id": "...", "created_at": "..." } } } -
Log each finding as discovered:
[TIMESTAMP] [supabase-audit-authenticated] [FINDING] P0: IDOR in orders table
FAILURE TO UPDATE CONTEXT FILES PROGRESSIVELY IS NOT ACCEPTABLE.
Related Skills
supabase-audit-auth-signup— Test if signup is open firstsupabase-audit-tables-read— Compare with anonymous resultssupabase-audit-rls— Deep dive into RLS policiessupabase-audit-functions— Test function access with authsupabase-report— Include auth-only findings in report
FAQ
What does the supabase-audit-authenticated skill do?
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.
How do I install supabase-audit-authenticated?
Run npx skills add https://github.com/yoanbernabeu/supabase-pentest-skills --skill supabase-audit-authenticated in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/supabase-audit-authenticated/ (personal) or .claude/skills/supabase-audit-authenticated/ (project).
Which AI agents can use supabase-audit-authenticated?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is supabase-audit-authenticated safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains supabase-audit-authenticated?
It is published by yoanbernabeu in yoanbernabeu/supabase-pentest-skills. It has 425 recorded installs.
More from yoanbernabeu/supabase-pentest-skills
supabase-audit-rls
yoanbernabeu/supabase-pentest-skills
Test Row Level Security (RLS) policies for common bypass vulnerabilities and misconfigurations.
supabase-audit-functions
yoanbernabeu/supabase-pentest-skills
Discover and test Supabase Edge Functions for security vulnerabilities and misconfigurations.
supabase-pentest
yoanbernabeu/supabase-pentest-skills
Orchestrate a complete Supabase security audit with guided step-by-step execution and ownership confirmation.
supabase-audit-auth-config
yoanbernabeu/supabase-pentest-skills
Analyze Supabase authentication configuration for security weaknesses and misconfigurations.
supabase-audit-rpc
yoanbernabeu/supabase-pentest-skills
List and test exposed PostgreSQL RPC functions for security issues and potential RLS bypass.
supabase-audit-realtime
yoanbernabeu/supabase-pentest-skills
Test Supabase Realtime WebSocket channels for unauthorized subscriptions and data exposure.
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.