Skip to content

Security · 6 min read · 6 Nov 2026

Vibe coding security checklist: is vibe coding a security risk?

AI can build a working app in an afternoon. Here's what it usually leaves insecure, and a checklist to run before you ship.

Vibe coding means describing what you want and letting an AI assistant write most of the code, accepting what works rather than reading every line. It’s a real productivity shift, and plenty of founders now ship a first version this way.

Is vibe coding a security risk? It can be, because the AI is optimising for “it runs”, and most security bugs don’t stop an app from running. An endpoint with no authorisation check works fine in a demo. So does an API key in the frontend. The problems show up later, when someone other than you starts poking at it.

The good news is that the gaps are predictable. Here’s what to look for.

What AI-built apps usually get wrong

Secrets in the wrong place. API keys hardcoded in source files, committed to the repo, or shipped in frontend code where anyone can read them in the browser. Once a key is in a public repo, assume it’s been copied. We wrote about this in Keeping secrets out of public code.

Missing authorisation. The app checks that you’re logged in, then lets you read any record by changing an ID in the URL. AI-generated APIs often skip the “does this user own this record?” check because nothing in the prompt asked for it.

Database rules left open. Backend-as-a-service platforms make it easy to talk to the database straight from the browser. That’s only safe if row-level access rules are switched on and correct. If they’re not, your whole database is one request away from anyone with the public key.

Packages that don’t exist. Code assistants sometimes import libraries that were never published. Attackers register those names with malicious code, a trick called slopsquatting. A USENIX Security 2025 study of 16 code-generating models found commercial models suggested non-existent packages at least 5.2% of the time and open-source models 21.7%, and many of the made-up names came back repeatedly, which is what makes them worth registering.

Outdated patterns. Models learn from years of old code, so they reach for deprecated libraries, weak password hashing or old crypto. It works, which is exactly why nobody notices. More on this in What AI gets wrong about security.

No limits. No rate limiting on login, so passwords can be guessed indefinitely. No limits on uploads or AI calls, so one script can run up your bill. Verbose error messages that show stack traces and database details to anyone.

The vibe coding security checklist

Run through this before real users or real data touch the app.

Secrets

  • No keys, tokens or passwords in source code; use environment variables or a secrets manager.
  • Nothing secret in frontend code. If the browser can see it, so can everyone.
  • Run a secret scanner over the repo history, not just the latest commit, and rotate anything it finds.

Access

  • Every API endpoint checks both who the user is and whether they may access this specific record.
  • Admin routes are protected server-side, not just hidden in the interface.
  • If the frontend talks to the database directly, row-level access rules are on and tested with a second account.

Dependencies

  • Every package exists, is the one you meant, and is actively maintained.
  • Run a dependency scanner (SCA) and fix critical known vulnerabilities.
  • Lock dependency versions.

Inputs and outputs

  • User input is validated server-side, and database queries are parameterised.
  • Output shown in the browser is escaped; no raw HTML from user content.
  • Error messages for users are generic; details go to your logs.

Limits and logging

  • Rate limits on login, signup, password reset and any endpoint that costs money.
  • Upload size and type limits.
  • Logs of logins, permission failures and admin actions, kept somewhere attackers can’t edit.

Before launch

  • Run a SAST scan on the code and a DAST scan on the running app. Our guide to SAST, DAST and SCA explains which catches what.
  • Ask the assistant to review its own code for security issues, then check its answers rather than trusting them.
  • Get a second person, or a professional test, to try breaking it before customers do.

Vibe coding isn’t the problem. Shipping code nobody has looked at with security in mind is, and that was true long before AI wrote it. If you’d like help, our SAST Scanner checks every pull request, the Repo Leak Scanner watches for leaked keys, and a penetration test is the last check before launch.

Next step

Want help with this?

Book a scoping call and talk it through with our team.