Vibe coding security vulnerabilities

Vibe coding is fast because a developer can describe an outcome and let an AI produce the implementation. The security failure is not the use of AI. It is accepting working-looking output without rebuilding enough understanding to verify the trust boundaries, permissions, dependencies, and deployment behavior.

1. Missing authentication and authorization

Generated endpoints often implement the happy path and omit the negative path. An API may check that a user is signed in but never verify that the requested record belongs to that user. Admin, billing, key-management, and internal routes may be callable without an explicit role or scope decision.

• Require authentication on every non-public route.
• Check authorization against the exact object and action, not only the user’s login state.
• Test cross-user, cross-project, and cross-tenant access.
• Keep privileged checks on the server; hiding a button in the client is not authorization.
• Use deny-by-default rules for admin, billing, secrets, grants, and destructive operations.

2. Injection and unsafe output handling

AI-generated code can compose untrusted input into SQL, HTML, shell commands, paths, URLs, templates, or dynamic code. The same problem appears one level higher when model output reaches eval, exec, subprocesses, file operations, or MCP tools.

• Use parameterized queries and safe framework APIs instead of string construction.
• Encode output for its destination and avoid unsafe HTML rendering.
• Validate command arguments, file paths, URLs, and redirect destinations with narrow allowlists.
• Do not execute raw model output.
• Trace untrusted input across helper functions instead of reviewing only the final line.

How to detect prompt injection in AI-generated code covers the model-specific version of this source-to-sink review.

3. Secret exposure and unsafe data handling

Generated examples frequently use convenient placeholders that become real credentials, copy server secrets into client code, log full request objects, or send sensitive context to a model. Once a secret is committed, bundled, or logged, deleting the line is not enough; the credential must be rotated.

• Keep secrets in server-side environment or secret-management systems.
• Never expose private keys through public environment-variable prefixes or browser bundles.
• Redact credentials, tokens, cookies, personal data, and sensitive tool arguments from logs.
• Give AI tools only the minimum context needed for the task.
• Scan commits and generated files for secrets before they leave the workstation.

4. Hallucinated and unverified dependencies

A model can suggest a package that does not exist, choose the wrong package with a similar name, or select an old and vulnerable version. Attackers can publish packages that match plausible hallucinated names—a supply-chain pattern often called slopsquatting.

• Verify every new package in the authoritative registry and the project’s official documentation.
• Check publisher, repository, maintenance history, release age, and install scripts.
• Pin reviewed versions and commit the lockfile.
• Remove generated dependencies that duplicate platform or existing-project functionality.
• Run dependency and license checks before merge.

5. Weak defaults and incomplete production controls

Generated applications often work locally with permissive settings that are unsafe in production: wildcard CORS, disabled certificate checks, broad file permissions, missing CSRF protection, verbose errors, weak cookie settings, no rate limits, and unrestricted request bodies.

• Review every security-relevant default separately for development and production.
• Use secure, HTTP-only, same-site cookies where session cookies are appropriate.
• Set request-size, upload, timeout, retry, and rate limits.
• Return calm public errors and keep stack traces and internal details out of responses.
• Fail startup when required production secrets or security settings are missing.

6. Destructive agent actions

When a coding agent can run commands, edit files, change schemas, publish packages, or deploy, a code-review mistake becomes an action-control problem. A correct tool call can still be unsafe because the agent chose the wrong target or acted on hostile context.

• Use a disposable branch or workspace for generated changes.
• Sandbox commands and generated code with limited file and network access.
• Require approval for schema changes, authentication changes, releases, destructive commands, and production writes.
• Set iteration and cost limits outside the model.
• Keep a searchable record of requested, denied, approved, and completed actions.

AI agent security checklist for developers provides the full control set. If the action path runs through a connector, review MCP security risks for Claude Code users as well.

A secure vibe-coding workflow

Before generation

• Define the trust boundaries, sensitive data, protected actions, and acceptance criteria.
• Give the agent a narrow task and the minimum tools and context needed.
• State security requirements explicitly, including authentication, authorization, validation, errors, and tests.

During generation

• Keep changes small enough to understand and review.
• Ask for explanations of data flow and permission decisions, then verify them in code.
• Do not approve new packages, migrations, or broad configuration changes automatically.
• Run generated code in an isolated development environment.

Before merge or deployment

• Review the diff manually and remove unrelated generated changes.
• Run tests, static analysis, secret scanning, and dependency checks.
• Test unauthorized and malformed requests, not only the success path.
• Review infrastructure, environment, migration, and workflow files with the same care as application code.
• Require a human decision for high-impact release actions.

What “safe enough” looks like

You do not need to understand every generated character from memory. You do need to understand what crosses each trust boundary, who can perform each sensitive action, which dependencies and credentials are involved, what will execute, and how the system stops or records unsafe behavior. That is the shift from unchecked vibe coding to reviewable engineering.