OWASP Top 10 for Vibe-Coded Apps (Plain English)

Vulnerability reports feel like a foreign language, and one term keeps showing up in the middle of them: the OWASP Top 10. If a scan result, a headline, or your own AI coding tool has mentioned it and you weren't sure what it meant, you're not alone, and it's worth ten minutes to close that gap.

OWASP is the Open Worldwide Application Security Project, a nonprofit that tracks web application risk. Its Top 10 is the industry's most-wanted list: the ten mistakes that get exploited most, in plain terms, used as a baseline industry-wide. It also doubles as a list of what AI coding tools get wrong, category by category, which this post covers, along with how to check your own app against it.

⚡ TL;DR

• The OWASP Top 10 is a plain-language list of the ten most common ways web apps get broken into, maintained by a nonprofit and used industry-wide as a baseline.
• Broken access control (letting someone see or touch data that isn't theirs) is both the top category on the list and the most common flaw in AI-generated code.
• Veracode found 45% of AI-generated code samples failed security tests or introduced an OWASP Top 10 vulnerability; a Carnegie Mellon benchmark found only a 10.5% security pass rate even in code that worked correctly.
• A passive, read-only scan can catch several categories (exposed secrets, missing headers, outdated components) before you ship; broken access control usually needs a live test.

What is the OWASP top 10, exactly?

OWASP publishes the Top 10 as a periodically updated ranking of the most critical web application risks, drawn from data contributed by security firms across the industry. It isn't a law, but auditors, compliance frameworks, and AI coding assistants cite it so widely that it has become shared vocabulary for what can go wrong with a web app. Each category is a pattern of failure, not a single bug, which is why it keeps reappearing across unrelated apps and stacks.

The OWASP Top 10, explained in plain English

A01: Broken access control

Broken access control means your app doesn't check whether the person asking for something is actually allowed to have it: someone else's order, another tenant's dashboard, an admin action fired from a regular account. It's the OWASP Top 10's number one category, and the most common flaw in AI-generated code, because building the feature that works when you're logged in as yourself is easy, and rejecting every other case is not. On Supabase-backed apps this usually traces back to missing or overly permissive Row Level Security (RLS); see broken access control for a deeper look. It's also the gap an early version of our own active-scanning agent used to miss, since proving it needs judgment about intent, not a pattern match. After reworking how the agent reasons about unauthenticated data access, it now catches that flaw on every run.

A02: Cryptographic failures

This covers sensitive data left unprotected: unencrypted connections, weak hashing, or, the pattern we see most in vibe-coded apps, a server-side secret key that never should have left the backend, sitting in plain text inside the browser bundle. A Stripe sk_live_ key, a Supabase service_role key, or a raw OpenAI or AWS credential shipped to the frontend all fall here. A Supabase anon key or Firebase web config, by contrast, is meant to be public, so its presence alone isn't a failure.

A03: Injection

Injection happens when user input gets treated as executable code instead of plain data, the classic example being SQL injection, with cross-site scripting (XSS) also falling in this category. Veracode's 2025 GenAI Code Security Report found this pattern in AI-generated code at scale: cross-site scripting showed up in 86% of applicable code samples across the models it tested.

A04: Insecure design

Insecure design is a flaw baked in before a single line of code runs: a safeguard the architecture never accounted for, not a bug you patch later. Tenzai's December 2025 test of 15 apps across Cursor, Claude Code, Replit, Devin, and OpenAI Codex found zero implemented protection against cross-site request forgery (CSRF), where a malicious site tricks a logged-in user's browser into acting on the attacker's behalf.

A05: Security misconfiguration

The catch-all for unsafe defaults left switched on: missing security headers, permissive cross-origin rules, error messages that hand an attacker a stack trace, or an admin panel reachable with no extra protection. The same Tenzai test found none of the 15 apps set basic security headers at all.

A06: Vulnerable and outdated components

Every app leans on third-party libraries, and this category covers the ones with known, published holes that never got patched. AI tools scaffold quickly from a template and rarely revisit dependency versions afterward. Our own scanner-validation test ran into this directly: the deliberately vulnerable build used a Next.js version carrying a known CVE (CVE-2025-29927), and the host's supply-chain gate blocked the deploy before it went live.

A07: Identification and authentication failures

This covers weak login and session handling: no rate limit on password attempts, predictable session tokens, or a way to skip verification altogether. Base44 hit this in July 2025, when Wiz Research found a public app_id combined with undocumented registration and OTP-verification endpoints let anyone create a verified account inside someone else's private app, bypassing single sign-on. Wix patched it in under 24 hours.

A08: Software and data integrity failures

This is about trusting code, updates, or a deployment pipeline without verifying they haven't been tampered with, including insecure deserialization, where an app rebuilds data into objects without checking what it's being handed. It's harder to see than the other categories, which is exactly why a fast build skips it.

A09: Security logging and monitoring failures

If your app doesn't record who did what, a breach can run for months before anyone notices, because there's no alarm to trip. Veracode's research found the opposite happening in AI-generated code: log injection, attacker-controlled text that corrupts your own log entries, showed up in 88% of applicable samples. The system meant to help you detect an attack was undermined at the source.

A10: Server-side request forgery (SSRF)

SSRF tricks your server into making a request on the attacker's behalf, often reaching internal systems the attacker couldn't touch directly on their own. Tenzai's test found this was the one flaw every tool introduced: all 15 apps across all five coding tools carried at least one SSRF vulnerability.

Why AI-generated code keeps landing on this list

None of this is a knock on any one tool. Veracode tested more than 100 large language models across 80 coding tasks and found 45% of the resulting code samples failed security tests or introduced an OWASP Top 10 vulnerability. As Veracode's CTO Jens Wessling put it: "Our research reveals GenAI models make the wrong choices nearly half the time, and it's not improving."

Passing your own tests doesn't mean you dodged the list, either. Carnegie Mellon's SusVibes benchmark found its best-performing agent and model combination hit a 61% functional pass rate (the code works) but only a 10.5% security pass rate (the code is also safe). More than eight in ten working solutions still carried a flaw on this list. See why AI code is insecure and 45% of AI-generated code is vulnerable for more.

How to check your own app against the OWASP top 10

A few of these categories are checkable from your own browser in a few minutes, no security background required:

• A02, secrets: open your site's dev tools and search your JS bundles for sk_live_, service_role, or a raw AI-provider or cloud key.
• A05, headers: check your main document's response headers for Content-Security-Policy and X-Frame-Options.
• A06, components: check whether your framework version has a known CVE against it.
• A01, access control: log in as yourself, open a page with an ID in the URL, then swap it for one that isn't yours and reload.

The last one is hardest to check by hand: "it looked fine when I tried it" isn't the same as "it's enforced for every ID." It's the category a passive check catches least reliably, and where a live test matters most.

The false alarm to skip

🐺 Not a real problem

A Supabase anon key or Firebase web config showing up in your results is not a cryptographic failure. Both are meant to sit in your browser code. The real question is what's standing behind that key: whether the RLS policies or security rules actually restrict rows to their rightful owner. A checklist that can't tell the difference sends you chasing the wrong fire.

FAQ

Is the OWASP top 10 only relevant to professional developers?

No. It was written for developers, but the categories describe outcomes anyone can grasp: can a stranger see data that isn't theirs, is a secret key exposed, does the app trust input it shouldn't. Reading code isn't required to understand what each category means for your app.

Does the OWASP top 10 actually apply to apps built with AI tools?

Yes, more directly than most expect. The list describes outcomes, not who wrote the code. Veracode found 45% of AI-generated samples introduced an OWASP Top 10 vulnerability, and a separate benchmark found only a 10.5% security pass rate even among functionally correct solutions.

Which OWASP top 10 category should I worry about most?

Broken access control. It's ranked first on the list, it's the flaw class we see most in AI-generated apps, and unlike a missing header or an outdated library, it usually means real user data reaching someone who shouldn't have it.

The bottom line

The OWASP Top 10 is a plain list of the ten ways attackers most often get in, and it maps closely onto what AI coding tools get wrong, starting with broken access control. An attacker can walk this list against your live app in minutes. Read the full picture in the vibe coding security guide, then find out which of these ten your own app is exposed on, before someone else does.