You shipped something. It works. Users are signing up.
And somewhere in your codebase, there's a Firebase rule that reads allow read, write: if true.
This is not a hypothetical. In March 2026, a quit-porn app called Quittr - 600,000 users, $1.1M in total revenue - was found to have every user record publicly readable. Ages. Emotional triggers. Personal confessions. The fix would have taken five minutes. The founders didn't know it was needed.
If you built your app with Lovable, Bolt, Cursor, v0, Replit, or any AI coding tool, this post is for you.
Why vibe-coded apps are uniquely vulnerable
AI coding tools optimize for "it works." They generate functional code fast, and that's genuinely useful. But security is almost never functional - a broken auth check doesn't throw an error, it just quietly lets the wrong person in.
The result is a specific, predictable set of mistakes. Not random vulnerabilities - the same four or five patterns, repeated across tools, stacks, and founders. A 2026 OX Security study found 62% of AI-generated code ships with vulnerabilities. CVE-2025-48757 (February 2026) affected 170+ Lovable apps by exploiting the same RLS misconfiguration pattern the tool had generated thousands of times.
These are factory-produced vulnerabilities. Which means they're findable and fixable before you ship.
The 8 most common vulnerabilities we see
1. Exposed API keys and secrets
AI assistants embed API keys directly in frontend code because it's the path of least resistance. The result: your OpenAI key, Stripe live key, or Supabase service-role key is readable by anyone who opens DevTools ? Sources on your deployed site.
Check: Build your app locally and search the output:
ash
grep -r "sk_live|service_role|OPENAI_API" ./dist
If anything shows up, it's exposed in production too.
2. Supabase Row Level Security disabled
RLS is what prevents one user from reading another user's data - or an unauthenticated request from reading all users' data. When AI-generated Supabase code throws a permission error, the model's fix is to disable RLS on the table. Error goes away. Vulnerability ships.
CVE-2025-48757 exploited this exact pattern: the public anon key (which is embedded in your client by design) was enough to dump entire tables because RLS wasn't there to stop it.
Check: Open your Supabase dashboard ? Table Editor ? each table should show RLS as enabled with at least one policy defined.
3. Firebase insecure rules
Firebase ships new projects in "test mode" with rules that allow anyone to read and write everything: allow read, write: if true. These rules are meant to be temporary. AI tools generate Firebase code that assumes they've been updated. They often haven't.
Check: Firebase Console ? your database ? Rules tab. If you see if true anywhere, change it now.
4. Unprotected API routes
AI tools generate API endpoints. They don't always generate the middleware that checks whether the caller is authenticated. The result: a /api/users endpoint that returns your full user list to any unauthenticated GET request.
Check: Test your API routes with no auth header or cookie using curl or a tool like Insomnia. If you get data back, the route is open.
5. Stripe webhook bypass
Stripe sends webhooks to your server when payments happen. If you don't verify the webhook signature, anyone can POST to your endpoint and fake a successful payment.
Check: Your webhook handler should call stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET). If it doesn't, it's unprotected.
6. SQL injection
AI-generated database queries sometimes concatenate user input directly into query strings. This is the oldest vulnerability in web development and it's still showing up in vibe-coded apps.
Check: Search your codebase for string concatenation in database queries: anything like SELECT * FROM users WHERE id = is a red flag. Use parameterized queries or an ORM.
7. CORS wildcard
Access-Control-Allow-Origin: * means any website can make requests to your API. Combined with missing auth checks, this can expose data to any domain that wants it.
Check: In your browser's DevTools ? Network, look at the response headers for your API calls. If you see access-control-allow-origin: * on authenticated endpoints, investigate.
8. Missing security headers
Security headers protect your users from browser-level attacks: clickjacking (X-Frame-Options), cross-site scripting (Content-Security-Policy), and insecure connections (HSTS). Most vibe-coded apps ship without any of them.
Check: Go to securityheaders.com and enter your URL. A grade below B means you're missing important ones.
What actually happens when these go unfixed
The Quittr story is the clearest example: 600,000 users had their most personal data exposed - confessions, ages, emotional triggers - for the entire lifetime of the app. The founders found out from a journalist, not from a monitoring alert. The app had generated over a million dollars in revenue. The fix was changing five lines of Firebase rules.
The Moltbook breach (January 2026) moved faster: 1.5 million API authentication tokens and 35,000 email addresses exposed within 72 hours of launch. The vector was a Supabase database with no row-level security - the same pattern as CVE-2025-48757.
A Lovable-featured EdTech app (showcased on Lovable's own homepage) was found to have 16 security vulnerabilities, 6 of them critical.
These aren't enterprise targets. They're solo founders and small teams who shipped something that worked and didn't know what they didn't know about security.
How to check your app today
The manual checks above will catch the obvious issues. But some vulnerabilities only show up at the intersection of source code and live site behavior - a secret that's in the code but only exposed after build, or an RLS configuration that looks correct but has a gap in one policy.
VibeSafe runs 16 checks across both layers - source code and live site - using static analysis, secret scanning, live header inspection, and behavior probing. You get a report with plain-English descriptions of each finding and exact steps to fix them.
Pricing is $19-$49 one-time. No subscription.
The Shield: preventing this on your next project
Even if you fix everything today, the next app you build with AI tools will generate the same patterns again - because the models haven't changed.
VibeSafe includes something called The Shield: an AI context file (CLAUDE.md, .cursorrules, or .windsurfrules depending on your tool) that you drop into your project at the start. It instructs your AI assistant to follow secure defaults: no hardcoded secrets, RLS enabled on every table, webhook signature verification, parameterized queries. The model follows the constraint file, so the vulnerable patterns don't get generated in the first place.
Conclusion: scan before you ship
The vulnerabilities in this list aren't hard to introduce - AI tools introduce them by default. And they're not hard to find, once you know what to look for.
The founders who built Quittr weren't careless. They shipped in 10 days using tools that made it easy, and no one told them what the defaults were leaving open. This checklist exists so you don't find out the same way they did.
Scan your app. Fix what you find. Ship with confidence.
VibeSafe runs 16 security checks on vibe-coded apps - source code and live site. Plain-English report, exact fixes, trust badge. One-time pricing from $19. ? vibesafe.store
Top comments (1)
The keys one goes deeper than the frontend. Even when they never ship to the client, they usually sit in .env under default names like OPENAI_API_KEY, readable by anything running on your machine. Push people to the macOS Keychain (or the OS equivalent) and off the obvious names. The other move I'd add: point an up-to-date harness like Claude Code at your own app and tell it to break in. White-box especially - give it the source and the running app and let it hunt. The same tools writing these bugs are good at finding them.