Built with AI coding tools? A security checklist before you launch

Why AI-built apps need their own check

AI coding tools are very good at producing something that runs. They are less reliable at the parts nobody sees in a demo: who is allowed to read which record, where secrets live, and which packages get installed. A study presented at USENIX Security 2025 tested 16 code-generating models and found that the code they wrote named packages that do not exist at average rates of 5.2% for commercial models and 21.7% for open-source ones. Attackers now register those invented names and fill them with malware, a trick known as "slopsquatting". None of this means the app is bad. It means it has not been checked yet.

The twelve checks

1. 01

   Lock every table by default.

   If the app uses Supabase, Supabase's own guidance is to "enable RLS on every table in an exposed schema", because "a table in an exposed schema without RLS is readable and writable by any role with a grant on it". The same applies to Firebase security rules left in test mode and to any API that returns whole tables. How to check: sign in as one user and try to read another user's data through the public API.

2. 02

   Keep secrets out of the browser.

   Keys for AI models, payments and email must live on the server. How to check: search the built front-end files and the repository history for keys; rotate any key that was ever committed, even if it was deleted later.

3. 03

   Check access on every server route.

   Each request must prove the user may touch that specific record. How to check: change an ID in a request and see whether someone else's data comes back. Broken access control is first on the OWASP Top 10 for 2025.

4. 04

   Protect admin and account flows.

   Admin pages need a server-side check, not just a hidden button. Password reset, email verification and session expiry must work and expire.

5. 05

   Verify payments and webhooks.

   Check the signature on every payment webhook, and never trust a price or a plan sent from the browser.

6. 06

   Validate input on the server.

   Validate types and lengths on the server, use parameterised queries, and avoid rendering raw HTML from users.

7. 07

   Confirm every package is real and wanted.

   Check that each dependency exists, is the one you meant, is maintained and is pinned in a lockfile, then run your package manager's audit. Supply-chain failures are third on the OWASP Top 10 for 2025.

8. 08

   Secure the AI features inside the app.

   If the app sends user text to a model, assume prompt injection (first on the OWASP Top 10 for LLM applications, 2025), keep system prompts free of secrets, and put a spending cap and rate limit on every AI endpoint so one user cannot run up the bill.

9. 09

   Rate-limit what bots love.

   Sign-up, login, password reset, contact forms and AI endpoints all need limits.

10. 10

    Fail safely.

    Users should never see stack traces, and logs should contain neither passwords, keys nor more personal data than you need.

11. 11

    Prove you can restore.

    Turn on automatic backups, then restore one into a test environment. A backup that has never been restored is a hope, not a backup.

12. 12

    Own your accounts.

    Hosting, database, domain, AI provider and app-store accounts belong to the company, on a company card, with two-factor authentication. Apps built fast are often tied to one person's personal accounts.

Before investors ask

Technical due diligence asks the same questions in a different order: who can see what, where secrets live, what happens if the main developer leaves, and whether the code can be deployed by someone new. If you can answer the twelve checks with evidence, most of that conversation is already done.

When to bring in help

Fix what you can yourself, but get a second pair of eyes before launch if the app stores personal data, takes payments or is about to be shown to investors.