Vibe Coding Security Checklist
What to Check Before Every Launch
A vibe-coded app is only as secure as the checklist its builder ran before launching. This checklist was built from real incidents — including the May 2025 audit that found 170 of 1,645 Lovable-built apps with data-leak vulnerabilities — and covers every security step a non-technical builder needs to take before shipping to real users.
Talk to an ExpertWhy a security checklist is necessary for vibe-coded apps
AI code generators produce working software quickly — but working software and secure software are not the same thing. AI tools generate the most plausible implementation of what you described. They do not automatically add every security layer, because many security configurations are invisible in the user experience and are easy to omit from a prompt. Supabase Row Level Security is not enabled by default — you have to turn it on and write the policies. API keys appear in generated code as placeholders that are sometimes left in client-side code. Input validation is often only client-side, not server-side. These are not AI failures — they are gaps that any non-technical builder needs a checklist to catch.
Working software and secure software are not the same thing
Security configurations are often invisible in demos — only visible when tested specifically
Row Level Security must be explicitly enabled — it is not on by default in Supabase
API keys in client-side code are visible to anyone using browser developer tools
What is at stake if you skip security checks
The consequences of a security failure in a vibe-coded app range from embarrassing to severe. A data leak exposes your users' personal information — and potentially triggers GDPR obligations requiring you to notify affected users and regulators within 72 hours. An exposed API key can lead to fraudulent charges on your billing account. A missing backup before a database migration can cause permanent data loss. In May 2025, 170 Lovable-built applications had data-leak vulnerabilities — not because the developers were malicious, but because they did not know what to check. Every one of those vulnerabilities was preventable with a ten-minute security review.
Data leaks can trigger GDPR notification obligations within 72 hours
Exposed API keys can result in fraudulent charges on your billing accounts
Database operations without backups risk permanent, unrecoverable data loss
170 of 1,645 Lovable apps had preventable vulnerabilities (May 2025 audit)
The complete pre-launch security checklist
Run through this checklist before every deployment to production. Each item takes less than five minutes to check:
Authentication: Is every protected route actually protected? Test by opening it in an incognito window without logging in
Row Level Security: Is RLS enabled on every Supabase table? Run: SELECT * FROM users WHERE id != auth.uid() — this should return zero rows
API keys: Search your deployed codebase for any string matching sk_, pk_, API_KEY, or SECRET. None should appear in client-side code
Input validation: Submit empty required fields, very long strings, and special characters (< > ' " ;) to every form
Error handling: Intentionally cause a server error — what does the user see? It should not expose stack traces
CORS configuration: Restrict allowed origins to your own domain — not *
Database backup: Verify an automatic daily backup is configured in Supabase before any users join
SSL: Confirm your deployment URL uses HTTPS — never ship over HTTP
Real incidents this checklist prevents
Each item on the checklist above corresponds to a real class of incident that has affected vibe-coded apps publicly.
Missing RLS → Lovable audit (May 2025): 170 apps where any user could query any other user's data
No database backup → Replit agent (July 2025): Production database deleted during migration with no recovery path
Exposed API key → Documented cases of Stripe and OpenAI keys hardcoded in client-side code, leading to fraudulent usage charges
Missing error handling → Apps showing raw database error messages to users, exposing schema and query structure
Security steps that non-developers most often skip
These are the steps that are skipped most frequently — not because builders are reckless, but because the tools do not surface them prominently.
Row Level Security — it is configured in Supabase's dashboard, not in the app code — easy to forget
CORS configuration — defaults are often too permissive; restrict to your own domain before launch
Server-side input validation — client-side validation is bypassed trivially; always validate on the server
Webhook signature verification — Stripe webhooks without signature verification can be spoofed
Rate limiting — login and sign-up endpoints without rate limiting are vulnerable to brute-force attacks
How to maintain security after launch
Security is not a one-time checklist — it is an ongoing practice. Review your security configuration every time you add a new feature or database table. Audit your Supabase logs monthly for unusual query patterns. Update your dependencies regularly — outdated packages are the most common attack vector in any web application. At Greta, we include a security audit as standard on every production build — and we provide a documented security configuration that builders can maintain independently.
Re-run the security checklist every time you add a new feature
Enable Row Level Security on every new Supabase table the moment you create it
Review Supabase and Vercel logs monthly for unusual access patterns
Keep dependencies updated — run npm audit weekly and fix high-severity issues
Greta includes a documented security configuration with every production build
Explore Further
Related guides and resources
Want a security-reviewed, production-safe vibe-coded app?
Greta audits every AI-generated build before deployment. No compromises on security.