Security
Why AI-generated code has more security bugs than you think
Ask an AI coding tool to build a login page, and within seconds you'll have one that works. Click it, type a password, get logged in. From the outside, it looks done. Underneath, there's a decent chance it's storing that password insecurely, skipping rate limiting, or trusting the browser to enforce access control it should be enforcing on the server.
This isn't a flaw unique to one tool. It's a structural property of how these models are trained and what they're optimized to do.
AI models are trained to produce working code, not safe code
Large language models learn from enormous amounts of public code — tutorials, Stack Overflow answers, open-source repos, blog posts. A huge fraction of that training data was written to demonstrate a concept quickly, not to be production-hardened. A Stack Overflow answer showing how to query a database will often concatenate a variable straight into the SQL string, because the point of the answer is "here's how queries work," not "here's how to prevent SQL injection."
When a model generates new code, it's pattern-matching against that corpus. The shortcuts baked into millions of educational examples become the model's defaults — unless the prompt specifically asks for security, which most "build me an app" prompts don't.
The feedback loop rewards speed, not safety
Vibe coding tools are judged, in the moment, by one thing: does the app work when you click around it? Security issues are almost invisible at that stage. An exposed API key doesn't crash your app. A missing Row-Level Security policy doesn't throw an error in the browser. Debug mode left on doesn't show up in the demo. These are exactly the kinds of issues that only matter once a real, sometimes hostile, user shows up — which is after the tool has already declared success.
The model doesn't know your threat model
A human security review asks: who can access this, what's the worst thing they could do, and what happens if they try? An AI generating code from a short prompt has no idea if you're building a internal prototype or a fintech product handling real money. It defaults to the simplest version that satisfies the literal request, which is rarely the most defensive version.
The most common patterns we see
- Hardcoded secrets — API keys and database credentials written directly into source files instead of environment variables, because that's the fastest way to "make it work" in a demo
- Missing database access rules — especially with Supabase/Postgres backends, where Row-Level Security has to be explicitly turned on and is easy to skip entirely
- Client-side-only validation — checks that run in the browser and can be trivially bypassed, with no matching check on the server
- Unhandled async errors — missing
awaits and unguarded promises that fail silently until real traffic hits an edge case
This isn't a reason to avoid AI coding tools
Lovable, Bolt, Cursor, Replit, and similar tools are genuinely changing who gets to build software — that's a good thing. The fix isn't "don't use AI to code," it's adding a deliberate safety check before you ship, the same way you'd review a contractor's work even if you trust the contractor. A quick scan that catches the predictable list above — exposed secrets, missing access rules, unguarded async code, vulnerable dependencies — closes most of the realistic risk in minutes, without needing to become a security engineer.
3 free scans every month, no credit card required
Related reading: