TL;DR. Vibe coding security problems are predictable. A 2026 academic audit of 200 deployed apps built with AI coding tools found at least one vulnerability in 91% of them, and about two thirds of those flaws were rated Critical or High. Most sit in five places: database access rules, server-side authorization, exposed secrets, login edge cases and unvalidated input. You can check most of them yourself in an afternoon, and most AI-built apps can be hardened rather than rebuilt.

You built the app in a few weeks with Lovable, Bolt, Replit, Cursor or Claude Code. People signed up. Some of them are paying. It works.

“It works” and “it is safe to put customer data in” are two different tests, and the AI tools that got you here mostly optimize for the first one. That is not a knock on the tools. They were the right way to get from idea to product. It just means vibe coding security is now your job, and you probably do not have a security engineer to hand it to.

The good news is that vibe coding security holes are not random. They show up in the same places in app after app, which means you can go looking for them.

What the research says about vibe coding security

The most thorough look so far is a paper from researchers Junquan Deng, Zhiyu Fan and Ruijie Meng, Understanding the (In)Security of Vibe-Coded Applications, first posted in June 2026 and revised in September. They collected 9,041 open-source apps built with Claude Code and Lovable, then audited 200 apps that were live on the public internet.

Across those 200 apps they found 1,186 vulnerabilities. 91% of the apps had at least one. 65.77% of the vulnerabilities were rated Critical or High. Most fell into three categories: broken access control, injection and authentication.

One vibe coding security finding matters a lot for founders. Better prompting and better agent setups reduced the number of vulnerabilities, but did not eliminate them. “Make it secure” in the prompt helps. It does not replace checking.

This is not theoretical. In May 2025, security researcher Matt Palmer disclosed CVE-2025-48757 after scanning 1,645 apps from Lovable’s public showcase and finding 170 of them exposing data through missing or weak database access rules. The vibe coding security debate afterward was about whether the platform or the app owner was responsible. For the founder whose customer data was exposed, that debate did not change much.

Why AI-built apps leave the same holes

An AI coding agent builds what you ask for and checks that it runs. When you say “users can see their orders,” it builds a page that shows orders. Whether a user can also see someone else’s orders by changing a number in the URL is a question you did not ask, so it often does not get answered.

The paper groups the root causes into three kinds of agent limitation. The agent forgets earlier decisions as the project grows. It optimizes for the visible goal (the feature works) rather than the invisible one (only the right people can use it). And it sometimes lacks current knowledge of how a library or platform should be configured safely.

Security is almost entirely invisible requirements. That is why vibe coding security fails in predictable places. Nothing on screen tells the agent, or you, that a rule is missing.

The five holes to close before you launch

1. Database access rules that are off or wide open

Many AI builders put a Supabase or Firebase backend behind the app, and the browser talks to the database more or less directly. That is fine only if the database enforces who can read and write each row. Supabase’s own row level security guide is blunt about it: a table in an exposed schema without row level security is readable and writable by any role with a grant on it.

The other common failure is a policy that exists but allows everything, the database equivalent of a lock that is installed but never closed. A policy that says “true” passes every check on a dashboard and protects nothing.

2. Missing authorization on the server

Authentication answers “who are you.” Authorization answers “are you allowed to touch this.” AI-built apps usually get the first one right because there is a login screen to look at. The second one lives in every API route and server function, and it is easy to skip. The classic symptom: user A can edit user B’s profile, invoice or project by changing an ID in a request.

3. Secrets shipped to the browser

Your app talks to Stripe, OpenAI, an email service, and its own database with an admin key. If any of those keys end up in the JavaScript that loads in the browser, anyone can copy them. Supabase’s docs say it directly: never use a secret key in the browser. An exposed OpenAI key costs money. An exposed database admin key gives away everything.

4. Login edge cases and no rate limits

Sign-up, login and password reset are where attackers start, and where AI-generated code tends to handle the happy path only. Can someone try 10,000 passwords against one account? Can they trigger unlimited reset emails? If you added Google sign-in, does the app quietly merge accounts just because two email addresses match? Each of these is a short fix, and each one is easy to miss.

5. Trusting input it should not trust

Injection was the second biggest category in the research. Any place your app builds a database query, a file path or a shell command from user input is a candidate. If your product calls an LLM, the same idea applies to prompts: text a user types can carry instructions, and the model may follow them unless you limit what it can do.

A one-afternoon vibe coding security self-check

You do not need to read code to run most of these. You need two test accounts, a browser and a couple of hours. As of November 2026, this is the list we would run on any AI-built app before it takes payments:

• Two-user test. Create user A and user B. Log in as A, open something that belongs to A, and note the ID in the URL or request. Log in as B and try that ID. If B sees A’s data, you have hole number 2.
• Database dashboard check. In Supabase, open each table and confirm row level security is enabled and that no policy simply says “true.” Do the same for storage buckets.
• Secret search. Open your browser’s developer tools, go to the Sources or Network tab, and search the loaded JavaScript for “sk_”, “secret”, “service_role” and “key”. Anything that looks like a private key is hole number 3.
• Login abuse test. Try 20 wrong passwords in a row, then request 20 password resets. If nothing slows you down, add rate limits.
• Dependency scan. Ask your AI tool to run npm audit (or the equivalent) and show you the critical and high results.
• Ask the agent to attack its own app. Prompt it to review every API route for missing authorization checks and list them. Treat the list as a starting point, not a clean bill of health.

If all six come back clean, you are ahead of most AI-built apps on the internet. If they do not, you now know where to start, which is more than most founders know the week before launch.

Harden or rebuild: what to do with what you find

Founders often assume a vibe coding security problem means starting over. Usually it does not. The interface, the product logic and the data you have collected are worth keeping. The fixes for the five holes above are mostly additions: policies on tables, checks in routes, keys moved to the server, limits on login.

Hardening is the right call when the data model makes sense and the app has a clear separation between what runs in the browser and what runs on the server. Most AI-built apps with a few dozen screens fall here.

A rebuild starts to make sense when the browser talks directly to the database for everything, the data model has drifted into duplicates and workarounds, and every fix breaks something else. Even then, the prototype is not wasted. It is the most detailed requirements document you will ever have, because it shows exactly how the product should behave.

We wrote more about where the remaining work hides in why AI-generated code is only 70% done. Vibe coding security is a big share of that last 30%.

How LoadSys takes an AI-built app to production

We start by turning your working prototype into a written spec. The spec captures what the app does today, and it adds the invisible requirements the prototype never had: who can read and write each kind of record, which keys live where, what gets rate limited, what happens when a login fails. That spec becomes the source of truth for everyone, including the AI coding agents.

From there our senior engineers harden or rebuild against the spec, using the same AI tools you used, and then verify the result against it. Verification is the step vibe coding skips, and it is where vibe coding security problems get caught.

These are the same requirements we write for established companies. On our recent ACLSOnline V2 rebuild, the security work included authorization checks so users cannot edit each other’s records, rate limits on login, registration and password reset, no account linking by matching email addresses, and a stored email password replaced with managed identity. None of that shows up in a demo. All of it matters the day someone goes looking. Our AI-Assisted Development service is built for exactly this handoff.

Frequently asked questions

If your self-check turned up more than you can fix this week, talk to an AI engineer at LoadSys. We will look at what you built, tell you what to keep, and give you a plan to get it safely in front of customers.