The complete security checklist for AI-built sites (Lovable, Bolt, v0, Cursor)
An AI can ship a working app in an afternoon — and leave a dozen doors unlocked. This is the full checklist I run against AI-built sites, in the order the findings actually bite.
An AI can build you a working web app in an afternoon. What it can't do is tell you which of the doors it left unlocked. I audit these sites for a living, and the findings are so consistent I can almost predict them before the scan finishes.
The reason is simple: an AI generator optimises for "it works", not for "it's safe". It gets the feature shipping and moves on — and the security work that a careful developer does by reflex just never happens. Nobody decided to skip it. It was never on the list.
This is the full checklist I run against a site built with Lovable, Bolt, v0, Cursor, Replit or any of the others. It's the same one Reconvio automates. Work through it top to bottom — the items near the top are the ones that actually get people breached.
1. Secrets and keys
This is where the real damage lives, so it goes first.
Is your .env reachable from the web? The single most common critical finding. The config file with your database password and API keys, sitting one request away from anyone:
https://your-site.com/.env → 200 OK
If that returns anything but a 404, treat every secret in it as already leaked — rotate them today. I wrote a whole piece on why an exposed .env is a catastrophe, because it is.
Are API keys sitting in your frontend bundle? A Stripe key, an OpenAI token, a Supabase key — hardcoded into JavaScript that every visitor downloads. "It's only the frontend" is not a defence. If you call a paid API directly from the browser, that key is in the bundle, and scrapers find bundled keys within hours of launch. Paid providers get drained on stranger's traffic all the time this way.
Is your .git directory public? Deploy the whole working folder and the commit history ships with it — publicly downloadable, and often still holding the "deleted" keys someone believed were gone. Check your-site.com/.git/config.
These three plus two more make up the five holes I find on almost every AI-built site — start there if you only have five minutes.
2. Your database and backend
AI builders love Supabase, Firebase and friends. They're excellent — right up until one setting is missed.
Row Level Security (RLS). Forget to switch RLS on and anyone can read other people's rows straight through the public API with the anonymous key — users, orders, personal data, the lot. This is the quiet one: the site works perfectly, and the data is wide open. Enable RLS and write a policy per table, but do it thoughtfully — a public product catalogue is meant to be readable; a users table is not.
The service_role / admin key. Supabase's service_role key bypasses every permission you set. It must never leave the server. If it's anywhere in the frontend, rotate it immediately and move those calls to a server function.
Public database admin tools. Adminer, phpMyAdmin or a database panel left reachable in production is a direct door to your data. Remove it, or lock it behind an IP allowlist or VPN.
3. Authentication and access
Auth on every sensitive route. AI frequently builds the login page and then forgets to actually protect the API routes behind it. An endpoint like /api/admin/users that returns data without checking who's asking is one of the most common — and most serious — patterns in AI-generated code. Test your sensitive routes while logged out.
Admin behind a real password. An /admin area with no auth, a default password, or a "secret" URL that isn't secret. If curiosity and a browser can reach it, so can everyone.
Session cookie flags. Login and session cookies need Secure, HttpOnly and SameSite. Without HttpOnly, a single injected script can steal the session and log in as your user.
4. Transport and headers
HTTPS everywhere, valid TLS. A valid certificate, a permanent HTTP→HTTPS redirect, and no mixed content. Modern hosts do most of this for you — verify it actually happened.
Security headers. A handful of HTTP response headers switch off whole classes of attack for the cost of a few lines of config — and AI almost never sets them. Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and the rest. I broke down what each security header does, in plain language, and how to roll out CSP without breaking your own scripts.
5. Domain and email
SPF and DMARC. If your domain has no SPF/DMARC records, anyone can spoof email as you — a gift to phishers using your brand. These are DNS records, quick to add, and worth it even if you don't send much mail. Start DMARC at p=none to monitor, then tighten.
6. Dependencies
Outdated libraries with known holes. AI often pins whatever version it was trained on. An old jQuery, Bootstrap or Lodash with a published vulnerability is an open invitation, because the exploit is already public. Update to a supported version and test.
7. The three things AI never thinks about at all
Security is only half the story. The same "it works, ship it" reflex leaves three more gaps that quietly cost you:
- Privacy and law. No cookie consent, trackers firing before opt-in, missing privacy policy. In the EU this is a fine waiting to happen — see the 2026 website compliance checklist for the full picture.
- Accessibility. Missing alt text, unlabelled buttons, poor contrast. Beyond locking out real users, in Europe it's now a legal requirement.
- Visibility. AI-built sites are often invisible to search engines and to AI assistants. If ChatGPT can't read your site, it can't recommend you — I covered how to check whether your site is invisible to AI.
How to check all of this in 30 seconds
You can walk this list by hand — open /.env, view source, test routes logged out, inspect headers. It's a good exercise and I recommend doing it once.
Or you point Reconvio at your site and it runs every check on this page in half a minute, tells you exactly what it found and how bad it is, in plain language, for free. Every check here came from a real finding on a real site — not theory. It's the stuff automated scanners built for big enterprises tend to miss on small AI-built sites, which is exactly why I built it.
You don't need to be a security expert to close these holes — you need to know they're there. AI gave you a running site in an afternoon. Give it thirty seconds to find out what it left open.
See what your site exposes
Run a free audit and get concrete issues in half a minute — no signup.
Check my websiteKeep reading
One website audit or a dozen browser tabs? All-in-one vs single-purpose scanners
There's a great free tool for each of security headers, SSL, DNS, speed, SEO and cookies. Running all of them, reconciling the results, and knowing what actually matters is the real work. The case for a single scan.
July 19, 2026
Supabase RLS: the one setting that decides who reads your data
Row Level Security is the difference between a private database and a public one — and it's the setting AI builders quietly skip. What RLS is, how to tell if yours is off, and how to switch it on without breaking your app.
July 18, 2026