English
Vibe Coding: The Billion-Dollar App and the Security Debt No One Talks About

Vibe Coding: The Billion-Dollar App and the Security Debt No One Talks About

Prompt-to-app development is exploding. So are the data leaks. 38 million records exposed through Power Apps alone, 125 million through Firebase, 40% of AI-generated code found vulnerable. Here's why governance, not better prompts, is the answer.

\"Generate me a billion-dollar app\" is a great prompt. Until your customer data ends up on the open internet.

Vibe coding, the practice of building software through natural language prompts and AI assistants, has gone from Twitter trend to enterprise reality in under two years. GitHub describes it as \"natural language-driven, AI-assisted programming.\" Google Cloud extends it to \"vibe deploying\": a prompt that generates not just code, but deployment steps into production-like environments.

The appeal is obvious. Non-technical employees can build internal tools. Prototypes go from idea to working app in hours. Development teams ship faster than ever. The market for low-code/no-code platforms, the broader ecosystem vibe coding lives in, is growing explosively.

But the security track record tells a different story.

The incidents that should stop you in your tracks

In 2021, security firm UpGuard discovered that Microsoft Power Apps Portals were exposing data through anonymous OData feeds. The scale: 38 million records across 47 organizations, including contact tracing data, vaccination appointments, Social Security numbers, and employee IDs. The root cause wasn't a sophisticated exploit. It was a configuration combination that was frequently set incorrectly: OData endpoints enabled, table permissions not enforced.

In Firebase, the backend-as-a-service that powers countless vibe-coded apps, researchers found mass exposures through misconfigured security rules. One scan identified approximately 125 million user records as extractable across roughly 900 sites. Firebase's own documentation warns about this, but the platform \"allows for easy misconfiguration with zero warnings.\"

In 2025, no-code app builder Passion.io exposed 3.6 million records (12.2 TB) through an unprotected, unencrypted database, personal data, billing information, business data, all publicly accessible.

And at Retool, a targeted smishing attack in 2023 led to unauthorized access to 27 cloud customer accounts through compromised MFA tokens, demonstrating that builder platforms become force multipliers when identities are compromised.

Why vibe-coded apps break differently

Traditional software has traditional vulnerabilities: SQL injection, buffer overflows, authentication bypasses. Vibe-coded and low-code apps break along different fault lines, and most security teams aren't trained to find them.

Configuration as code, but without code review. In low-code platforms, security isn't in the source code. It's in permission settings, connector scopes, data sharing rules, and table access policies. These are configured through UI toggles, not written in files that get reviewed in pull requests. The Power Apps incident proves what happens when this configuration is wrong: millions of records exposed, with no traditional vulnerability to patch.

Authorization lives in the UI, not on the server. Mendix explicitly warns: \"Any user can talk directly to the API.\" If access control is implemented only as UI restrictions, hiding buttons, filtering views, an attacker who speaks directly to the API sees everything. This is a fundamental architectural mistake that's endemic in low-code development.

Connectors are privilege amplifiers. When a vibe-coded app connects to your CRM, ERP, email, or file storage through a service account, that connector's permissions become the app's permissions. Google warns that sharing a powerful default service account across multiple apps is \"very risky.\" But in low-code platforms, sharing service connections between apps and users is a first-class feature, and a direct path to privilege amplification.

AI-generated code introduces new supply chain risks. A large-scale study found over 205,000 unique hallucinated package names in AI-generated code. Attackers publish packages under these hallucinated names (\"slopsquatting\") and wait for them to be blindly installed. Meanwhile, Pearce et al. found approximately 40% of Copilot-generated code to be vulnerable in CWE-relevant scenarios. LLMs don't generate \"secure by default\", they generate \"plausible by default.\"

Zombie apps never die. OWASP identifies asset management as a core low-code risk: apps are built quickly, rarely decommissioned properly, and remain active with their connectors and permissions long after anyone remembers they exist.

The governance gap at the heart of vibe coding

The common thread across every incident and every risk category is the same: governance.

Not \"better prompts.\" Not \"more secure AI models.\" Governance, the organizational and technical framework that controls which data flows where, who has access to what, and what happens when something goes wrong.

OWASP's Citizen Development Top 10 names \"Blind Trust\" as a foundational risk: citizen developers lack security training, and automation bias leads them to assume that platform-generated code and templates are \"inherently secure.\" This is structurally embedded in the vibe coding narrative, speed, flow, \"forget the code.\"

The result is a predictable pattern: apps go live without threat modeling, with overprivileged connectors, without logging, without incident response plans, and without anyone who's accountable for security.

What this means for enterprises deploying AI

The vibe coding explosion is not going to slow down. Gartner projects massive GenAI adoption in enterprises by 2026. OWASP has already expanded its low-code/no-code risk taxonomy to include AI-assisted coding and AI agents. The number of people building software is growing far faster than the number of people securing it.

The companies that will avoid the next 38-million-record exposure are the ones building governance into the foundation:

Deny by default. Every data endpoint, every connector, every API should require explicit permission, not implicit trust. The Power Apps and Firebase incidents both trace back to defaults that were too open.

Treat every connector as a blast radius. Separate service identities per app. Enforce least privilege on every integration. Audit connector scopes quarterly. A compromised connector to your CRM shouldn't also unlock your email, your file storage, and your ERP.

Gate publishing, not just building. The moment of risk is not when someone builds an app, it's when they publish it. Pre-publish security checks, permission diffs, and public endpoint scanning should be mandatory gates, not optional steps.

Make governance the easiest path. If your developers have to choose between \"prompt and ship in 20 minutes\" and \"prompt, wait for security review, ship in two weeks,\" they'll choose speed every time. The governance layer needs to be embedded in the workflow, invisible, automatic, and non-negotiable.

Log everything, because you can't investigate what you can't see. OWASP flags insufficient logging as a systemic low-code problem. If you can't trace which data was accessed, which connectors were invoked, and which actions were triggered, you can't respond to incidents, and you can't prove compliance.

The future of software development is faster, more accessible, and more AI-driven than ever. That's not a problem, it's an opportunity. But only if the governance architecture keeps pace with the speed of creation.

hegyon.ai governs the layer between your people, your data, and AI, whether they're querying models, building apps, or connecting systems. Every data flow is policy-enforced. Every interaction is logged. Every connector is scoped. Because in the age of vibe coding, the biggest risk isn't bad code. It's ungoverned data.

← Back to all posts