AI coding tools such as Lovable, Bolt, v0, Cursor, and Replit let a small team ship a working product in days. What they do not do for you is make that product secure. The speed that gets you to a launch is the same speed that lets a stray key, an open database, or a missing permission check slip through unnoticed. This is a short, practical checklist to run before you put an AI-built app in front of real users.
Why AI-built apps need a deliberate security pass
These tools generate code that works, not code that is necessarily locked down. Sensible defaults are often left open so that the app runs on the first try, and authorisation, secret handling, and data exposure are treated as your job, not the generator's. Because features arrive quickly and in bulk, there are simply more places for a gap to hide. A short, structured pass before launch catches the issues that matter most, while they are still cheap to fix. Many of these are the same gaps AI coding tools quietly miss.
The pre-launch checklist
Secrets and configuration. Make sure no API keys, database passwords, or tokens are hardcoded or committed to source control, and that anything ever exposed has been rotated. If you are unsure where to start, our guide on secrets, keys and config covers the common traps.
Access control and data. Confirm that every sensitive action and record is checked on the server, not just hidden in the interface, and that users can only reach their own data. An open database rule is one of the most common serious findings in fast-built apps: see broken access control, in plain English and our check for a publicly readable database.
Dependencies. Review the third-party packages your app pulls in, remove anything you are not using, and update those with known vulnerabilities.
Your public surface. Check what the app exposes to the internet before anyone else does: security headers, TLS, cookie flags, and email spoofing protection. Our free Surface Check gives you an A-to-F score for this in about thirty seconds.
Authentication basics. Enforce sensible password rules, protect against brute-force attempts, and make sure session tokens expire and log out cleanly.
Error handling and logging. Turn off verbose debug output in production, and make sure logs do not record secrets or personal data.
What to do with the findings
A checklist is only useful if the items it surfaces actually get fixed. Triage each finding, confirm it is real, prioritise anything that is internet-facing or exposes user data, fix the root cause rather than the symptom, and retest. A list of issues is not security until that work is done. For a wider reference on the most critical web application risks, the OWASP Top 10 is a reliable starting point.
Next steps
Running this checklist before launch removes a large share of the risk for very little effort. If you would like a second pair of eyes on an AI-built app before it goes live, our application security assessment is built for startups and fast-moving teams. We prepare the fixes and hand them to your team to review and deploy, or apply them directly where you have authorised us to do so in writing. You can get in touch through our website.