Application security audit checklist: the OWASP Top 10 in plain English for AI-built apps

An application security audit checklist is a list of yes-or-no tests that show whether your app protects its users' data, its accounts and its money. For an app built with Lovable, Bolt, v0, Cursor or Replit, the most useful version follows the OWASP Top 10, the industry's standard list of the most common web application risks, and turns each item into something a non-technical founder can actually check. This post does exactly that: ten categories, a plain-English explanation of each, and a pass-or-fail test you can run yourself.

You do not need to read code for most of it. You need a browser, two test accounts and about an hour. If you want a faster first pass, start with our free self-check: ten questions, no passwords or links required, and you get a traffic light for security, privacy, speed and backups. Then come back here for the deeper tests.

What the OWASP Top 10 is, and why it suits AI-built apps

OWASP (the Open Worldwide Application Security Project) is a non-profit that publishes free security guidance. Its Top 10 list, updated for 2025, ranks the risk categories that show up most in real web applications. The 2025 list is:

1. A01 Broken Access Control 2. A02 Security Misconfiguration 3. A03 Software Supply Chain Failures 4. A04 Cryptographic Failures 5. A05 Injection 6. A06 Insecure Design 7. A07 Authentication Failures 8. A08 Software or Data Integrity Failures 9. A09 Security Logging and Alerting Failures 10. A10 Mishandling of Exceptional Conditions

AI builders are good at producing working features and less consistent at the invisible rules around them. That is why the list maps so well: most of the problems we find in AI-built apps fall into the first few categories.

The application security audit checklist, item by item

For each item: what it means, what it looks like in an AI-built app, and a test. Mark each one Pass, Fail or Not sure. "Not sure" counts as a fail until someone checks.

1. Broken Access Control: can users see what is not theirs?

Plain English: the app lets someone open, change or delete data that belongs to another user, or reach admin features without being an admin.

In AI-built apps: database tables without proper per-user rules, record IDs in the URL that anyone can change, admin pages that are only hidden from the menu.

Test: create two normal accounts. As user A, create a record. As user B, try to open it by changing the ID in the address bar. Then, as a normal user, type the admin page address directly. *Pass:* both attempts are refused. Our two-account test walks through this step by step.

2. Security Misconfiguration: are the defaults still on?

Plain English: settings left at insecure defaults, debug screens in production, open storage, missing security headers.

Test: open your live site, press F12, go to the Network tab, reload, click the main page request and look at Response Headers. Look for Strict-Transport-Security and Content-Security-Policy. Then visit a page that does not exist and an obviously broken URL. *Pass:* security headers are present, and error pages do not show stack traces, file paths or database messages.

3. Software Supply Chain Failures: are your packages trustworthy and current?

Plain English: your app depends on hundreds of open-source packages. If one is vulnerable or malicious, so is your app.

In AI-built apps: frameworks that are several security releases behind, and packages added by an AI agent that nobody reviewed. Popular frameworks now ship security fixes on a schedule. Next.js, for example, moved to a formal security release process in July 2026, with scheduled releases announced about a week ahead, and on October 27 announced a release of seven medium-severity fixes for November 3, 2026.

Test: in your GitHub repository, open Settings, then Code security, and confirm Dependabot alerts are on. Check the Security tab for open alerts. *Pass:* alerts are on, someone receives them, and there are no open critical or high alerts older than a week.

4. Cryptographic Failures: is sensitive data protected?

Plain English: data sent or stored without proper encryption, or secrets stored where they can be read.

Test: confirm every page loads over https:// and that http:// redirects to it. Then search your built JavaScript for secret key prefixes, as described in our post on secrets leaking into the browser. *Pass:* HTTPS everywhere and no server-only keys in browser code.

5. Injection: can user input become a command?

Plain English: text typed by a user is treated as code or a database query.

Test: in a search box or comment field, type a short string containing quotes and angle brackets, such as "test'. *Pass:* it shows up as plain text, unchanged, and the page does not break or show a database error. If the text appears in bold, the app is rendering user input as HTML, which needs a developer to look at it.

6. Insecure Design: does the business logic hold?

Plain English: the code works as written, but the design allows abuse. Examples: a free trial that resets with a new email, a discount code with no usage limit, a success page that grants paid features without a confirmed payment.

Test: list the three ways your app gives out value (paid features, credits, invites). For each, ask "how would someone get this without paying or without permission?" and try it. *Pass:* each attempt is blocked on the server.

7. Authentication Failures: are logins solid?

Plain English: weak sign-in, no limits on password guessing, sessions that never expire, password reset flows that leak whether an email exists.

Test: try ten wrong passwords in a row on a test account. Sign out and press the browser Back button. Request a password reset for an email that does not exist. *Pass:* repeated attempts are slowed or blocked, signed-out pages do not reload private data, and admins have multi-factor authentication enabled.

8. Software or Data Integrity Failures: can someone fake an event?

Plain English: the app trusts data or updates it should verify, such as unsigned webhooks or auto-updated scripts from third-party sites.

Test: if you take payments, confirm paid status changes only after a verified webhook from the payment provider. Ask your builder or developer to show you where the signature check happens. *Pass:* you can point to it.

9. Security Logging and Alerting Failures: would you know?

Plain English: something bad happens and nobody notices because nothing was logged or nobody gets an alert.

Test: ask yourself, "If someone downloaded our customer list last night, how would we find out?" *Pass:* sign-ins, admin actions and errors are logged somewhere you can search, and at least one alert (errors, unusual sign-ups or spend) reaches a real person.

10. Mishandling of Exceptional Conditions: what happens when things fail?

Plain English: when an error occurs, the app fails open (lets the action through), leaks details, or leaves data half-written.

Test: turn on airplane mode mid-checkout or mid-save, then reconnect. Submit a form twice quickly. *Pass:* you do not get duplicate charges or half-saved records, and error messages are friendly without technical detail.

How to score your results

Count your fails and "not sure" answers:

• Any fail on items 1, 4 or 8: fix before taking more users or payments. These are the categories where one gap can expose every customer or every payment.
• Fails only on items 2, 3, 7 or 9: schedule fixes this month. They raise risk steadily rather than all at once.
• Fails only on items 5, 6 or 10: have a developer review the specific screens involved.
• More than three "not sure": that is a signal in itself. Nobody on the team has a full picture of the app's security, which is exactly what an outside review is for.

What this checklist cannot do

A self-run checklist catches the common, visible problems. It will not reliably find issues buried in server code, complex permission rules across many tables, or flaws that only appear under specific timing. It is also not a penetration test or a compliance certification. For a deeper review against a recognized standard, OWASP's Application Security Verification Standard (ASVS) lists detailed requirements at several levels, and an experienced reviewer can test against it.

That is where our Launch-Ready Check fits: a senior engineer runs these tests and the ones a browser cannot reach, then gives you a plain-English report and a fix plan.

Quick checklist

• Run the free self-check first for a traffic-light view.
• Do the two-account test and the admin URL test.
• Check security headers and error pages in DevTools.
• Turn on Dependabot alerts and keep your framework on the latest security release.
• Search browser code for secret keys.
• Try abusing your own free trial, credits and success page.
• Confirm payments rely on verified webhooks.
• Decide how you would find out about a data breach.

FAQ

How often should I run an application security audit checklist?

Run it before launch, before taking payments, and after any large AI-generated change. A quarterly re-run is a sensible habit for a live app.

Is the OWASP Top 10 enough for a small app?

It is the right starting point because it covers the most common risks. It is an awareness list, not a complete standard. For a deeper review, OWASP's ASVS is the more detailed reference.

Can my AI builder fix the failures for me?

Often, yes, if you describe the failed test precisely. Re-run the same test afterwards; a fix that was only described in chat is not a fix until the test passes.

---

Security audits do not have to start with jargon. Take the free self-check to see where you stand in a few minutes, then book a free technical assessment. A senior engineer will go through your results with you and tell you which fixes matter first.