The OWASP Top 10, Read Through AI-Generated Code
Written By
SprintX Team
AI & Product Engineering
August 01, 2026
8 min read
A category-by-category translation of the OWASP Top 10 into the specific things Lovable, Cursor, Bolt and friends leave in your codebase.
The OWASP Top 10 is the closest thing application security has to a shared vocabulary. Every questionnaire references it, every auditor expects you to know it, and every version of it was written with hand-built software in mind.
Generated code changes the distribution. Some categories are near-universal in AI-built apps, a few are rarer than in traditional codebases, and one is effectively invisible to any tool that only reads code. Knowing which is which turns an abstract list into a work plan you can finish.
OWASP revises the list periodically and the category names shift between editions. The failure modes below do not, so treat the names as labels and the descriptions as the substance.
How generated code redistributes the risk
Two habits of code generators drive almost everything.
The first is that they write features, not invariants. A feature is describable in a prompt; an invariant — no customer ever reads another customer's row — is a property that must hold everywhere and was never stated. Categories that are really invariants get skipped wholesale.
The second is that they reproduce quickstart defaults. Tutorial code has permissive CORS, public buckets, verbose errors, wide-open database policies, and no rate limits, because tutorials optimize for the reader getting something working. That is the training data, and it is what you get.
The upside: some traditionally common categories are rarer now. Modern frameworks parameterize queries and escape output by default, so classic SQL injection and reflected XSS show up much less than they did a decade ago. The risk moved, it did not vanish.
The ten, translated
| Category | What it looks like in an AI-built app | How common |
|---|---|---|
| Broken access control | ID taken from the request, role checked only in the UI, open database policies | Near-universal |
| Cryptographic failures | Secrets in the client bundle, tokens in local storage, sensitive fields stored plain | Very common |
| Injection | Rarer in queries; appears in raw SQL escape hatches, shell calls, and model prompts | Occasional |
| Insecure design | No tenancy model, no threat model, trust decided per-endpoint | Universal by definition |
| Security misconfiguration | Wildcard CORS, debug endpoints live, stack traces returned, public buckets | Near-universal |
| Vulnerable and outdated components | Pinned-old versions, unmaintained packages, hallucinated names | Very common |
| Authentication failures | Sessions that never expire, reusable reset tokens, no lockout or rate limit | Common |
| Software and data integrity failures | Unpinned dependencies, unreviewed CI actions, no build provenance | Common |
| Logging and monitoring failures | No audit trail, no alerting, no way to reconstruct an incident | Near-universal |
| Server-side request forgery | Any "fetch this URL for me" feature, including AI summarizers | Growing fast |
The four that dominate
Broken access control
If you fix one category, fix this one. It is the most common finding, the most damaging, and the least visible to scanners — a query that fetches a record by ID looks identical whether or not the caller owns that record.
The test is two accounts and a swapped identifier. The fix is enforcement in a place every request passes through, backed by a default-deny data layer. The five shapes this takes, and how each gets written, are in why AI-generated apps keep shipping auth bypasses.
Security misconfiguration
Cheap to find, cheap to fix, and consistently present. Work through it as a list: lock CORS to your own origins, return generic error messages in production, remove seed and debug routes, make storage buckets private with expiring signed URLs, stop publishing source maps, add the standard security headers, and confirm no service-level credential is reachable from the browser.
Half an hour of work removes a third of a typical findings report. There is no reason for this category to be open on launch day.
Vulnerable components and supply chain
Two distinct problems arrive together. The ordinary one: generated projects pin whatever versions the model remembered, which are old by definition, and nobody has run an audit since.
The novel one: the Cloud Security Alliance found roughly 19.7% of 2.23 million AI-generated code samples referenced package names that do not exist. Attackers register the popular hallucinations and wait for an install. Verify that every dependency in your manifest is a real, maintained package from the publisher you expect — the mechanics are in slopsquatting and hallucinated packages.
Logging and monitoring failures
Nobody prompts for an audit trail, so nobody has one. The consequence only appears during an incident, when you cannot answer when it started, which accounts were affected, or whether it is still happening. That is also the moment it becomes a legal question rather than an engineering one.
Minimum viable: structured logs for every authentication event, authorization denial, admin action, payment event, and AI tool call, with a user ID and timestamp, retained somewhere searchable, plus alerts on error-rate spikes. Adding observability to an AI-built app covers the setup without turning it into a platform project.
The two that get underestimated
Insecure design is not a bug you can grep for. It is the absence of a decision — no one ever wrote down who may see what, what happens at the boundary between two customers, or which actions are irreversible. Every access-control bug downstream is a symptom of that gap. Writing a one-page rules document before you prompt for the next feature is the single highest-leverage security work available to a small team, because it gives the assistant the requirement it never had.
Server-side request forgery used to be a niche concern for enterprise apps. Now every product with a "summarize this link," "import from URL," or agent-with-a-browser feature has one. If your server fetches a URL a user supplied, an attacker can point it at internal addresses, cloud metadata endpoints, or your own private services. Allowlist the destinations, block private address ranges, and never return the raw response body to the caller.
The AI-specific layer on top
The classic ten do not cover what happens when a model can act. OWASP maintains a separate list for LLM applications, and three of its items belong on any 2026 review: prompt injection, insecure handling of model output, and excessive agency — an agent holding more permission than the task requires.
If your product has a chat feature, an agent, or any pipeline that reads untrusted text and then calls tools, treat that as its own review surface. The containment approach — scoped tool permissions, human confirmation on irreversible actions, egress allowlists — is in prompt injection is now your application security problem. And because model calls cost money, abuse control is a security control here too, which is the argument in rate limiting an AI app.
Working the list without stalling the product
Do not attempt all ten in one sprint. Sequence by exposure:
Week one, the unbounded and silent risks: exposed secrets, cross-tenant data access, unprotected endpoints. Week two, the cheap wins: configuration, headers, error handling, rate limits, dependency updates. Week three, the durable work: the rules document, logging and alerting, access-control tests in CI so the next generated feature cannot quietly reopen what you closed.
That last piece is what separates a codebase that stays secure from one that was secure in August. In an AI-assisted workflow the surface grows every time you prompt, so the controls have to be enforced by tests and pipelines rather than by remembering.
Frequently asked questions
Does passing the OWASP Top 10 mean my app is secure? It means you have handled the categories that account for most real-world breaches, which is a lot. It is a floor, not a ceiling — the list says nothing about your business-specific logic, your vendors, or your internal access practices. Buyers and auditors treat it as the shared baseline, so use it as one.
Which categories can I safely deprioritize in an early-stage app? If you handle no payment or health data and have a small surface, cryptographic storage concerns and advanced integrity controls can reasonably wait. Access control, misconfiguration, secrets, and logging cannot — those are exposed the day you deploy, users or not.
Do enterprise buyers ask about OWASP specifically? Constantly. Security questionnaires ask whether you test against the Top 10 and how you remediate findings. Having a dated, written pass with an owner per category answers the question far better than "yes," and it is the same artifact an auditor will ask for later.
If you have a generated codebase and a questionnaire that assumes someone has worked this list, the gap between those two is a defined, finishable project. SprintX maps AI-built apps against the Top 10, fixes what is open, and leaves you the tests that keep it closed — send us your repo or builder link.
