Is my AI-built app secure? 12 checks before real users

Lovable, Bolt, Cursor, Replit, v0 and Claude have made it possible to build a working app in a weekend. That is real progress. But “it works” and “it is safe to put real people’s data in it” are different questions.

What the research says

Studies find a large share of AI-generated code with security flaws. Veracode’s 2025 GenAI Code Security Report tested code written by many language models for common tasks and found that about 45% of the samples contained a security flaw, mostly from well-known OWASP Top 10 classes such as injection and cross-site scripting. The report also notes that newer and larger models were not noticeably better at security.

A second risk is less obvious. In the paper “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs” (USENIX Security 2025), researchers found that roughly one in five packages recommended in their sampled code did not exist. Attackers can register those invented names and fill them with malware, a trick now called slopsquatting. If your AI tool tells you to install a package nobody has heard of, check before you run the command.

None of this means AI code is always insecure. It means you should check it like code from a fast, confident junior developer who never asks about security unless you do.

The 12 checks

1. Secrets in the frontend or the repository

Search your code and your Git history for API keys, database passwords, service-role keys and tokens. Anything in the frontend bundle is public: anyone can open the browser’s developer tools and read it. Payment, email and AI provider keys must live only on the server or in your platform’s secret store. If a secret was ever committed, rotate it; deleting the line is not enough because Git keeps history.

2. Row-level security in Supabase or Firebase

This gap alone can expose your whole database. With Supabase, the anonymous key is shipped to the browser by design. Without row-level security (RLS) enabled on each table, and correct policies, anyone with that key can read or change every row. With Firebase, check that your security rules are not left in test mode (allow read, write: if true). Test it: log in as one user and try to read another user’s records directly through the API.

3. Authentication and sessions

Use your platform’s built-in authentication instead of a home-made login. Check that passwords are never stored in plain text, sessions expire, logout really ends the session, password reset links are single-use and expire, and session tokens are not stored where any script can read them if you can avoid it.

4. Authorization on every API route

Being logged in is not the same as being allowed. For every route or server function, ask: does this check that the current user owns the thing they are asking for? The classic failure is IDOR (insecure direct object reference): change /api/invoices/1041 to /api/invoices/1042 and you see someone else’s invoice. AI tools often generate the happy path and skip this check. Admin-only actions need an explicit role check on the server, not just a hidden button.

5. Input validation and injection

Validate every input on the server: type, length, format. Use parameterised queries or your ORM, never string-built SQL. Escape output to prevent cross-site scripting, especially where you render user content or Markdown. If you pass user text to an AI model that can call tools, treat it as untrusted too.

6. Rate limiting

Login, sign-up, password reset, contact forms and any endpoint that calls a paid API need limits. Without them, someone can guess passwords, flood your inbox or run up your AI or SMS bill overnight. Most platforms and CDNs offer rate limiting; turn it on.

7. Dependencies and hallucinated packages

Run your package manager’s audit (npm audit, pip-audit or similar) and fix critical issues. Then read your dependency list: does every package exist, is it the one you meant, does it have real usage and a maintained repository? Remove anything you do not use. Commit a lock file so builds are repeatable.

8. CORS

Cross-origin rules decide which websites may call your API from a browser. Access-Control-Allow-Origin: * combined with cookies or credentials is a common AI-generated shortcut. Allow only your own domains.

9. File uploads

Limit file size and type, check the content and not just the extension, store uploads outside the code directory or in object storage, and never execute them. Make sure uploaded files are private by default when they belong to a user, and serve them through signed or authorised links.

10. Error messages and logs

Production errors should not show stack traces, SQL queries or environment variables to users. In the other direction, check that your logs do not collect what they should not: passwords, full card numbers, tokens, or more personal data than you need. Logs are often the least protected copy of your data.

11. Backups and restore

Find out whether your database is backed up, how often, where, and for how long. Then restore a backup to a separate place and check that it works. Many hosted platforms include backups only on paid plans or keep them for a short time. Decide how much data you could afford to lose, and set the schedule to match.

12. Admin panels and default credentials

Look for admin dashboards, database consoles, debug routes and test accounts that the AI or a template created. Remove what you do not need, and put the rest behind strong authentication, ideally with MFA or an IP allow-list. Change every default password and remove seed users such as admin@example.com before launch.

How to run these checks

Work through the list in this order: 1, 2, 4 first, because they expose data. Then 3, 5, 6, 7. Then the rest.

For each item, write down what you checked and what you found. That short record is useful later, when a customer, investor or partner sends a security questionnaire.

You can ask your AI tool to help fix each finding. Give it a precise task: “Add a check to every route under /api/projects that the project belongs to the current user, and add a test that fails for another user’s project.” Then verify the fix yourself.

When to get help

If your app handles payments, health data, children’s data, or personal data of people in the EU, or if you are about to raise money or sign a larger customer, an independent review is worth it. Our security audit for AI-built apps covers these twelve areas and more, and every finding comes with a concrete fix.