Security researchers found roughly 5,000 vibe-coded apps exposing user data — exposed API keys, missing access controls, databases readable by anyone with the URL. Every cited source on this topic sells a security scanner. We don't. Here are the 6 risks every AI-built app ships with, and how an engineering team actually fixes each one.
Security researchers reported, in findings covered by Wired and PCMag, roughly 5,000 vibe-coded apps exposing user data— API keys sitting in public frontend code, databases readable by anyone with the URL, login screens that guarded nothing. The internet noticed. Per DataForSEO Content Analysis, spring 2026, web mentions of “vibe coding” grew from about 21,700 a month in July 2025 to about 48,300 a month in April 2026 — more than doubling in nine months — and by April, negative-sentiment mentions outnumbered positive nearly three to one (23,264 negative vs. 7,992 positive). Here's the awkward part: nearly every article ranking for this topic is written by a company selling a security scanner. We don't sell one. We're a Southern California engineering shop that gets hired to fix these apps after the scanner report lands, and this is the field guide we wish our clients had read first: the six risks every AI-built app ships with, and how an engineering team actually closes each one.
Why are vibe-coded apps so often insecure?
AI models optimize for code that works in the demo, not code that survives an attacker — and nobody reads the code before shipping. That single sentence explains almost every headline. A model like Anthropic's Claude Fable 5, or whatever powers Lovable, Bolt, or Replit under the hood, is rewarded for producing something that runs and looks right. “Runs and looks right” and “resists a motivated stranger” are different properties, and only one of them is visible in a demo.
Two mechanisms make it worse. First, models learn from the code that exists, and an enormous share of public code — tutorials, quick-start repos, decade-old Stack Overflow answers — contains insecure patterns: hardcoded keys, string-built SQL queries, auth checks done in the browser. The AI faithfully reproduces what it was trained on. Second, the entire culture of vibe coding is speed. The point is to skip the slow parts, and code review is the slowest part of all. When the person prompting can't read the output and the workflow never pauses for someone who can, insecure code sails straight from generation to a public URL.
The failures are no longer hypothetical, and searchers know it: our DataForSEO pull (June 2026) shows searches for “vibe coding security” running roughly 3× year over year. People aren't asking because they're curious. They're asking because someone's app just made the news — or because their own API bill just tripled overnight.
What are the biggest vibe coding security risks?
Six risks account for nearly every vibe-coded breach we've seen: exposed secrets, missing auth, open databases, unvalidated input, bad dependencies, and prompt-degraded architecture. They show up across every builder and every model, because they're structural — consequences of how the code gets made, not of which tool made it.
1. API keys and secrets in frontend code
An API key embedded in frontend code is readable by anyone who opens their browser's dev tools — no hacking required, just View Source. It happens because the AI takes the shortest path: you ask for a feature that calls a paid API, and the model wires the key directly into the page, where it works instantly in the demo. Attackers run automated scrapers that harvest exposed keys within hours of deployment, then run up your OpenAI, Stripe, or Maps bill or use the key to reach the data behind it. The fix: rotate every key that ever touched the codebase (assume it's already harvested), move all secrets to server-side environment variables, and make every third-party call pass through a backend route the browser never sees inside.
2. Missing or client-side-only authentication
Hiding a page is not protecting it — if the server hands over data to anyone who asks, the login screen is theater. AI builders generate beautiful login flows, but the check often lives only in the browser: the UI hides the dashboard from logged-out users while the API behind it happily answers direct requests. This was the signature flaw in the 5,000-app research — apps that lookedlocked and weren't. The fix is to enforce authentication on the backend for every route and every API endpoint, and to verify it the blunt way: log out, then request your own API endpoints directly. If anything answers, it's open.
3. No database access rules
A database without access rules serves any row to any authenticated user — and sometimes to unauthenticated ones. Modern backends like Supabase and Firebase are secure by design, but their protection (row-level security, security rules) has to be switched on and written correctly, and AI builders frequently skip that step or generate rules so permissive they might as well not exist. The result is a customer table where user A can read user B's records by changing an ID in the request. The fix: enable row-level security on every table, write rules that scope each row to its owner, and test with a second account trying to read the first account's data. If the second account sees anything it shouldn't, the rules failed.
4. Unvalidated user input
Every text box in your app is a door, and unvalidated input is that door left unlocked — injection attacks have topped security lists for twenty years precisely because they keep working. AI-generated code often passes user input straight into database queries, file paths, or rendered HTML, because that's the shortest code that satisfies the prompt. An attacker who types a crafted string where a name should go can read tables, delete records, or plant scripts that run in other users' browsers. The fix: validate and sanitize everything on the server (never trust the frontend's checks), use parameterized queries everywhere, and escape output before rendering it.
5. Hallucinated and outdated dependencies
AI models recommend packages that are outdated, abandoned, or don't exist at all — and attackers have industrialized the response. When a model repeatedly hallucinates the same plausible-sounding package name, attackers register that name and fill it with malware, a technique known as slopsquatting; installs then succeed and the malicious code runs inside your app with full access. Even real packages arrive pinned to whatever version was common in the training data, often several known vulnerabilities ago. The fix: audit the dependency list (run npm auditor the equivalent), verify every package actually exists and is maintained, and update to patched versions before launch — then keep doing it, because new CVEs don't wait for your roadmap.
6. Prompt-degraded architecture
Every additional prompt can quietly weaken security that an earlier prompt added — the AI patches locally without understanding the whole system. Ask for a bug fix and the model may route around the auth middleware; ask for a faster page and it may cache data that was supposed to be private; ask for an export feature and encryption applied three weeks ago silently doesn't cover the new path. No single change looks wrong, which is why this risk is invisible to anyone reviewing prompts instead of code. The fix is periodic whole-system review: an engineer reads the auth flow, the data flow, and the change history end to end — not just the latest diff — and re-verifies that the protections you added in week one still hold in week ten.
How do you secure a vibe-coded app before launch?
Run this order of operations: secrets, authentication, database rules, input validation, dependencies, then a human review of the data flows. The order matters — it's sorted by blast radius, so the failures that cost the most get closed first:
- Rotate and relocate every secret. Treat any key that ever appeared in the code as compromised. Rotate them all, move them to server-side environment variables, and search the frontend bundle to confirm nothing leaks.
- Verify backend authentication. Log out and hit your API endpoints directly. Every route that returns data must reject the request — hiding buttons in the UI counts for nothing.
- Turn on and test database access rules. Enable row-level security, scope rows to their owners, then attack it yourself with a second account.
- Validate all input on the server. Parameterized queries, sanitized fields, escaped output. Assume every form will eventually be filled in by someone hostile.
- Audit the dependencies. Confirm every package is real, maintained, and patched. Remove anything you can't account for.
- Have an engineer read the data flows. One pass by someone who can trace where data enters, where it's stored, and who can reach it. This is the step that catches what the first five can't.
For an internal tool with no sensitive data, steps one through five may genuinely be enough. The moment customer data, payments, or logins are involved, step six stops being optional.
Why isn't a security scanner enough?
Scanners catch known patterns; they can't tell you that the wrong user can see the right data. That distinction — authentication versus authorization — is where scanner coverage ends. A scanner can confirm your login system exists and your secrets aren't in the bundle. It cannot know that in yourbusiness, a contractor should see the jobs assigned to them but not the client's billing history, because that rule lives in your head, not in any vulnerability database.
To be fair to the scanner vendors: their tools are genuinely useful, and we use them. Exposed secrets, vulnerable dependency versions, common injection shapes — automated detection handles those faster than any human. Treat that as the floor. What sits above the floor is everything a scanner is structurally blind to: business-logic flaws (the discount code that stacks forever, the status change that skips approval), authorization gaps, and the cross-prompt design drift from risk six — a system whose individual pieces all pass inspection while the way they're wired together leaks. Those only surface when someone who understands both the code and the business reads how data actually moves through the app. A clean scan report on a vibe-coded app is a good sign, not a green light.
What if the app is already live?
Assume exposure, rotate every secret, and audit before adding a single new feature. If keys were ever in the frontend, treat the data they guarded as read; if auth was ever client-side-only, treat the database as browsed. That sounds harsh, but automated harvesting is fast enough that “probably nobody noticed” is not a plan. Check your provider dashboards for usage you don't recognize — an unexplained API bill is often the first symptom — and freeze feature work until the six risks above are verifiably closed, because every new prompt on an unaudited codebase widens the surface.
The good news: a live vibe-coded app is usually rescuable, and the rescue is cheaper than a rebuild more often than the horror stories suggest. We wrote the full playbook — triage order, refactor-vs-rebuild math, what to expect from an engineering audit — in how to fix a vibe-coded app. If you're still weighing whether AI-first building was the right call at all, our broader verdict is in is vibe coding bad; and if you haven't built yet and are choosing a tool, start with the capability map in can AI build an app.
Want a real security read on your AI-built app?
Tell us what you built and we'll run an engineer-led audit of the parts scanners miss: secrets, authentication, database rules, and how data actually flows through your app. You get the findings in plain English — what's exposed, what's fine, what to fix first — and an honest quote for the fixes, whether or not we're the ones who do them.
Prefer to talk it through? Call us directly at (909) 662-4058 . No intake form required.
Frequently asked questions
What are the security risks of vibe coding?
The six recurring risks in AI-generated apps are: API keys and secrets embedded in frontend code, missing or client-side-only authentication, absent database access rules (like missing row-level security), unvalidated user input enabling injection attacks, hallucinated or outdated dependencies that attackers can exploit, and architecture that degrades with every additional prompt. None of these announce themselves — the app works fine in a demo while being exploitable in production.
How do I make a vibe-coded app secure?
Start with the highest-blast-radius items: rotate every API key that ever touched the code and move secrets server-side; verify authentication is enforced on the backend, not just hidden in the UI; turn on and test database access rules; validate all user input on the server. Then run a dependency audit and have an engineer review the data flows. Automated scanners catch some of this; they can't tell you whether your business logic gives the wrong user access to the right data.
Are AI app builders secure?
The platforms themselves (Lovable, Replit, Bolt, Base44) are reasonably secure infrastructure — the insecurity is in what gets generated and shipped without review. AI models optimize for code that works in the demo, not code that resists attack, and they inherit insecure patterns from their training data. Platform defaults are improving, but every study of AI-generated code to date finds a meaningful share contains exploitable flaws.
How do I know if my AI-built app has already been exposed?
Check the obvious blast doors first: search your frontend bundle for API keys (open dev tools, view source, search for 'key', 'secret', 'sk-'), test whether your database or API endpoints respond without being logged in, and review provider dashboards for usage you don't recognize — unexpected API charges are often the first symptom. If you find an exposed key, rotate it immediately and assume the data it guarded was read.
Do security scanners fix vibe coding risks?
Scanners catch known patterns — exposed secrets, vulnerable dependency versions, common injection shapes. They don't catch broken business logic, missing authorization (who is allowed to see what), or design flaws spread across multiple AI-generated changes. Treat scanners as the floor, not the fix: useful for triage, not a substitute for an engineer reading how data actually flows through the app.