supabase-audit-authenticated_skill

Overview

This skill creates a disposable test user with explicit consent and runs authenticated-vs-anonymous checks to detect IDOR, cross-user access, and privilege escalation in Supabase projects. It captures evidence and saves progressive context and logs as each test completes. The goal is to reveal vulnerabilities that only appear for authenticated users and produce actionable findings and remediation guidance.

How this skill works

After explicit authorization, the skill generates a strong random password and a pentest-[8char] email, signs up the test user via the Supabase auth endpoint, and obtains a JWT. It then performs table, storage, realtime, and function checks as both anonymous and authenticated users, comparing results to identify auth-only issues like IDOR or overly permissive RLS. All actions, responses, and evidence files are written incrementally to audit logs and context files so results are preserved if the run is interrupted.

When to use it

• After anonymous access testing to reveal auth-only vulnerabilities
• To detect IDORs where objects are accessible by any authenticated user
• To verify RLS policies enforce per-user ownership
• To confirm storage and realtime channels do not expose other users' data
• Before production deployments to catch privilege escalation issues

Best practices

• Obtain explicit consent before creating test users and document it in the log
• Write context and evidence files immediately after each action (never batch at end)
• Use a non-deliverable test email domain and store the password securely (shown once)
• Compare identical queries for anon and auth to highlight differences
• Remove the test user after the audit using service_role or dashboard cleanup

Example use cases

• Sign up a test user and confirm whether the users table leaks every account to any auth user
• As the test user, attempt to GET another user's orders by filtering user_id to detect IDOR
• List storage bucket objects authenticated vs anonymous to find overly broad access
• Subscribe to realtime events as authenticated user to see if other users' events are delivered
• Attempt to call admin functions with a regular test user to detect privilege escalation