The OWASP Top 10 applied to apps built with AI tools
Each OWASP Top 10:2025 risk explained in plain words, how it tends to appear in Lovable, Bolt, Cursor or Replit apps, and what to check in your own.
Leer en español →
The OWASP Top 10 is the most widely used list of web application security risks, and the 2025 edition applies to apps built with Lovable, Bolt, Cursor, Replit or v0 just as it does to hand-written ones. In AI-built apps the same few items show up again and again: broken access control (users reaching data that isn't theirs), security misconfiguration (open database rules, test settings in production), supply chain problems (unreviewed packages) and authentication flaws. The rest still matter, but those four are where to look first.
Below, each of the ten categories gets a plain explanation, the form it usually takes in an AI-built app, and one or two things you can check yourself.
What is the OWASP Top 10?
It is a ranking published by OWASP, a non-profit foundation, of the most critical security risks for web applications, based on data from real applications and a community survey. It is not a checklist or a standard you certify against; it is a shared vocabulary for "the things that most often go wrong". The current list is the OWASP Top 10:2025.
A01 Broken Access Control
What it means: users can do or see things they shouldn't, such as reading another customer's invoices or calling an admin action.
In AI-built apps: this is the most common serious problem. The interface hides the button, but the database or API answers anyone who asks. Supabase tables with Row Level Security off, or with a policy like using (true), are the classic case. The 2025 list also folds server-side request forgery (making your server fetch a URL an attacker chose) into this category.
Check: sign in as user A, copy the ID of one of their records, sign in as user B and request it. Our guide on a user seeing another user's data walks through this.
A02 Security Misconfiguration
What it means: insecure settings rather than buggy code.
In AI-built apps: storage buckets set to public, CORS open to every origin, debug or verbose error pages in production, default email settings, a test Stripe key on the live site, preview deployments with real data and no password.
Check: go through each dashboard you use (database, hosting, auth, storage) and read the security-related settings one by one, with production in mind.
A03 Software Supply Chain Failures
What it means: risk that comes from the code you didn't write: packages, build tools, plugins and the services that deliver them.
In AI-built apps: agents install packages freely, sometimes ones that are abandoned, misspelled or not needed at all. Lockfiles get deleted to "fix" an install error.
Check: look at your package.json and ask what each dependency is for. Keep the lockfile in Git, enable dependency alerts in GitHub, and be suspicious of a package you've never heard of with very few downloads.
A04 Cryptographic Failures
What it means: data that should be protected isn't, through missing or weak encryption.
In AI-built apps: this is mostly handled for you (HTTPS from the host, passwords hashed by the auth provider). Problems appear when the AI writes its own login system, stores passwords or tokens in plain text, or keeps sensitive fields in localStorage.
Check: if your app has its own password table instead of a managed auth service, get it reviewed.
A05 Injection
What it means: user input treated as code or commands, including SQL injection and cross-site scripting (XSS).
In AI-built apps: raw SQL built by string concatenation in a server function, user content rendered with dangerouslySetInnerHTML, and, for AI features, prompt injection, which we cover in prompt injection in your app.
Check: search the code for dangerouslySetInnerHTML, innerHTML and SQL strings with ${ inside them.
A06 Insecure Design
What it means: the flaw is in how the feature was planned, not how it was coded.
In AI-built apps: a referral credit anyone can claim repeatedly, a free trial that resets when you change email, a price sent from the browser and trusted by the server, an invite link that never expires.
Check: for each feature that involves money, credits or permissions, ask "what happens if someone does this a thousand times, or changes the number in the request?"
A07 Authentication Failures
What it means: weaknesses in how users prove who they are.
In AI-built apps: no limit on login attempts, weak password rules, password reset links that don't expire, sessions that survive a password change, no second factor on admin accounts. See our guides on a secure password reset flow and two-factor authentication.
Check: try the reset flow end to end and confirm the link works once only.
A08 Software or Data Integrity Failures
What it means: trusting code or data without checking it hasn't been tampered with.
In AI-built apps: webhook endpoints that don't verify the signature (anyone can send a fake "payment succeeded"), scripts loaded from random CDNs, auto-updates without review.
Check: confirm every webhook handler verifies the provider's signature before acting.
A09 Security Logging and Alerting Failures
What it means: attacks or abuse happen and nobody notices.
In AI-built apps: no error tracking, no record of admin actions, no alert when sign-ups or AI usage spike.
Check: could you tell, today, who changed a given user's role last week? Our guide on monitoring and error tracking covers a lightweight setup.
A10 Mishandling of Exceptional Conditions
What it means: the app behaves unsafely when something goes wrong, such as failing open, leaking details in error messages, or leaving data half-written.
In AI-built apps: a permission check wrapped in try/catch that lets the user through on error, a payment flow that grants access when the provider times out, stack traces shown to users.
Check: look for catch blocks that return success, and make sure errors shown to users are generic while details go to your logs.
Which items should I fix first?
| If your app has… | Start with |
|---|---|
| User accounts and private data | A01, A02 |
| Payments or credits | A06, A08 |
| An admin area | A01, A07 |
| AI features | A05 (prompt injection), plus usage limits |
| Many packages added by an agent | A03 |
Quick answers
Is OWASP compliance a certification? No. The Top 10 is an awareness document. Following it is good practice, not a certificate.
Do AI tools write insecure code on purpose? No. They aim for code that works in the preview, and many of these risks only show up when someone actively misuses the app.
Can I check all ten myself? You can check the symptoms listed here. A full review needs someone to read the code and the database rules. Our guide on reviewing AI-generated code helps with the first pass.
Where to go from here
The free health check covers what is visible from outside your app. For a person to go through access control, database rules and the rest of this list in your code, see our Supabase security review, or get in touch if your stack is different.
