Guide · plain English

Vibe coding security: how to secure AI-built apps

Q: Is AI-generated code secure?

Not by default. Independent studies have found that a large share of AI-generated code — by some measures roughly half — contains at least one common (OWASP Top 10) vulnerability. AI assistants optimize for code that works, not code that's hardened, so secrets, missing auth and missing security headers are common.

Q: What are the most common security issues in vibe-coded apps?

Exposed secrets and .env files, missing or weak access control, missing HTTP security headers, no email authentication (SPF/DKIM/DMARC), outdated dependencies with known CVEs, and publicly readable cloud storage buckets.

Q: How do I check if my AI-built app is secure?

Run a passive security scan that checks your TLS, security headers, email authentication and exposed files, and explains each finding in plain English with a fix. Hardn does this for free and doesn't require you to read a CVE.

You described an app and an AI built it. It works, it's live, people are using it. The problem: AI assistants optimize for code that runs, not code that's safe — so vibe-coded apps routinely ship with security holes their builders can't see and can't read.

How big is the problem?

Bigger than most builders realize. Multiple independent analyses of AI-generated code have found a large share carries real vulnerabilities:

Roughly half of AI-generated code samples have been found to introduce at least one common (OWASP Top 10) vulnerability. In one analysis of thousands of vibe-coded apps, researchers surfaced thousands of vulnerabilities, hundreds of exposed secrets, and real PII exposures.

That's not an argument against building with AI — it's an argument for a quick safety check before and after you ship. If you can't read a CVE, you need a tool that reads it for you and tells you what to do in plain English.

The 6 security holes most common in vibe-coded apps

Exposed secrets & .env files. AI scaffolds often leave API keys, database URLs and tokens in places that end up publicly reachable. If your /.env or /.git is downloadable, treat those secrets as already compromised.
Missing security headers. Generated front-ends rarely set Content-Security-Policy, HSTS or X-Frame-Options — leaving the door open to cross-site scripting and clickjacking. Check yours free →
Weak or missing access control. "Make a dashboard" often produces endpoints that don't actually check who's asking — so anyone with the URL can read or change data.
No email authentication. Without SPF, DKIM and DMARC, anyone can send email that looks like it's from your domain and phish your users.
Outdated dependencies. AI pins whatever version it learned — often one with a known, published vulnerability.
Public cloud buckets. Storage created "to get it working" is frequently left world-readable, exposing uploads and backups.

A 5-minute vibe-coding security checklist

Confirm /.env, /.git and config files are not publicly reachable.
Set the core security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options).
Make sure every data endpoint checks authentication and authorization.
Add SPF, DKIM and DMARC records for your domain.
Update dependencies and check them against a CVE database.
Make any cloud storage bucket private unless it's meant to be public.
Force HTTPS everywhere and keep your TLS certificate from expiring.

Don't want to check all that by hand?

Hardn scans your live site for these exact issues — passively, no exploitation — and hands you a plain-English report with a copy-paste fix for your stack. Built for builders who can't read a CVE.

Run a free scan →

Why "plain English" matters here

A traditional scanner spits out CWE-79 and a severity number. If you came to coding through AI, that's useless. The value isn't the finding — it's knowing what it means for your app and the exact line to change. That's the whole idea behind Hardn: business-context risk scoring plus copy-paste fixes for your actual stack (nginx, Caddy, Vercel, Cloudflare, Netlify), each with a command to confirm it worked.

Frequently asked questions

Is AI-generated code secure?

Not by default. A large share — by some measures about half — of AI-generated code contains at least one common vulnerability. AI optimizes for working code, not hardened code.

What are the most common security issues in vibe-coded apps?

Exposed secrets and .env files, missing access control, missing security headers, no SPF/DKIM/DMARC, outdated dependencies, and public cloud buckets.

How do I check if my AI-built app is secure?

Run a passive scan of your TLS, headers, email auth and exposed files, with each finding explained in plain English and a fix attached. Hardn does this free — no CVE-reading required.