Table of Contents
Staff and founders are shipping AI-built apps faster than anyone can review them. This guide to vibe coding security shows where the debt hides, five checks to run before launch, and how to decide whether to keep, fix or rebuild.
On November 5, 2026, a systems administrator posted a weary complaint to Reddit’s r/sysadmin forum. Colleague after colleague kept arriving with apps they had built with AI, each asking for sweeping access to company systems, and none could say where the data would live. The thread drew roughly 530 upvotes and 223 comments, and the top reply needed only seven words: “It is the new excel macro nightmare.”
A rogue spreadsheet macro lived on one person’s laptop. A vibe-coded app has a login page, a database and a public web address, and it can be built between lunch and the last meeting of the day.
That speed is real, and it is worth keeping. But speed bought without review is a loan. Every shortcut the AI took to make the demo work, and every rule nobody asked it to follow, sits on the books as security debt. The interest falls due the day real customer data arrives.
Vibe coding security is the work of making an AI-built app safe for real users and real data: who can read the database, where secret keys live, whether the server checks every request, and who owns the app when it breaks. This guide shows owners and IT leads how to size that debt in an afternoon, and when calling in engineers is cheaper than borrowing more.
In brief
- In a 2026 academic audit of 200 live vibe-coded apps, 91% had at least one security flaw.
- The usual vibe coding security failure is a missing access rule, not sophisticated hacking.
- Five checks and one verdict (keep, fix or rebuild) settle most cases.
Vibe coding security: why AI-built apps fail in production
Most vibe coding security failures come from rules nobody stated, not from clever attacks. Vibe coding means describing the app you want in plain language and letting an AI tool such as Lovable, Bolt, Replit or Claude Code write it. The result usually works. The trouble is that “works” and “safe” are different tests, and only one of them shows up in a demo.
Most vibe-coded apps ship with security flaws. A research team with authors from Microsoft and the National University of Singapore audited 200 publicly deployed vibe-coded apps in 2026. They confirmed 1,186 vulnerabilities, each checked by two human reviewers. In that audit, 91% of apps had at least one security flaw, and about two thirds of flaws were critical or high.
The same study explains how this happens. The typical app in its wider sample ran to about 8,000 lines of code, written in just over eight days. Nobody reviews that much code in that little time.
Three failures dominate. Together they make up 60% of all the vulnerabilities the researchers confirmed, and each one has a plain meaning:
- Broken access control (64% of apps): people can see or change data that is not theirs. It is the top risk on the OWASP Top 10 and the most common flaw in the study, with 339 of the 1,186 vulnerabilities. Most of it sat in server code that did not properly check who was asking. In one live healthcare platform, it exposed a large volume of customer information.
- Injection (54% of apps): hostile input is treated as instructions. Text typed into a form or a web address reaches the database or the page unchecked, and the app runs it as a command. One injection flaw the researchers found gave an attacker full control of the app’s server.
- Login and session failures (51.5% of apps): identity checks can be sidestepped. In one app, the AI added a back-door login route with a hard-coded password to get past a sign-in error, creating a critical vulnerability.
The open database is the signature flaw. In August 2026, the app-monitoring firm Reeve scanned 30,998 live AI-built apps. Of the 3,680 Supabase-backed apps whose database Reeve could test, 2,096 (57%) let a stranger read at least one table without logging in. In 394 of them, the exposed tables had names like users, orders or messages.
In fall 2026, the security firm UpGuard went wider, probing about 300,000 sites. UpGuard counted 16,326 Supabase databases with tables anyone could read, more than half with signs of personal data.
When a person creates a table in the Supabase dashboard, row-level security (the rule that lets each user see only their own rows) is switched on automatically. When an AI agent creates the same table through code, it is not. The lock exists. The AI was simply never asked to turn the key.
Three ways the debt builds up
The academic team traced every flaw back to its origin.
- Rules nobody stated (63% of flaws). Hash the passwords, check permissions on the server, validate what users type. Engineers apply these by reflex. An AI builds what was asked, and the app looks identical with or without them.
- Shortcuts taken for the demo (23%). A login check relaxed to clear an error, a placeholder key, encryption that only pretends. Each one made the demo work, then stayed in the product.
- Promises forgotten (14%). A protection added to new pages but never to old ones, or a password check marked “to do” and shipped that way.
The researchers also replayed the original build tasks. In about a fifth of the runs where a flaw came back, the AI had noted the risk in its own working and shipped the code anyway.
Not every warning is an emergency. Reeve found at least one issue in 99% of the vibe-coded apps it scanned, but most of those were missing browser security headers: worth fixing, yet not where the real danger is. A public key showing in the page is also normal, because these platforms are built to work that way. The critical gaps are hidden in a few settings that only the app’s builder can change, such as table access rules and where secret keys are stored. That is good news for vibe coding security. The risk is concentrated, so a quick, focused review can find it.
Five vibe coding security checks before you launch
Five checks cover where the serious flaws cluster: open tables, secret keys in the browser, missing server checks, switched-off safeguards and missing ownership. You do not need to read code to run most of these. You need the builder in the room, an hour or two, and a willingness to hear awkward answers.
- Can a stranger read your database? Ask the vibe-coded app’s builder to open the database dashboard and show that every table has access rules switched on. Supabase’s Security Advisor flags an unprotected table in plain words, and Firebase has an equivalent in its security rules. Any table holding names, emails, orders or messages must never be public.
- Are any secret keys sitting in the browser? Some keys are meant to be public. Others can spend your money or unlock the whole database. Payment secret keys, AI provider keys and database admin keys belong on a server, never in the page, and a secret scanning tool will find strays in minutes. In Reeve’s scan, 52 apps had shipped exactly that kind of key to every visitor.
- Does the server check who is asking, every time? Log in as one user and open a record. Then change the ID in the address bar to someone else’s. If their data appears, the app is hiding buttons rather than enforcing rules. This is the broken access control found in 64% of audited apps.
- What did the AI switch off to make it work? Ask the tool to list every place where a check was relaxed, a test login was added or a task was left unfinished. Search the project for words such as bypass, demo and temporary. Shortcuts taken while debugging are the debt most likely to be forgotten.
- Who owns it on a bad day? Name the person who gets the call when it breaks. Confirm where the data is stored, whether it is backed up, which other systems the app can reach, and what happens when the builder leaves. If nobody can answer, the app has a creator but no owner.
Checks 1, 2 and 5 are conversations. Checks 3 and 4 are where a trained eye earns its keep, because the dangerous cases look fine from the outside. Scanners make a useful first pass, but even the firms that sell them warn that a clean scan is not an audit.
Keep, fix or rebuild your vibe-coded app?
Keep a low-stakes internal tool, fix an app with real users but a sound foundation, and rebuild anything that holds payment, health or financial data on a tangled one. Once you know what is inside your AI-built app, you need a verdict. Two questions settle most cases. What would it cost you if this app’s data leaked? And is the foundation worth building on?
| Verdict | When it fits | What the work looks like |
|---|---|---|
| Keep | An internal tool with low-stakes data, a few known users and no link to core systems | Pass the five checks, put it behind company sign-in, name an owner, and look again when its use grows |
| Fix | Real users or sensitive data, but a sensible data model and code an engineer can follow | A hardening pass: access rules on every table and route, secrets moved to the server, tests on the critical paths, logging and backups |
| Rebuild | Payments, health or financial data on a tangled foundation, where each fix breaks something else | Engineers rebuild on a secure base, using the prototype as a working specification |
A rebuild is not a verdict of failure. The prototype has already done the hardest job in software, which is proving what people actually want.
The real mistake is to skip the verdict. The researchers behind the 200-app audit closed with blunt advice: treat a generated app as a prototype until someone has checked it, and do not expose it casually to real users.
The line usually falls at the moment of exposure: customer data, payments, or a connection into the systems that run the business. Before that moment, keep experimenting. After it, you are running production software, whether or not anyone decided to.
How much does a vibe coding security review cost?
Cost depends on the app, so anyone quoting a figure before seeing it is guessing. Four things drive the price.
- Size and sprawl. More screens, more routes and more code mean more to check.
- Roles and data. An app with customers, staff and administrators has far more ways to leak than a single-user tool. Personal, payment or health data raises the bar again.
- Connections. Every link to a CRM, a payment provider or a company account is another door to test.
- Depth. There are three levels of scrutiny, and they are not interchangeable.
| Level | What it does | Where it stops |
|---|---|---|
| Automated scan | Checks from the outside for open tables, exposed keys and missing headers, in minutes | Cannot tell which data should be private, or test logic behind a login |
| Production-readiness review | An engineer reads the code and configuration, tests access as different users and returns a prioritized fix list | Finds and ranks the problems; the fixes are scoped separately |
| Penetration test | Specialists attack the running app the way a real adversary would | Proves the holes exist; does not redesign a weak foundation |
At HyScaler, pricing follows an engineering call. We look at the application first, then send a scoped proposal: fixed-scope for a one-off review, or a retainer for testing alongside every release. Security testing sits within our testing and QA practice, and covers vulnerability assessment, penetration testing, authentication testing and access control verification. The test plans and defect reports land in your repositories, so the work stays yours.
Set that against the other side of the ledger. A table of personal data that anyone could read may count as a reportable breach under laws such as GDPR. Without logs, you cannot prove that nobody looked.
Debt is cheapest to repay before the interest compounds. That means before launch, before the first thousand customers, and before the first awkward email from a stranger who found your users table.
How can staff build AI apps safely?
Banning the tools behind vibe-coded apps does not work. People carry on with personal accounts, and the apps simply vanish from view. The better answer is a paved road, where the safe route is also the easy one.
- Company accounts, not personal ones. Pay for the tools centrally. You can see who is building, and customer data does not end up in someone’s private account.
- One sanctioned place to deploy. Offer a staging space behind company sign-in and closed to the internet by default. Anything may be built there, and nothing is invisible.
- Three questions for every app. Where does the data live? Who can reach it, and who owns it when the builder leaves? What does it connect to? An app whose maker cannot answer is not ready for real data.
- House rules the AI inherits. Keep a short instructions file with your defaults: access rules on every table, secrets on the server, no test logins. In the academic study, telling the AI to build for production cut the reappearance of known flaws from about 26% to 11%. That helps, but nothing removed them all.
- A review gate before real data. The moment an app will hold customer records, take payments or touch core systems, an engineer reviews it. No exceptions and no blame.
This is the part most small firms cannot staff alone, and it is where a partner earns its place: setting up the secure starter templates and deployment space once, then reviewing apps as they graduate. Your team keeps its speed. The business keeps its data.
Vibe coding security FAQ
Is vibe coding safe for production use?
It can be, but not by default. The tools build working software quickly, yet they do not reliably apply security rules nobody asked for. An app is production-safe once a qualified person has reviewed its access rules, secrets and ownership.
How many vibe-coded apps have security flaws?
In a 2026 academic audit of 200 deployed apps, 91% had at least one confirmed vulnerability. Roughly two thirds of the flaws were rated critical or high.
Is the API key in my app’s code a problem?
It depends on the key. Publishable keys are designed to be visible, and the protection comes from the access rules behind them. Secret keys for payments, AI services or database administration must never reach the browser.
When should we bring in engineers?
Before the app holds customer data, takes payments or connects to systems the business depends on. A review before launch is a planned expense. A leak is not.
What is the biggest security risk in vibe-coded apps?
Missing access rules. Broken access control appeared in 64% of the 200 audited apps, often because nobody told the AI who may see each record.
Pay the debt down before it compounds
Vibe coding has made building cheap. It has not made production cheap, and the gap between the two is where businesses get hurt.
HyScaler’s engineers review AI-built apps for the vibe coding security failures described here, then help you keep, fix or rebuild.
Get a production-readiness review of your AI-built app. Book 30 minutes with an engineer. There is no pitch deck, just a straight answer on where your app stands.