The security gaps we find most in AI-generated apps

AI coding tools are brilliant at producing working features. They are far less reliable at producing safe ones — because a demo never asks whether a stranger could abuse it.

Across the AI-generated codebases we review, the same handful of vulnerabilities appear again and again. None of them are exotic. All of them are the kind of thing an automated scanner or a bored attacker finds in minutes. Here are the ones worth checking before anyone but you touches your app.

1. Secrets committed to the repository

API keys, database passwords and third-party tokens pasted directly into source — and then pushed to a Git host, often a public one. Once a secret is in history, rotating the file is not enough; the secret itself must be revoked and replaced. This is the single most common finding, and the most immediately dangerous.

2. Missing or broken authorization

Authentication answers "who are you?"; authorization answers "are you allowed to do this?" AI-generated code frequently implements the first and skips the second. The result is endpoints that check you are logged in but not that the record you are editing is yours — so any user can read or modify any other user's data by changing an ID.

3. Unvalidated input and injection

String-concatenated SQL, unsanitised HTML rendered straight to the page, user input passed to a shell or a template engine. These lead to SQL injection, cross-site scripting and remote code execution. Parameterised queries and output encoding are the fix — but they have to be applied everywhere, not just where it was convenient.

4. No rate limiting or abuse controls

Without limits, a single actor can hammer your login endpoint (credential stuffing), your signup flow (spam and cost), or your expensive AI calls (a surprise invoice). Rate limiting, captchas on sensitive actions and per-account quotas are cheap to add and painful to omit.

5. Over-permissive CORS and headers

Access-Control-Allow-Origin: * on an authenticated API invites other sites to make requests on your users' behalf. Missing security headers (HSTS, content-type options, frame options) leave easy openings. These are one-line fixes that are almost always missing.

6. Vulnerable dependencies

The code your tool generated may be fine; the packages it pulled in may not be. Outdated or abandoned dependencies with known CVEs are a standard entry point. This needs continuous attention, not a one-time check — new advisories land weekly.

The messier the app, the more a scan is worth. There is no judgement in finding these — only a plan to close them.

Why this happens — and why it isn't your fault

An AI model generating code is optimising for "does this satisfy the request?" not "could this be abused by a motivated stranger?" Security is an adversarial property: it depends on what an attacker could do, which is information that never appears in the prompt. Expecting a prototype to be secure by default is like expecting a first draft to be legally watertight.

How to close the gaps

• Scan before you ship. An automated assessment surfaces committed secrets, injection points, missing authorization and vulnerable dependencies in one pass.
• Fix by severity. Revoke exposed secrets and close authorization holes first — those are the ones that cause breaches.
• Add the boring controls. Rate limiting, security headers, input validation and dependency monitoring are cheap insurance.
• Keep watching. Security is not a milestone you pass once. Under a managed production arrangement, someone stays responsible for the new advisories and the changes you keep shipping.