Simple explanation
Vibe coding security is not a special kind of security. It is the security work that becomes easy to skip when an AI-built app looks finished before hidden systems have been reviewed.
Common risks include exposed secrets, database tables with weak or missing Row Level Security, unsafe payment webhooks, login checks that exist only in the interface, missing rate limits, and user data returned more broadly than necessary.
The front end can look polished while these problems remain invisible. Ask an AI tool to inspect specific controls, show evidence, and name what it could not verify.
What to do
Run this checklist before launch:
Supabase and RLS: list tables that store user or business data. Confirm Row Level Security is enabled where isolation is required. Test an anonymous user, the owner, and a different authenticated user for reads, inserts, updates, and deletes.
Secrets and environment variables: check that service-role keys, payment secret keys, webhook secrets, and private API tokens are server-only. Never commit them, print them in logs, or paste their values into an AI prompt.
Payments and webhooks: verify signatures server-side, handle duplicate events, and do not grant paid access because a browser says “paid.” Test success, decline, cancellation, refund, retry, and delayed webhook states.
Auth and user data: test guessed IDs and URLs, logout, password reset, expired sessions, account deletion, and access to another test user’s records.
Rate limits: identify login, password reset, public forms, uploads, expensive AI requests, and payment endpoints. Ask what limits or abuse controls exist and mark unknowns for manual provider review.
For deeper review, use the Supabase Safety Checklist, the Non-Developer App Launch Checklist, and the GitHub guide.
Copy-paste prompt
Audit this AI-built app for launch security without changing files and without printing secret values. Inspect Supabase RLS and policies, storage access, auth and ownership checks, exposed environment variables, payment and webhook verification, duplicate events, rate limits, public endpoints, input validation, and sensitive data in responses or logs. For every finding, give evidence, impact, a safe next check, and whether you verified it or inferred it. Do not report PASS unless the relevant test actually ran.
Course note
Key takeaway
Do not trust a security PASS without evidence. Ask for the audit, run the important tests, and keep launch blocked when access or secret handling is still unknown.