Is your AI-built app safe to launch? The 12-point checklist

By Carl Mills - cloud & security engineer • Published 9 July 2026 • Last updated 9 July 2026

Why "it works" is not "it's safe"

AI coding tools - Cursor, Claude Code, Lovable, Bolt, v0 - optimise for one thing: code that runs. Security is invisible in a demo, so it's the first thing the model trades away. The numbers are consistent across independent studies:

• Analyses by OX Security and others put the share of AI-generated code containing vulnerabilities at between 40% and 62%.
• A 2025 audit of 1,645 apps built with Lovable found 170 (about 10%) had critical flaws exposing user data.
• In January 2026, the Moltbook breach exposed ~1.5 million API tokens and 35,000 email addresses within 72 hours of launch - an app built entirely by prompting.

None of this means don't build with AI. It means the launch step has a checklist, exactly like a rental car has a walk-around. Here it is.

The 12-point launch checklist

1. Get every secret out of your code

Search your project for sk-, key, secret, and password. Anything real goes into environment variables, and every key that was ever committed to git gets rotated (regenerated) - deleting the line doesn't delete the history. Exposed keys are the single most common finding in scans of vibe-coded apps.

2. Check authorisation on the server, not the screen

Hiding a button isn't security. Open your browser's dev tools, copy a request your app makes, and replay it logged out (or as a different user). If the API answers, anyone on the internet can do the same. Every endpoint that reads or writes user data must check who is asking on the server.

3. Lock your database rules

Supabase row-level security, Firebase rules, or plain SQL grants - whatever your stack, the database must refuse queries the app didn't intend. The classic vibe-code failure is a Supabase table with RLS disabled: the anon key in your frontend then gives every visitor full read/write access.

4. Validate every input on the server

Assume every form field and API parameter is hostile. Length limits, type checks, and parameterised queries (never string-built SQL). Injection remains in the top tier of the OWASP Top 10 for a reason.

5. Add rate limiting before someone else finds you don't have it

Without limits, one script can spam your signup form, drain your AI API credits, or brute-force logins all night. Limit by IP on auth endpoints (e.g. 10 attempts/minute) and put a cap on anything that costs you money per call.

6. Protect your paid APIs from becoming everyone's free tier

If your app calls OpenAI, Anthropic or any paid API from the browser, your key is public and your card is the product. All paid API calls go through your server, authenticated, rate limited, with a monthly spend cap set at the provider.

7. Set security headers

Five headers stop whole categories of attack: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Strict-Transport-Security. Test yours free at securityheaders.com - it takes 30 seconds and grades you A-F.

8. Turn off debug output in production

Stack traces, verbose errors and seeded test accounts tell an attacker exactly how your app is built. Production errors should say "something went wrong" to users and write the detail to logs only you can read.

9. Run one automated scan

Free tools catch the embarrassing stuff: npm audit for dependencies, gitleaks for committed secrets, and OWASP ZAP pointed at your staging URL. Ten minutes of scanning beats a public post-mortem.

10. Know what personal data you hold - and delete what you don't need

Emails, names, IPs and analytics IDs are personal data under privacy laws in most English-speaking jurisdictions - GDPR in the UK and EU, CCPA/CPRA in California, PIPEDA in Canada, the Privacy Act in Australia. Write one paragraph: what you collect, why, and how someone gets it deleted. If a field isn't needed, stop collecting it - data you don't hold can't leak.

11. Back up, then prove the restore

A backup you've never restored is a hope, not a backup. Take one, restore it to a scratch environment, and note how long it took. Vibe-coded apps often live on a single database with no recovery story at all.

12. Decide your "oh no" plan before launch day

Write down: how you'd take the app offline in under 5 minutes, how you'd rotate all keys, and where you'd tell users. When Moltbook leaked 1.5M tokens, the costly part wasn't the bug - it was the 72 hours of not having a plan.

The checklist at a glance

Frequently asked questions

Is AI-generated code safe to deploy without review?

No. Between 40% and 62% of AI-generated code contains vulnerabilities in independent tests. AI tools produce code that works; "works" and "safe" are different properties.

What's the most common vibe-coding security mistake?

Exposed secrets and client-only permission checks. Both are invisible in a demo and trivially found by anyone who opens dev tools.

Do I need to hire a security expert for a small app?

If you store no personal data and take no payments, this checklist is usually enough. The moment real customer data or money is involved, a 1-2 day professional review is dramatically cheaper than a breach - see our small business security checklist for what that covers.

Which check should I do first?

Secrets (check 1). It's the most common flaw, the fastest to exploit, and the fastest to fix.