Vibe Coding Security Risks: What to Check Before You Launch

Vibe coding security risks are the gaps AI-generated apps ship with when nobody reviews the code: keys in the browser bundle, tables without row-level security, missing authorization checks, injection, invented or hijacked packages, open admin routes, no rate limits and, if the app calls an LLM, prompt injection. Each maps to an OWASP category, and free tools find most of them before launch.

Vibe coding security is the work of finding and closing the vulnerabilities that appear when an AI model generates software and a person accepts it without reading it. It is ordinary application security applied to code nobody fully read. The failures are the classic ones, produced faster.

Is vibe coding safe for a production app?

Vibe coding is fine for a prototype and risky in production until someone checks the output, because working and secure are different tests. SusVibes, a benchmark of 186 feature tasks from real open-source projects where humans had once committed vulnerable code, shows the gap. The current version of the paper (version 4, revised 21 September 2026) says: "Although 57% of the solutions from SWE-Agent with Claude 4 Sonnet are functionally correct, only 11.8% are secure."

It is one of 12 agent settings tested; the authors say "all agents perform poorly in terms of software security," and vulnerability hints in the request did not fix it. How vibe coding differs from reviewed AI-assisted work is in my comparison of AI-assisted development and vibe coding.

Which security risks show up in AI-generated apps?

Eight failure types recur, and each has a category in the OWASP Top 10:2025, the edition after 2021, or, for model features, the OWASP Top 10 for LLM Applications 2025.

Why do API keys end up in the browser or the repository?

Keys leak because the quickest way to make a feature work is to put the key where the code runs, which in a vibe-coded app is often the browser. Most front-end frameworks copy environment variables with a public prefix into the JavaScript every visitor downloads. Other paths: a committed .env file, or a key left in git history after cleanup.

Supabase adds a trap: its row-level security guide describes the service_role key as "Full access. It bypasses RLS, so keep it server-side." Prompts are no safer. OWASP's LLM07 entry says "the system prompt should not be considered a secret, nor should it be used as a security control." OWASP lists hard-coded credentials as CWE-798 under A07:2025. The fix has two steps: move the key to the server, then rotate it, because a key that was ever public is a stolen key.

What does missing row-level security or authorization look like?

It looks like an app that works for its one test user and hands other people's records to anyone who changes an ID or queries the database directly. A01:2025 Broken Access Control keeps the top spot, and OWASP reports that "100% of the applications tested were found to have some form of broken access control." One of its scenarios is the vibe-coded pattern: "An application puts all of their access control in their front-end."

When the browser queries the database, its rules are the access control. Supabase is blunt: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." It also warns that on projects that still grant anon and authenticated by default, "Adding policies doesn't remove them," and that "Views bypass RLS by default because they are usually created with the postgres user."

On a server-rendered app the same bug is a route that loads a record by ID without checking the owner (CWE-639). Test it by hand as a second user, then signed out. In a multi-tenant SaaS build, settle this in the design.

How do injection and insecure defaults get into generated code?

They come with the first version that runs, because "it works" never tests hostile input or production settings. Injection, A05 in the 2025 list, appears as string-built SQL, raw HTML from user content and shell commands with user-chosen file names. Ask for parameterized queries and framework escaping, then check the diff uses them.

Defaults fall under A02:2025 Security Misconfiguration, whose warning signs include "Default accounts and their passwords are still enabled and unchanged" and stack traces shown to users. I look for debug mode, seeded admin passwords, CORS open to every origin and error pages that print the query.

How can an AI assistant pull in a fake or malicious package?

It can name a package that does not exist; an attacker registers the name, and the install runs their code. This is package hallucination, and the attack is often called slopsquatting. In a study for the 2025 USENIX Security Symposium, Joseph Spracklen and colleagues generated 576,000 code samples with 16 models and found "the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models" (arXiv version 3, revised 2 March 2025).

Real packages turn hostile too. On August 26, 2025, attackers used a stolen npm token to publish malicious versions of Nx, a popular build tool. The Nx advisory says they contained "code that scans the file system, collects credentials, and posts them to GitHub as a repo under user's accounts." The Nx postmortem of September 5, 2025 adds that the script "attempted to use local AI tools (like Claude and Gemini)."

OWASP now ranks this as A03:2025 Software Supply Chain Failures. My rule: agents propose packages and never install them. I check each name against the library's official docs and its registry page.

What changes when your app itself calls an LLM?

Your app gains an input channel that can rewrite its instructions. OWASP's LLM01:2025 Prompt Injection "occurs when user prompts alter the LLM's behavior or output in unintended ways," and "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files." A bot that reads tickets, web pages or email takes orders from whoever wrote them. It has happened in shipped products: CVE-2025-32711, published June 11, 2025, reads "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network." Microsoft scored it 9.3, critical.

No prompt wording stops injection, so defend in code:

• Least privilege. OWASP says to "handle these functions in code rather than providing them to the model" (LLM06 Excessive Agency).
• Human approval for refunds, deletions and outbound email.
• No secrets in the system prompt (LLM07), and escaped model output (LLM05).
• Per-user limits and a provider spend cap (LLM10 Unbounded Consumption).

I apply these to every AI agent feature before it touches customer data.

Which routes and limits do vibe-coded apps forget?

The admin side and the brakes. Generated apps grow /admin pages, seed endpoints and debug routes that are hidden from the menu but open on the server. OWASP's test: "If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw." Only a server-side role check counts.

A07:2025 flags apps that permit "brute force or other automated, scripted attacks that are not quickly blocked," and A01 advises: "Implement rate limits on API and controller access to minimize the harm from automated attack tooling." Limit login, signup, password reset, one-time codes, email forms, uploads and paid API or model calls. Slow repeat attempts down rather than locking accounts forever.

What should you check before launch?

Check each area with evidence, not with the agent's summary.

Short on time? Run it as a gate; the first "no" is your next job.

1. Secret keys server-side and rotated? No: move and rotate them.
2. Every table and route checks the user? No: add RLS and server-side checks.
3. Packages real, intended and unflagged? No: remove or patch them.
4. Admin routes locked and logins rate limited? No: lock them and add limits.
5. No LLM feature, or one with least privilege and caps? Yes: ready to launch. No: cut its privileges and cap spend.

If several answers are no, read how to fix a vibe-coded app and decide between repair and rebuild.

How do you test a vibe-coded app with free tools?

Three free scans cover most of it, then a manual access test that no tool replaces. Scan only code and staging copies you own.

Gitleaks finds "secrets like passwords, API keys, and tokens in git repos, files" and can run as a pre-commit hook. npm audit asks your registry "for a report of known vulnerabilities" and by default exits non-zero when it finds one, so it can fail a CI build; OSV-Scanner checks dependencies against the open OSV database. The ZAP baseline scan spiders for one minute by default and only checks passively: "the script doesn’t perform any actual ‘attacks’". Audits know reported problems, not a package name invented last week.

How do you keep using AI coding tools safely?

Keep the agent fast and give it less power. Anthropic's Claude Code security page says "Claude Code starts with read-only permissions. When it needs to edit files, run tests, or execute commands, it asks you first," and "You’re responsible for reviewing proposed code and commands for safety before approval."

• Permissions. Allow tests and the formatter, deny reading .env files, keep production credentials off machines where agents run. The Nx malware tried to drive local AI tools. Anthropic "does not security-audit or manage any MCP server," so add only servers you trust.
• Review. Read every diff that touches sign-in, queries, uploads, payments or dependencies.
• Tests. For each protected resource, one test that the owner can read it and one that another user cannot.
• CI. Gitleaks and the audit run on every pull request.

My setup with hooks and deny rules is in my Claude Code workflow for client projects.

What else do people ask about vibe coding security?

Can AI-generated code have security vulnerabilities?

Yes. A model reproduces patterns it learned, insecure ones included, and optimizes for "make it work". Treat its code like a pull request from a new contributor.

What is slopsquatting?

Registering a package name that AI models invent, so anyone who installs the suggestion gets the attacker's code. It is typosquatting where the model makes the typo. Check new packages against the library's official docs first.

Is it safe to expose the Supabase anon key?

Only when row-level security and grants are right. Supabase says the anon role should keep "Only what signed-out visitors are meant to read." If the anon key alone returns private rows, fix the policies, not the key.

Can the AI review its own code for security?

It helps, but it should not be the last word. It cannot know your business rules, such as which staff role may refund an invoice. Pair it with scanners and a human read of risky files.

Do I need a penetration test before launch?

If the app holds personal data or takes payments, yes: a manual test of sign-in and authorization by someone who did not write the code. Scans find known problems; people find logic flaws.

If your app is about to take real users or payments, I can review it against this checklist, fix what it finds and set up the scans that keep it fixed. Hire Claude Code Developer: a free scoping call of about 30 minutes, a written quote within one business day, $55-$65 an hour or a fixed price.

Last reviewed 21 October 2026. Disclosure: I am a freelance developer who sells AI-assisted development and security review, so I am not neutral. I am CTO at ElySpace and founder of WHMCSPilot and MagizAI. I am not affiliated with OWASP, Anthropic or any tool vendor named here; Claude and Claude Code are trademarks of Anthropic, PBC. Quotes and figures were checked against the linked primary sources on that date.