Is vibe coding safe? The security problems that show up

Short answer: it is safe enough for a throwaway prototype and not safe by default for anything with real users or real data. AI tools write code that works on the happy path, and security failures live off it. The repeat offenders are missing authorisation, secrets in the wrong place, trust in client input and unvetted dependencies. A short review before launch catches most of them.

Why is generated code often insecure?

A model produces the most likely code for your prompt. If you ask for a login page, you get a login page. You did not ask for rate limiting, so there is none. You did not say that user A must not read user B's invoices, so any logged-in user can. The code is not malicious. It is incomplete in exactly the places a prompt rarely mentions.

What are the usual problems?

Broken access control

The page hides the admin button, but the API route behind it accepts any authenticated user. Test this by taking a request from a normal account and changing the ID in the URL to someone else's. This is the most common serious bug in apps built fast.

Secrets in the wrong place

API keys placed in front-end code, committed to the repository, or printed in logs. In frameworks like Next.js, anything prefixed NEXT_PUBLIC_ is shipped to every browser.

Trusting the client

Prices, roles or discounts sent from the browser and believed by the server. Always recompute totals and check roles on the server.

Injection

SQL built by string concatenation, shell commands built from user input, HTML rendered without escaping. See how to prevent SQL injection.

Dependencies

Models sometimes suggest a package name that does not exist. Attackers register those names. Confirm that a package exists, has real history and is the one you meant, before you install it.

Missing basics

• No rate limit on login, password reset or any endpoint that sends email.
• Verbose errors that show stack traces and SQL to users.
• Wide-open CORS.
• No logging of sign-ins and sensitive actions.
• Database exposed to the internet with a default password.

A pre-launch checklist

• Search the repository, including git history, for keys and passwords. Rotate anything found.
• For every route that returns or changes data, write down who may call it and confirm the check is on the server.
• Try to read and edit another user's records with a second test account.
• Run npm audit or your language's equivalent, and look at every package the AI added.
• Turn on a secret scanner and a dependency scanner in CI.
• Put a rate limit on authentication and email-sending endpoints.
• Set security headers and a Content Security Policy, and test that the site still works. See why a strict CSP can break Next.js hydration.
• Back up the database and restore it once.

Can you ask the AI to review its own code?

It helps. Ask for a review focused on authorisation, injection and secrets, with a list of every endpoint and its access rule. It finds real issues. It also misses some, and it will sometimes tell you something is fine that is not. Treat it as a second reader, not as an auditor.

When should you pay for a human review?

Before you take payments, store health or financial data, or let strangers upload files. A day of a security engineer's time costs far less than a breach notification.