Shipping a site used to take weeks. Now you describe what you want to Cursor, Lovable or Bolt, and you're live by the weekend. That's genuinely amazing — but it also means a lot of sites go to production without anyone ever thinking about the boring, dangerous stuff. The AI writes code that works, you deploy, and nobody checks whether it's actually safe.
Here are the five issues I run into most often on freshly shipped AI-built sites, why they matter, and how to check for each one yourself.
1. A publicly accessible .env file
This is the scariest one and it's shockingly common. Your .env holds API keys, database credentials, sometimes third-party secrets. If it ends up in a web-served directory, anyone can just request it.
How to check: try opening https://yoursite.com/.env in a browser. You should get a 404. If you see actual contents, rotate every key in there immediately and move the file outside your web root.
2. Tracking cookies firing before consent
If you dropped in Google Analytics or the Meta pixel, there's a good chance _ga and _fbp cookies are being set the moment someone lands — before they agree to anything. Under GDPR that's a consent violation, not a nice-to-have.
To check this, open DevTools, go to the Application/Storage tab, clear cookies, reload, and look at what gets set before you touch any consent banner. Analytics cookies should only appear after opt-in.
3. Session cookies without Secure and HttpOnly
A session cookie without HttpOnly can be read by JavaScript, which turns any XSS bug into full session hijacking. Without Secure, it can leak over plain HTTP.
Look at your session cookie's flags in DevTools > Application > Cookies. Both Secure and HttpOnly should be checked. In most frameworks this is a one-line config change.
4. Missing security headers (especially CSP)
Content-Security-Policy, HSTS, X-Content-Type-Options — these are your cheap, high-impact defenses. A missing CSP means an injected script runs with no restrictions.
Run curl -I https://yoursite.com and look at the response headers, or paste your URL into a headers checker. If Content-Security-Policy is absent, that's your first thing to add.
5. No way for users to request their data be deleted
This one isn't in the code — it's a legal gap. GDPR (and newer laws like Israel's Amendment 13, live since Aug 2025) give users the right to request deletion of their data. If your site collects personal data and has no mechanism for that, you're exposed regardless of how clean your code is.
Ask yourself: if a user emailed and said "delete my data," is there a process? If not, at minimum add a contact route and a documented procedure.
The annoying part: you have to remember to check all of this every deploy
Doing these checks by hand once is fine. Doing them on every deploy, across every project, is where it falls apart — which is exactly the gap I kept seeing, so I built a scanner for it called AI Cyber Shield. You paste a URL and it runs these checks from the outside, plus a GDPR/privacy pass, and hands you the fix for each thing it finds. Free to try — it's a paid product past the first scan, but the free scan isn't crippled, you get the full list.
That said, even if you never touch a tool: run through the five checks above before your next deploy. Most of them take two minutes and close holes that could genuinely get you breached or fined.
What do you all check before shipping? Curious whether people have a pre-deploy checklist or if it's more ship-first-fix-later.
Top comments (0)