Vibe Coding Security Risks: 8 Things to Check Before You Launch

"Vibe coding" means building software by describing what you want to an AI and accepting what it produces. It has put app building within reach of founders, designers and operators who could not code a year or two ago. It has also created a new kind of security gap: software that works, looks finished and was never reviewed by anyone who thinks like an attacker.

This guide lists the eight security risks we would check first in a vibe-coded app, why each one happens, and what to do about it. None of them require you to read code. They require you to ask the right questions before real users arrive.

Why AI-generated apps have a distinct risk profile

AI tools optimise for "it works". If a request fails because of a permission, the quickest way to make it work is often to remove the permission. If an API key is needed, the quickest place to put it is where the code can reach it, which may be the browser. The app passes every test the builder runs, because those tests are run as the owner.

That is why the weaknesses below are rarely dramatic code bugs. They are missing decisions: who is allowed to do this, where should this secret live, what happens if someone misuses this feature.

Risk 1: broken access control

The most common and most serious issue. One customer can read, change or delete another customer's records, or an ordinary user can reach admin functions, because checks exist only in the interface and not on the server or database. In Supabase projects this usually means missing or weak Row Level Security, which we cover in seven RLS mistakes AI-built apps make.

Test: use two accounts and try to access each other's data by changing IDs in URLs and requests.

Risk 2: exposed secrets

API keys, database passwords and service tokens end up in frontend code, in public repositories or in chat transcripts. Anything shipped to the browser is public, and keys committed to Git remain in the history even after the file is deleted.

Fix: keep secrets in server-side environment variables, search your bundle and repository for keys, and rotate anything that was ever exposed.

Risk 3: unvalidated input

Forms, URLs and API parameters are attacker-controlled. If the app builds database queries by joining strings, or prints user input into pages without encoding it, it may be open to SQL injection or cross-site scripting. Modern frameworks and query builders prevent most of this by default, but generated code sometimes bypasses them.

Fix: use parameterised queries, validate input on the server, and review any place where raw queries or raw HTML are built.

Risk 4: hallucinated and outdated dependencies

AI tools sometimes suggest software packages that do not exist. Attackers have started registering such names, with malicious code inside, hoping a developer or an automated tool installs them. This is sometimes called slopsquatting. Separately, generated projects often pin old versions with known vulnerabilities.

Fix: check that every dependency exists, is widely used and is the one you intended, commit your lockfile, and run a dependency vulnerability scan on every build.

Risk 5: insecure defaults

Examples include a permissive cross-origin setting that allows any site to call your API, debug mode left on in production, detailed error messages that reveal internals, public storage buckets, and default admin accounts. Each is a one-line change and each is easy to miss.

Fix: review production configuration separately from development, and turn off anything that exists only for convenience.

Risk 6: no limits on use or cost

Apps with AI features often call a paid model on behalf of every visitor. Without rate limits, per-user quotas and spend caps, a script can run up a large bill or take the service down. Login and sign-up forms without limits invite password guessing and bot sign-ups.

Fix: add rate limiting, set usage caps on every third-party key, and alert when spending jumps.

Risk 7: prompt injection in your own AI features

If your app lets a model read user content, browse pages or call tools, attackers can hide instructions in that content to steer the model. The danger rises with what the model can do: reading private data, sending messages or changing records. We explain the attack types and the testing in our guide to LLM red teaming versus a web app penetration test.

Fix: give the model's tools the least privilege possible, require human approval for risky actions, and treat everything the model outputs as untrusted.

Risk 8: no logging, so no way to know

Many vibe-coded apps cannot answer basic questions after something goes wrong: who accessed what, when did the error start, which request failed. Without logs and monitoring, an incident can run for weeks before anyone notices, and you cannot work out what was exposed.

Fix: centralise error logs, keep audit logs for sensitive actions, and set alerts that reach a real person.

A 30-minute security pass you can do today

1. Create two test accounts and try to see, change and delete each other's data.
2. Search your repository and built website code for API keys and service tokens.
3. Check which storage buckets and database tables are publicly readable.
4. Open your app's network requests and look for secrets, internal URLs or verbose errors.
5. List every dependency and confirm each is real, current and intended.
6. Confirm rate limits and spend caps exist on login, sign-up and any AI feature.
7. Check that errors and sensitive actions are logged somewhere you can read.

What AI tools can and cannot do about this

You can ask the AI to review its own code for these issues, and it will find some. But it works from the same assumptions that produced the problem, and it cannot test your deployed system with two real accounts. Treat an AI security review as a first pass, not a clearance.

When the stakes are real users, personal data or payments, bring in someone independent. An AI app technical audit covers access control, secrets, data permissions, payments and deployment and ends with a ranked fix list. If you already know what is broken, AI app repair and production launch fixes it and releases it in a controlled way. Our 20-point production checklist ties these checks together.