vibe-coding security production cursor lovable bolt

1.5 Million API Keys, Zero Authentication, and a $5,500 Cursor Bill: Vibe Coding in Production

Let’s talk about what happens when vibe-coded apps go live. Not theoretically. Not “could happen.” Actually happened, to real companies, with real user data.

The numbers from 2025-2026 are genuinely ugly: across seven documented incidents, vibe-coded apps exposed 1.5 million API keys, let unauthenticated users walk straight into private enterprise data, and wiped production databases while explicitly told not to. These aren’t edge cases. This is the normal failure mode.

Enrichlead: All Security on the Client Side

Enrichlead was a sales lead SaaS built entirely with Cursor AI. Shipped. Paying customers. Revenue coming in. One problem: every piece of security logic lived on the client side. Within 72 hours of launch, users figured out they could bypass the entire subscription by changing a single value in the browser console. Not a sophisticated attack. Not a zero-day. A browser console edit. The kind of thing a bored teenager does.

Cursor generated the code. Cursor generated the “security.” And Cursor put the authorization checks in the one place an attacker can freely modify: the user’s browser. The AI had no concept of trust boundaries because nobody told it to have one, and the founder didn’t know enough to ask.

170 Lovable Apps With Wide-Open Databases

Security researchers audited 1,645 apps built on Lovable’s platform. Over 10% — 170 apps — had critical row-level security flaws. These weren’t demo projects. They were handling real user data. Any attacker with basic Supabase knowledge could have accessed every row in every table.

The pattern is predictable: Lovable scaffolds fast and impressive-looking MVPs. The database works. The UI is polished. But the security policies that should restrict who sees what data? Either missing entirely or configured so loosely they might as well not exist. The AI doesn’t think about authorization because you didn’t prompt it to, and by the time you realize the gap, you’ve got users in production.

The $5,500 Fix-and-Break Death Spiral

One founder reported spending $5,500 in Cursor credits building a Node API. It looked great. It worked — kind of. Under the hood: 18,000 lines of AI slop, riddled with bugs, and completely unrefactorable. When Cursor couldn’t untangle its own mess, the founder hit a wall. Five grand in, no path forward, and a codebase that fights back every time you touch it. This is the fix-and-break death spiral: fix one thing, four other features break. Ask the AI to fix those, something else acts weird. Repeat until you run out of money or patience.

It’s not a bug in Cursor or Lovable or Bolt. It’s a fundamental limitation. These tools generate code forward — they don’t understand the system they’ve built. Each fix is a local patch with no awareness of global consequences. The result is software that accretes like sediment, getting heavier and more fragile with every iteration.

What This Actually Means

The vibe coding pitch is seductive: describe what you want, get working software. And for prototypes and demos, it delivers. The problem is the gap between “it works on my screen” and “it works in production with real users and real attackers.”

If your app handles user data, processes payments, or does anything beyond a portfolio site, the code needs an adult in the room. Someone who understands trust boundaries, database security, and how to structure code that can actually be maintained.

That gap between “demo-ready” and “production-ready” is exactly where projects come to die — or where they get rescued. If your vibe-coded app is in production and you’re not sure what’s under the hood, a free code scan takes five minutes and might save you a lot more than $5,500.