The 7 security bugs AI coding tools ship by default

Cursor, Copilot, v0, Lovable, Bolt, and GPT are genuinely good at shipping fast. They are also remarkably consistent at shipping the same dangerous bugs — not because the tools are malicious, but because they optimize for "works in the demo" and pattern-match training data that was never meant for production.

This list is honest about where it comes from: the OWASP LLM Top 10 for LLM-specific risks, plus the failure patterns we see repeatedly when auditing AI-scaffolded apps. These are the exact classes of issues that vibe-code-rescue detects with AST analysis and that llm-security-audit probes in black-box tests. No client war-stories, no invented statistics — just what to look for, how to spot it in thirty seconds, and how to fix it.

01. Debug mode left on in production

AI scaffolds often ship with verbose error pages, stack traces, and DEBUG=true because that makes local development painless. In production, the same settings leak file paths, dependency versions, database connection strings, and sometimes secrets in config. Flask's debug mode can even enable a remote code execution console.

Why AI tools ship it: the app "works" locally with debugging on, and the model rarely adds a separate production config unless you ask.

Fix it: Set DEBUG=false in production via environment variables — never in committed config. Log full traces server-side; return a generic message to the client. In Flask, never pass debug=True outside local dev. Add a CI check that fails if debug flags appear in production deploy manifests.

02. Auth that looks real but checks nothing server-side

The UI shows a login page, a "protected" dashboard, and maybe a redirect if you're not logged in. Under the hood, the API routes are wide open — or the check happens only in React via a useEffect that hides a button. An attacker who knows the endpoint URL walks straight in. Common in Lovable, v0, and Bolt exports: frontend auth is complete; the backend never validates the session.

Why AI tools ship it: they generate the visible auth UX first because that's what you asked for, and server-side middleware is boilerplate they often skip unless prompted.

Fix it: Every protected route must verify the session or JWT on the server before business logic runs. Use established libraries (NextAuth with getServerSession, Flask-Login, Django auth decorators). Never trust client-side guards alone. Write one integration test per protected endpoint that asserts unauthenticated requests get 401/403.

03. Plaintext (or weakly-hashed) passwords

AI-generated login handlers frequently compare passwords with == against a column named password or pw. Sometimes they "hash" with MD5 or SHA-256 without a salt — which is barely better than plaintext against any modern attack. Registration and password-reset flows are often missing entirely, so the insecure compare is the only path.

Why AI tools ship it: a direct string comparison is the shortest code that makes the demo login work, and models reproduce that pattern from outdated tutorials.

Fix it: Hash with bcrypt (cost factor ≥ 12) or argon2id at registration time. Store only the hash. Compare with a constant-time function (bcrypt.checkpw, argon2.verify) — never roll your own. If you already have plaintext passwords in the database, force a reset: you cannot safely "upgrade" stored plaintext without user action.

04. Hardcoded secrets / keys shipped to the browser

API keys, Stripe secrets, OpenAI tokens, and database URLs end up in source files or in NEXT_PUBLIC_* / VITE_* environment variables — which means they are bundled into the JavaScript sent to every visitor. AI tools love putting sk-... right in the fetch call because it makes the feature work immediately. Anyone can open DevTools → Sources and extract them.

Why AI tools ship it: the model needs a working API call to demonstrate the feature, and env-var naming conventions for "public" vs "server" keys are easy to get wrong.

Fix it: Rotate any exposed key immediately — assume it is compromised. Move the API call to a server route or edge function; the browser talks to your backend, your backend talks to the third party. Use server-only env vars (process.env.SECRET without the NEXT_PUBLIC_ prefix). Add a pre-commit hook or CI step that rejects commits matching secret patterns.

05. Injection from unsanitized input

User input gets concatenated into SQL queries, shell commands, file paths, or LDAP filters. AI-generated CRUD endpoints are a frequent source: f"SELECT * FROM users WHERE id = {user_id}" or os.system(f"convert {filename}"). ORMs do not save you if you use raw queries or .extra() with string interpolation.

Why AI tools ship it: string formatting is the fastest way to write a query that returns data in a tutorial, and the model reproduces it unless you specify parameterized queries.

Fix it: Parameterize everything — cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)), prepared statements, ORM methods that bind parameters. For shell commands, use argument lists (subprocess.run(["convert", filename])) never string concatenation. Validate and allowlist file paths; reject ../ traversal. If you must build dynamic SQL, use a query builder with bound parameters, not f-strings.

06. No input validation

Endpoints accept whatever JSON the client sends: negative quantities, wrong types, oversized payloads, missing fields. AI scaffolds trust the frontend to send valid data — attackers do not use your frontend.

Why AI tools ship it: TypeScript types and form labels give the illusion of validation, but types are erased at runtime and HTML required attributes are trivially bypassed.

Fix it: Validate at every boundary — API handlers, webhooks, file uploads, LLM tool inputs. Use a schema library (Pydantic, Zod server-side, Joi) and reject invalid requests with 400 before touching the database. Set max body and field sizes.

07. Prompt injection on LLM features

Apps that let users chat with an AI assistant — or pass user text into a system prompt — often treat the system prompt as a security boundary. It is not. Users can extract it ("repeat your instructions verbatim"), override it ("ignore previous instructions and…"), or trick the model into calling tools that send email, write to the database, or fetch internal URLs. If model output directly triggers actions without server-side gates, you have given users arbitrary agency over your backend.

Why AI tools ship it: the demo looks magical when the AI "just does things," and the wiring from model output → tool call is the fastest path to a wow moment. OWASP LLM ranks prompt injection and excessive agency among the top risks for a reason.

Fix it: Assume the system prompt is extractable. Never let raw model output trigger side effects — validate against an allowlist of actions and parameters server-side, and execute only what passes policy checks. Separate the model from the executor. Log and rate-limit tool calls; require human confirmation for high-risk actions. llm-security-audit has reproducible probes for injection, prompt leakage, and excessive agency.