My AI tool created a .env file — does that mean I'm safe?

Not necessarily. AI tools routinely create a .env.example file (correct — this is a committed template with placeholder values) and a .env file (correct — this is the real secrets file). The failure mode is that .env does not always end up in .gitignore. Confirm with git check-ignore -v .env from your project root. If it prints nothing, your .env is not ignored and a git add . will commit it. Check all variants: .env.local, .env.production, and .env.staging are common names that also need to be listed. The fix is a single line in .gitignore: .env* — this covers all .env files regardless of suffix.

Can I trust AI tools to add security headers to my project?

No framework or AI tool adds security headers automatically by default. Express, Fastify, Next.js, Vite, and Netlify all serve responses without a Content-Security-Policy, HSTS, X-Frame-Options, or Referrer-Policy header unless you explicitly configure them. When you ask an AI tool to generate a server setup, it will produce working code that does not set these headers, because most of the server configuration examples in its training data do not set them either. You have to request them explicitly — or scan the live site after deploy with HardenCheck, which takes 10 seconds and shows you exactly which headers are missing.

What is the most common way AI-generated apps get compromised?

The most common scenario is a hardcoded API key that reaches a public GitHub repository. AI tools frequently suggest const API_KEY = 'your-key-here' in comments or examples, and a developer replaces the placeholder with the real key, then commits the file. Automated bots scrape the GitHub Events API in real time and collect exposed keys within 60 seconds of a push. For AI-assisted projects specifically, source maps in production are a close second: a Vite or webpack config left at default settings exposes the full reconstructed source code, which makes it easy for an attacker to map out your API endpoints, authentication logic, and any secrets left in comments.

Do I need to run these checks on every deploy, or just on the first launch?

Run the full checklist at launch, then re-run targeted checks when you add new features that change the attack surface. LeakCheck and .gitignore verification are worth running before every significant commit that touches config files or adds new environment variables. ExposureCheck and HardenCheck are worth re-running when you change your build or deployment configuration, add a new subdomain, or switch hosting providers — each of these can silently change what is served publicly or which headers the server sends.

Pre-ship checklist

Vibe coding security checklist: what to check before you ship AI-generated code

Q: Do AI coding tools know about security best practices?

AI coding assistants are trained on a vast corpus of code that includes tutorials, Stack Overflow answers, and example projects — most of which were written to illustrate a concept, not to be shipped to production. The result is that AI tools often reproduce patterns like hardcoded API keys in config objects, wildcard CORS, and no security headers, because those patterns appear frequently in training data contexts where they were acceptable (local development, demo code, simplified examples). The tools are not unaware of security; they will often give good advice if you ask directly. The issue is that they default to the most common pattern they have seen, and the most common pattern for tutorial code is optimised for clarity, not production safety.

Q: Are source maps actually a security risk in production?

Yes. A JavaScript source map (.js.map file) contains your full, un-minified source code — function names, variable names, comments, and file structure — reconstructed from the bundled output. If it is served publicly alongside your production bundle, any visitor can view it in browser devtools (Sources tab → right-click → reveal in filesystem) or fetch the .map URL directly. This is equivalent to publishing your source code. It can expose proprietary business logic, API endpoint patterns, secrets accidentally left in comments, and the internal structure of your application. For production builds, set sourcemap: false in your bundler config (Vite: build.sourcemap, webpack: devtool, Next.js: productionBrowserSourceMaps).

AI coding tools — Cursor, Copilot, Lovable, Bolt, v0 — can scaffold a working web app in minutes. They can also, without flagging it, hardcode an API key in a utility file, leave .env out of .gitignore, and generate a server config with no security headers. This isn’t a flaw in those tools; it’s their training data: most tutorials and Stack Overflow examples were written for clarity and explanation, not for production deployment. Here is the six-check sequence to run before any AI-assisted project goes live.

Why AI tools introduce these gaps
The 5 most common gaps
The pre-ship checklist
If you find a leak
FAQ

Why AI tools introduce these specific security gaps

AI code assistants generate statistically likely code, not maximally secure code. The patterns they reproduce most faithfully are the ones that appear most frequently in their training data. Tutorial code, blog posts, and framework quickstarts — all optimised to get something running fast — dominate that corpus. Those sources routinely inline credentials for brevity, omit .gitignore entries that the reader is expected to add themselves, and skip security headers that would make the example harder to follow.

This means AI-generated code is often excellent at the application layer (routing, data models, UI) and consistently weak at the deployment and configuration layer. The categories below are not edge cases; they appear in the majority of greenfield AI-assisted projects.

The 5 most common security gaps in AI-generated code

Hardcoded API keys in source files

AI tools suggest const OPENAI_KEY = "sk-..." in config objects, utility helpers, and sometimes inline in component files. Bots scrape the GitHub Events API in real time; a public push with an exposed key is collected within 60 seconds.
Incomplete .gitignore

AI scaffolding usually creates .env.example (correct) but does not always add .env, .env.local, and .env.production to .gitignore. A single git add . then commits your real secrets file alongside your application code.
Wildcard CORS on API routes

AI-generated Express and Fastify routes default to Access-Control-Allow-Origin: * because it eliminates friction during development. Left in place in production, it allows any external site to make credentialed requests to your API from a visitor’s browser.
Missing security headers

No framework generates a Content-Security-Policy, HSTS, X-Frame-Options, or Referrer-Policy header by default. AI-written server configs — server.js, next.config.js, netlify.toml — almost never add them unless you ask explicitly.
Source maps served in production

Vite and webpack default to generating source maps in production builds, or AI-generated configs enable them explicitly. A publicly served .js.map file exposes your full un-minified source code — function names, comments, file structure, and anything accidentally left in the code.

The six-check pre-ship sequence

Work through these in order. The first two are free text checks that take under a minute; the rest are automated scans of your live URL.

Scan your source code for exposed secrets
Before your first commit and after any major AI-generated addition, paste your source files into LeakCheck. LeakCheck runs pattern matching for API keys, tokens, connection strings, and other credentials entirely in your browser — nothing you paste is sent to a server. Pay particular attention to config files, utility modules, and any file with “key”, “secret”, or “token” in its name.
Verify your .gitignore covers all env files
From your project root, run:
```
git check-ignore -v .env
git check-ignore -v .env.local
git check-ignore -v .env.production
```
Each command should print a line like .gitignore:5:.env* .env. If it prints nothing, that file is not ignored. The simplest fix is a single line in .gitignore:
```
.env*
```
This covers .env, .env.local, .env.production, .env.staging, and any other variant. Commit the updated .gitignore before committing anything else.
Scan your live URL for exposed files
After your first deploy, enter your domain in ExposureCheck. It probes for exposed .env files, accessible .git directories, JavaScript source maps, bundled secrets, and other configuration files that can end up publicly served if a build or deploy config is misconfigured. AI-generated Vite and Next.js configs are a frequent source of publicly accessible source maps.
Check your security headers
Paste your URL into HardenCheck. It checks your live site’s Content-Security-Policy, HSTS, X-Frame-Options, Referrer-Policy, and other security headers in seconds, with plain-English guidance on what each missing header enables an attacker to do and how to add it to your specific stack (Express, Next.js, Netlify, Cloudflare, nginx). AI-generated projects consistently have zero security headers on first deploy.
Audit your dependencies
Paste your package.json into DepCheck. AI tools suggest packages from their training data, which reflects the npm ecosystem as it existed at training time. Some suggested packages have since accumulated open CVEs, been abandoned by their maintainers, or have names one character away from a well-known typosquatting target. DepCheck flags all three categories.
Check accessibility and privacy compliance
AI-generated UIs produce a recognisable pattern of accessibility errors: heading order violations, missing alt attributes on images, form controls without labels, and colour contrast ratios set for aesthetics rather than WCAG thresholds. Paste your URL into ShipSafe for a plain-English report on the accessibility and privacy gaps that most commonly attract ADA demand letters.

If you find a secret that was already committed

The order of operations matters: rotate the key first, then clean up the history. Removing a file from the working tree or rewriting git history does nothing for a key that is already in someone else’s hands. Rotate the credential at the issuing service (OpenAI, Stripe, AWS, Supabase, etc.) to invalidate the old value immediately, then follow the steps to remove it from source and rewrite git history so the old commit no longer contains the value.

Detailed walkthroughs:

Frequently asked questions

Do AI coding tools know about security best practices?

They do, in the sense that they can give accurate security advice when asked. The issue is default behaviour: AI tools reproduce the most statistically common pattern for a given context, and the most common pattern in tutorials and example code is optimised for getting something running, not for production deployment. Asking your AI tool “does this code have any security issues” or “add production-ready security headers to this server config” often produces good results. The problem is that it does not volunteer those additions unprompted.

Are source maps actually a security risk in production?

Yes. A .js.map file contains your full un-minified source code — function names, variable names, comments, and file structure — reconstructed from the bundled output. If served publicly, anyone can view it in browser devtools (Sources tab) or fetch the URL directly. This exposes proprietary business logic, API endpoint patterns, and anything accidentally left in comments. Disable source maps in production builds: set build.sourcemap: false in Vite, devtool: false in webpack for production, or productionBrowserSourceMaps: false in Next.js.

My AI tool created a .env.example file — doesn't that mean .env is handled?

.env.example is a committed template with placeholder values — correct. But the existence of .env.example does not mean .env is in .gitignore. These are independent files. Verify with git check-ignore -v .env; if it prints nothing, your real secrets file is unprotected. Add .env* to .gitignore before your first git add ..

Can I ask my AI tool to add security headers for me?

Yes, and this works well. A prompt like “add Content-Security-Policy, HSTS, X-Frame-Options, and Referrer-Policy headers to my Express server config” or “update my next.config.js to add security headers” produces accurate output for most stacks. The catch is that you need to then verify the headers are actually present on the live site — misconfigured headers are common, and some middleware applies them only to certain routes or response types. HardenCheck scans the live response headers and tells you which ones are present, misconfigured, or missing.

What is the most common way AI-assisted projects get compromised?

Hardcoded credentials reaching a public git repository. AI tools suggest inline key values in config objects and test helpers; the developer commits the file without scanning it first; automated bots collect the key within minutes. The second most common path is source maps in production: a Vite or webpack config left at defaults exposes the full reconstructed source, revealing API endpoint patterns, authentication logic, and any secrets in comments. Both are caught in under two minutes with LeakCheck and ExposureCheck.

Do I need to rerun these checks on every deploy?

Run the full checklist at launch. After that: rerun LeakCheck and the .gitignore check whenever you add new environment variables or AI-generate a config change. Rerun ExposureCheck and HardenCheck when you change your build or deployment configuration, switch hosting providers, or add a new subdomain. Rerun DepCheck monthly or when you add new dependencies — CVE disclosures and package abandonment happen after packages are added to a project, not just at install time.

The full Copper Bay Labs ship-safety suite

Run all six tools before you flip a new project live. Each covers a distinct failure mode; none overlaps with the others.

Secrets scan LeakCheck

Paste code or a .env file and see every exposed API key and secret flagged by severity. Runs entirely in your browser.

Post-deploy ExposureCheck

Scan your live URL for exposed .env files, .git directories, source maps, and bundled secrets.

HTTP hardening HardenCheck

Check your live site’s security headers: CSP, HSTS, X-Frame-Options, Referrer-Policy, and more.

Dependencies DepCheck

Paste your package.json to find packages with CVEs, abandoned maintainers, or typosquatting risk.

ADA & privacy risk ShipSafe

Plain-English ADA/WCAG accessibility and privacy risk report for any live URL. Flags the issues that attract demand letters.