Vibe coding security: risks, review steps and a launch checklist for 2026

Vibe coding security is the work of making software that was largely written by an AI model safe to run in production. The short answer: read AI-written code the way you would read a pull request from a fast new hire. It usually works. It also tends to skip authorisation checks, leak secrets, ship insecure defaults and, now and then, import packages that do not exist. Review it, scan it, and test the running app before real customer data touches it.

What is vibe coding security?

Vibe coding means building software by describing what you want to an AI model and accepting what it writes, often without reading the code closely. Andrej Karpathy popularised the phrase in early 2025, and it has since stretched to cover almost any AI-assisted development, from a founder prompting a no-code builder to an engineer using an agent inside an IDE.

Vibe coding security covers the review steps, tooling and guardrails that sit between "it runs" and "it is safe". That gap is real. A model optimises for code that satisfies the prompt, and a prompt such as "add an invoices page" rarely says "and make sure one customer cannot read another customer's invoices".

In March 2026 the head of the UK National Cyber Security Centre, Richard Horne, spoke about it at RSAC. He called vibe coding a huge opportunity but "not without risk of its own", which is a fair summary for a team deciding how much to trust the output.

Vibe coding versus AI-assisted engineering

The risk depends on how much a human reads. At one end, a developer uses autocomplete and reviews every diff. At the other, a non-developer ships an app they have never opened in an editor. Most teams sit in between, and the security controls should scale with that distance.

Table 1. How reading effort changes the controls you need

How risky is AI-generated code in 2026?

Studies disagree on the exact rate, and no figure describes your codebase. Four public data points still show the shape of the problem.

Insecure code in tests

Veracode's 2025 GenAI Code Security Report analysed code from over 100 large language models across Java, JavaScript, Python and C#. It found that AI-generated code introduced risky security flaws in 45% of tests. It also reported that larger, newer models did not write more secure code.

Leaked secrets

GitGuardian's State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets added to public GitHub in 2025, a 34% increase year on year and the largest single-year jump it has recorded. Commits assisted by Claude Code leaked secrets at 3.2%, against a 1.5% baseline across all public GitHub commits. GitGuardian itself says this should not be read as a simple tool failure, because developers decide what to accept.

Invented dependencies

A USENIX Security 2025 paper, "We Have a Package for You!", generated 576,000 code samples and found that the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source models. The authors recorded 205,474 unique invented package names.

Access control was already the weak spot

This matters because the most common web flaw does not need an AI to appear. The OWASP Top 10:2025 keeps Broken Access Control at A01 and states that 100% of the applications tested had some form of it. A model trained on public code has seen plenty of examples of the pattern done badly.

What are the main vibe coding security risks?

The same handful of failures turn up again and again. None is new; the model just produces them faster. Each one below comes with a test you can run, and most map to the OWASP Top 10.

1. Missing authorisation checks

The model builds the screen, the route and the query, and forgets the rule about who may call it. The result is broken access control: a signed-in account that can read or change another account's records by changing an ID, or a normal account that can reach an admin route.

What it looks like in code

Look for handlers that load a record by ID from the URL and return it with no comparison to the signed-in account. In a prompt-built app with a hosted database, look for tables that the browser can query directly with no row rules. This is IDOR or BOLA in an API, and our guide to broken object level authorization shows how to test it.

Why database rules matter

Supabase is a common back end for prompt-built apps. Its Row Level Security documentation says plainly: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." It adds that on existing projects a new table in public starts with every privilege already granted to its roles. If the generated code creates tables and never turns on row-level security, the public key in the browser can read the data.

2. Hardcoded secrets and exposed keys

Models paste API keys into source files, front-end bundles and .env files that get committed. Anything shipped to the browser is public. A hardcoded secret in a repository stays in its history even after you delete the line, so the fix is to rotate the key, not just remove it. The OWASP Secrets Management Cheat Sheet advises rotating secrets regularly so stolen credentials only work for a short time, and scanning early with IDE checks, pre-commit hooks and CI.

3. Insecure defaults

Generated projects often run with debug mode on, wildcard CORS, no rate limiting, permissive storage buckets and verbose error pages. Each is a secure defaults failure that the model copied from a tutorial where convenience was the goal. The OWASP list ranks Security Misconfiguration at A02:2025 for a reason.

4. Hallucinated and risky dependencies

When a model suggests a package that does not exist, an attacker can register that name with malicious code and wait for someone to install it. This is often called slopsquatting, and it is a close cousin of typosquatting and dependency confusion. OWASP now names the wider category A03:2025 Software Supply Chain Failures and recommends getting components only from official sources and keeping an inventory (an SBOM) of direct and transitive dependencies.

5. Weak input handling and injection

Models still concatenate strings into queries, trust file names and skip output encoding. Expect SQL injection, cross-site scripting and path traversal in the places where user input meets a sink. Veracode's report is the best-known measurement of this class in generated code.

6. Missing business rules

The model implements the happy path. It does not know that a coupon may only be used once, that a refund cannot exceed the payment, or that a trial must not restart on every sign-up. These business-logic flaws pass every scanner because nothing looks malformed. They are found by someone, or something, trying to misuse the feature. Our API security testing guide covers how to probe them.

7. Over-powered coding agents

The tool that writes the code can also run commands, read your environment and call outside services. A poisoned README or issue can steer it through indirect prompt injection. Keep agents on least privilege, away from production credentials, and read our notes on MCP security and AI agent security testing if your agent uses tools.

Table 2. Risk, typical sign, quick check

How do you secure vibe-coded apps?

You secure them in layers: constrain what the model may do, review what it wrote, scan it automatically, then test the running application. No single layer is enough. The NCSC's message at RSAC was that AI development tools must be designed to avoid introducing vulnerabilities, so the safeguards have to be built in rather than assumed.

Guardrails before the first prompt

• Write security rules into the project. Most coding tools read an instructions file. State the rules there: check ownership on every query, parameterise SQL, never put secrets in client code, ask before adding a dependency.
• Use a secure base. Start from a template with authentication, session handling and security headers already done, and let the model fill in features.
• Keep production out of reach. Give agents a dev environment, throwaway credentials and no write access to production data.
• Protect the main branch. Require a reviewed pull request and passing checks with branch protection.

A review checklist for generated code

Large AI diffs wear reviewers out, so use a short, fixed checklist. The OWASP Authorization Cheat Sheet gives the three rules to anchor it: deny by default, enforce least privilege, and validate permissions on every request.

Check 1: authorisation on the server

For each new route, find the line that decides whether this caller may do this to this record. If the only check is in the front end, treat it as missing. Read about server-side authorisation and the ownership check.

Check 2: data access and secrets

Confirm database rules exist for every table the browser can reach. Search the diff for keys, tokens and connection strings. Confirm only public identifiers reach the client.

Check 3: inputs and outputs

Find where user input enters. Is it validated, parameterised, encoded on output? Does an error message reveal stack traces or table names? See input validation.

Check 4: dependencies

List every package the change added. Open each on its official registry. Check age, maintainers and download history, then pin the version with a lockfile. Dropping a package you do not need is the safest fix.

Check 5: business rules

Ask what a bored customer could do with this feature: repeat it, reorder the steps, send negative numbers, or use another account's IDs.

Automated checks in the pipeline

Automation catches the repeatable mistakes so humans can focus on logic. Wire these into CI so a failing check blocks the merge.

Table 3. What each automated check finds in AI-written code

The DAST, SAST and IAST comparison explains where each tool earns its keep. Add a pre-commit hook so secrets are blocked before they ever reach the repository.

How do you test a vibe-coded app before launch?

Test the running app with at least two accounts and a pile of real-looking data, then try to make one account reach the other's records. Scanners and reviews read what the code says. Testing shows what the app does, and that is where authorisation and logic flaws surface. The sections below give a practical order.

Set up accounts and data

Create at least two ordinary accounts in separate organisations, one admin, and one unauthenticated session. Fill each with distinct records, so any leak is easy to recognise. Note every ID, file URL and API route each account touches.

Run the cross-account tests

1. Replay account A's requests with account B's session and see whether B can read, change or delete A's data.
2. Call admin routes with an ordinary session, and with no session.
3. Change IDs, including those in file links, exports and webhook payloads.
4. Query the database directly with the public client key and see which tables answer.
5. Try changing fields the form never shows, such as role, plan, owner or price (mass assignment).

Our access control testing checklist turns these into a full plan, and the VAPT checklist covers the surrounding process.

Run logic and abuse tests

Repeat a payment, cancel half-way, apply a code twice, or run two requests at once. Models rarely handle a race condition. Send oversized, empty and unexpected values to every field.

Where an exploit-proving tester fits

This is the kind of work Cyberlop does. It finds vulnerabilities in web apps and their APIs with black-box, grey-box and white-box pentesting, checks business-logic flaws and cross-account access, and reports only what it exploited, with the request, the response and, in white-box mode, the line of code. A fix is proven by re-running the exact exploit against the new code in a closed-loop retest. It can run on a schedule or in CI/CD and gate a build, which suits a codebase that changes by the hour. See how it works and what a finding looks like.

Is AI-generated code safe for production?

It can be, if it passes the same gates as human code and a few extra ones. The model is not the problem. The missing gates are. Use this table to decide how much proof to demand before each release.

Release gates by risk

Table 4. Release gates by what the app holds

If customers or auditors ask, keep the evidence: the review notes, scan results, test findings and retest proof. That record also helps with SOC 2 and ISO 27001 conversations, and with security questionnaires. Our continuous penetration testing guide shows how to keep the test current as the code changes. For a view on automated testing tools and their honest limits, read AI penetration testing.

Vibe coding security checklist

Copy this into your pull request template. Each item is a yes or no.

Mistakes teams repeat

The classic mistake is asking the model to "make it secure" and accepting the answer. Another is scanning once, at the end, and reading a green SAST run as proof that access control works. Teams also fix the one line a scanner flagged and miss the same flaw in five sibling routes, or re-prompt the model to patch a problem without checking that the patch held. The only reliable check is to run the original exploit again.

What do standards expect from AI-written code?

Standards do not exempt generated code. They ask what they ask of any software: secure development practices, tested controls and evidence. For a product team, the useful anchors are the OWASP Top 10 and ASVS for requirements, the secure SDLC for process, and the DPDP Act or GDPR if you hold personal data. If an AI-written flaw exposes customer records, the duty to report a breach applies just the same. See also the product teams page and our limits.