„Vibe coding" – quickly assembling an app with AI assistants like ChatGPT, Claude or Cursor without understanding every line – has become the norm. The result is often ready in hours instead of weeks. The price is rarely visible: security holes that the generated code brings along and that nobody reviews. This article shows the most common risks – and how to test your site for them in ten seconds.
What „vibe coding" really means
When vibe coding, you describe what you want to the AI model and accept its suggestion without auditing it. The model optimises for „it works" – not for „it's secure". It doesn't know your context: whether a key belongs in the browser, whether an endpoint is publicly reachable, or whether you're building a production system. The problems grow in exactly that gap – not out of malice, but because nobody is looking anymore.
The five most common security holes in AI code
1. API keys end up in the frontend
The classic: an AI assistant drops the Stripe, OpenAI or AWS key straight into the React or Next.js code „so it runs". At build time the key lands in the JavaScript bundle – readable by anyone in the browser. Whoever opens the dev tools has your key. The consequences range from someone else's invoices to leaked customer data and a compromised account.
2. The dev server runs in production
Vite, Next.js and Webpack have a development mode with hot reload, source maps and verbose error messages. If the site is accidentally run with the dev server instead of a real production build, it exposes internals that do an attacker's work for them: file paths, stack traces, sometimes entire source files.
3. Security headers are missing entirely
Content-Security-Policy, HSTS and X-Frame-Options are the first line of defence against cross-site scripting and clickjacking. AI-generated setups almost never ship them automatically. Without them, a single injected script line is enough to hijack sessions or force the page into a foreign frame.
4. Inputs aren't validated
„Take the form field and write it to the database" – that's how SQL injection and stored XSS happen. AI code reliably builds the happy-path logic; it rarely accounts for malicious input. Validation and parameterised queries are exactly the steps that get dropped during rapid assembly.
5. Tell-tale AI traces
Leftovers like „TODO: add auth", „Get started by editing…", default secrets from tutorials or commented-out test keys aren't just ugly. They tell attackers that unreviewed code is running here – and are often the hole themselves, for example when a tutorial password was never replaced.
Why classic GDPR and header checkers miss this
The common German website checkers test the imprint, cookie banner and a handful of headers. That's useful, but it falls short here: they don't look for leaked keys, a running dev server or typical AI code patterns. This blind spot is exactly why „vibe-coded" sites pass every standard check and are still wide open.
What you can do right now
- Keys belong on the server (environment variables), never in the frontend bundle.
- Always deploy a real production build – never the dev server.
- Set security headers (CSP, HSTS, X-Frame-Options).
- Validate every user input on the server and parameterise queries.
- Scan your site from the outside before going live.
Check in 10 seconds instead of hoping
The Vibe Check scans your site for exactly these risks: exposed API keys, dev servers in production, missing security headers and typical AI code traces – 55+ checks, a result in about ten seconds, with nothing stored.
Vibe coding isn't the problem. Unchecked vibe coding is.
Scan your site in 10 seconds →