AI coding tools such as Lovable, Bolt, Cursor, v0 and Replit can take you from an idea to a working app in a weekend. What they cannot do is tell you whether that app is safe to put in front of real users. The model builds what you ask for and checks it the way you check it: by clicking through the happy path in the preview, signed in as yourself. Security problems do not show up there. They show up when someone else opens the browser console.
We review apps built this way, and the same problems come up again and again. Here is the checklist we would run before launch. Each item says what goes wrong, how to check it yourself and what the fix looks like. None of it needs a security background, only the willingness to test your app the way a stranger would.
1. Database rules: can a stranger read your tables?
Apps built on Supabase or Firebase let the browser query the database directly. That is safe only if the database rules are right: Row Level Security policies on Supabase, Security Rules on Firebase. The most common serious finding in AI-built apps is a table with no rules or with rules that allow everything, such as using (true) on Supabase or allow read, write: if true; on Firebase.
Check: in Supabase, open Advisors → Security Advisor. In Firebase, read your rules in the console and look for if true or test-mode rules with a date. Fix: every table gets rules that tie each row to the user or team that owns it. Our guides to Supabase RLS mistakes and Firebase Security Rules mistakes show how.
2. Secret keys in the browser
To make a feature work quickly, an AI tool will happily call OpenAI, Stripe or your database's admin API straight from the frontend, with the secret key in the code. Anything in the frontend is public: anyone can find the key and use it on your account and your bill.
Check: open your live site, press F12, and search all sources (Ctrl+Shift+F) for sk_, sk-, service_role, secret and AKIA. Watch the Network tab: a request from the browser straight to api.openai.com means your key is in the browser. Fix: rotate the key, then move that call to a server route or edge function. Details in our guide to exposed API keys.
3. .env files and git history
AI tools generate .env files full of keys, and it is easy to commit one by accident, especially when the tool syncs your project to GitHub for you. Deleting the file later does not help: it is still in the history.
Check: make sure .env is in .gitignore, search your history with git log --all -p -S "sk_live" (repeat for your other key prefixes), and confirm that https://your-app.com/.env returns an error, not a file. Fix: rotate anything that was ever committed, and use your host's environment settings for secrets.
4. Admin pages that are only hidden
A typical AI-generated admin area checks whether the user is an admin in the React code and hides the button if not. But the page, and more importantly the API calls behind it, are still there. Hiding a button is not access control.
Check: sign in as a normal user and open the admin URL directly. Then call the admin API endpoints or database tables the admin page uses, from that normal account. Fix: check the role on the server or in the database rules for every admin action, using a role that users cannot set themselves.
5. Other users' data, one ID away
If your app loads an invoice from /api/invoices/1042, try /api/invoices/1041. Apps that check "is someone signed in?" but not "does this record belong to them?" leak every customer's data to anyone who can count. This mistake is so common that it has its own name: insecure direct object reference, or IDOR.
Check: create two test accounts and try to read and change account B's records while signed in as account A. Fix: every query filters by the signed-in user (or their team) on the server or in the database rules, never only in the frontend.
6. Server routes and edge functions without checks
AI tools create API routes, serverless functions and Supabase Edge Functions quickly, and often without an authentication check, because the frontend that calls them is behind a login. The route itself is public, though.
Check: call each route with no session at all, for example with curl. Fix: verify the user's token at the start of every route that is not meant to be public, and validate input: never pass user input straight into SQL, shell commands or file paths, and do not let users make your server fetch arbitrary URLs.
7. Payments that can be faked
Two classic mistakes: trusting the price that the browser sends, and marking orders as paid when a webhook arrives without checking that it really came from the payment provider.
Check: look at the code that creates the checkout session (where does the amount come from?) and the webhook handler (does it verify the signature?). Fix: prices come from your server, and every webhook signature is verified. See our Stripe webhook security guide.
8. File uploads
Uploads need limits on file type and size, and private files need private storage. AI-generated code often puts every upload in a public bucket, where anyone with the link can download it.
Check: upload an HTML file or a very large file and see what happens. Open an uploaded file's link in a private window. Fix: allow only the types you need, set a size limit, and keep private files in private storage with short-lived signed links.
9. Rate limits, especially on AI features
Without limits, bots can try thousands of passwords, flood your sign-up form, or send password-reset emails to everyone. AI features add a new risk: if your summarise or chat endpoint has no limit, someone can run up your AI provider bill overnight.
Check: send the same request 50 times in a row and see whether anything stops it. Fix: rate limits per user and per IP address on login, sign-up, password reset and every endpoint that costs you money, plus a monthly spending limit with your AI provider.
10. Prompt injection in AI features
If your app feeds user content, web pages or documents into a language model, that content can contain instructions. Treat the model's output as untrusted input: do not let it run actions, send emails or query data on its own authority, do not put secrets in the system prompt, and give the model only the tools and data it needs.
11. HTTPS and security headers
Your host probably handles HTTPS, but check that HTTP redirects to HTTPS and that the site sends the basic security headers: HSTS, a Content Security Policy, X-Content-Type-Options and protection against being framed by other sites. The free Website Health Check tests these on your live site in a minute.
12. Dependencies, backups and logs
- Run
npm auditand update packages with known vulnerabilities, starting with your framework. - Turn on backups, and restore one into a test project at least once. A backup you have never restored is only a hope.
- Make sure your logs do not record passwords, tokens or full card or ID numbers.
Can the AI tool fix this itself?
Partly. Asking your tool to "review the RLS policies on every table" or "check that every API route verifies the user" often finds real problems, and it is worth doing. But the tool will also tell you with confidence that everything is secure when it is not, and it does not test the app the way an attacker would. Treat its review as a first pass, and test the important things yourself with a second account.
Get it checked before your users do
If you would rather have someone go through this list for you, our AI app security audit does exactly that. We test your app the way an attacker would, only with your written permission and our own test accounts, and give you a plain-English report with proof, severity and the fix for each finding. We can fix the issues for you and re-test afterwards. No audit can promise an app is perfectly secure, but this one catches the holes attackers look for first.
