Vibe coding security audit

Your first users are in, on an app you built with Lovable or Base44, or with Cursor on Supabase. Maybe you ran a scanner and it came back with a list, or with nothing, and either way you still can't say whether one user can read another's data.

• Every row-level security policy read against your app's real roles, from a signed-out visitor to an admin.
• Every table tried as each of those roles with your app's own public key, the way an attacker starts.
• The client bundle searched for service role keys, API secrets and anything else that shouldn't reach a browser.
• Sign-in read through, from sign-up and password reset to sessions and what a signed-in user can call.
• Storage buckets checked for who can list, read and upload files.
• Edge functions and webhooks checked for calls that skip sign-in, and for webhooks that act on a request without checking its signature.
• A written report, in the order to fix things, and the fixes made and tested again.

Scanners are quick and worth running. They flag a table with row-level security off, and Supabase's own advisor does the same. What they can't tell is whether the policies on the other tables match who should see what, so a policy that's on and wrong passes. A user allowed to update their own profile row can update the role column in it too, and a hole like that only shows when someone reads the policy against the app.