AI-generated code is not insecure because an AI wrote it. It is risky because it is usually produced faster than anyone reviews it, by a tool that optimises for “it works” rather than “it is safe”. Whether your app is secure depends on what the code actually does once deployed. This checklist shows how to assess that, area by area, with each check mapped to the relevant OWASP category so you can prioritise what you find.
Key takeaways
- Test behaviour, not just code. Many serious flaws only show up when you use the running app as an attacker would.
- Start with access control and secrets. They cause the most damaging incidents in AI-built apps.
- AI features add their own risks. Prompt injection and over-privileged agents need separate checks.
- Fix at the right layer. Server and database rules protect data; hiding UI elements does not.
Assess the app you have, not the reputation of AI code
Search results on this topic are full of alarming percentages about AI code, many of them hard to trace to original research. They are not much use for deciding what to do on Monday. What helps is a structured look at your own application: what it exposes, who can call it, what it trusts, and what it does when things fail.
The OWASP Top 10:2025 is a good frame because it reflects what actually goes wrong in web applications. Its top three are Broken Access Control, Security Misconfiguration and Software Supply Chain Failures, which are also the three areas where AI-built apps most often need work.
The checklist
1. Exposed credentials (Security Misconfiguration)
- Search the deployed JavaScript, not just the repository, for API keys, tokens and connection strings. Build tools such as Vite inline any
VITE_variable into client code, and the Vite docs warn these should not hold secrets. - Check git history, not just the current files. A key deleted in the latest commit is still in earlier ones.
- On Supabase, confirm the secret (service role) key, which bypasses Row Level Security, is used only on the server.
- Rotate anything that was ever exposed, then enable push protection or an equivalent scanner to catch the next one before it is committed.
2. Access control (Broken Access Control)
- For every API route and database table, write down who should be allowed to read and change it. Compare that with what the code and policies actually enforce.
- Test with two ordinary accounts and one admin. Try reading, editing and deleting another user’s records by changing IDs in requests.
- Check admin-only routes from a non-admin session. Generated code often protects the admin page but not the API calls behind it.
- On Supabase, confirm RLS is enabled on every table in exposed schemas and that policies cover select, insert, update and delete. The Supabase RLS guide explains that without RLS, any role with a grant can read and write the table.
3. Insecure API endpoints
- List every endpoint, including serverless functions the builder created automatically. Unused ones should be removed, not just unlinked.
- Confirm each endpoint requires authentication unless it is deliberately public.
- Check rate limiting on login, sign-up, password reset and anything that costs money per call, such as AI or SMS endpoints.
- Verify webhooks. A payment webhook that does not check its signature lets anyone mark an order as paid. Stripe documents how to verify signatures using the raw request body.
4. Unsafe input handling (Injection)
- Validate all input on the server: types, lengths, formats and allowed values.
- Look for SQL built by joining strings, and for raw HTML rendered from user content. Use parameterised queries and your framework’s escaping instead.
- Check file uploads: allowed types, size limits, where files are stored and whether uploaded files can be executed or served from your main domain.
5. Dependencies (Software Supply Chain Failures)
- Review every package in your manifest. Remove ones you do not use, and question unfamiliar names: AI tools occasionally suggest packages that do not exist, which attackers can register.
- Run npm audit or your ecosystem’s equivalent, and commit the lockfile so builds are reproducible.
- Turn on automated dependency alerts so new advisories reach you after launch.
6. Error handling (Mishandling of Exceptional Conditions)
- Trigger errors deliberately and check users never see stack traces, SQL errors or internal paths.
- Check that failures fail closed. If a permission lookup throws, access should be denied, not granted by default.
7. Logging and alerting (Security Logging and Alerting Failures)
- Log authentication events, permission denials and admin actions, with timestamps and user IDs.
- Keep passwords, tokens and unnecessary personal data out of logs.
- Make sure unusual patterns, such as many failed logins, alert a person.
8. AI features inside your app
If your product itself calls a language model, there is a second list to check. The OWASP Top 10 for LLM and Generative AI Applications puts prompt injection first and sensitive information disclosure second.
- Assume any text the model reads, including documents, emails and web pages, may contain instructions meant to manipulate it.
- Give AI features and agents the minimum permissions they need. An assistant that only answers questions should not hold credentials that can delete records.
- Check the model cannot reveal data the current user is not allowed to see.
- Set spending limits and per-user rate limits on AI calls, which also limits abuse.
How to prioritise what you find
| Finding | Typical severity | Fix first because |
|---|---|---|
| One user can read or change another’s data | Critical | Direct data breach |
| Secret key in client code or git history | Critical | Account takeover, unexpected costs |
| Unverified payment webhook | High | Fraudulent orders or access |
| No rate limit on login or paid endpoints | High | Credential stuffing, runaway bills |
| Vulnerable dependency with a known exploit | High to medium | Depends on whether the code path is used |
| Stack traces shown to users | Medium | Helps attackers map your system |
| Missing security logging | Medium | You cannot investigate incidents |
Severity depends on context. A vulnerable package in a build tool that never runs in production is less urgent than one in your request handler. When in doubt, ask: what is the worst realistic thing someone could do with this, and how easily?
What a checklist cannot tell you
This checklist covers the issues we find most often in AI-built apps. It does not replace threat modelling for your specific product, an independent review, or a penetration test where your customers or regulators expect one. If you are curious what a structured review involves, we explain it step by step in what happens during a website or SaaS security audit. For the non-security items to sort before launch, see 10 things to fix before launching an AI-built app.