The Vibe-Coding Security Crisis: How AI-Generated Apps Ship Critical Vulnerabilities

A founder ships a SaaS product in a weekend. The landing page is polished, payments work, sign-ups are flowing. What the founder cannot see is that the public anonymous key embedded in the browser bundle lets anyone on the internet read the entire users table: emails, phone numbers, subscription status, and a few third-party API keys for good measure. No login required, no exploit chain, just a slightly modified database query. This is not a hypothetical. It is the documented failure mode behind CVE-2025-48757, and it sat exposed across hundreds of live applications before anyone with defensive intent went looking.

The speed that makes AI-assisted development feel magical is the same speed that compresses years of accumulated security debt into a single afternoon. "Vibe coding" — describing what you want in natural language and accepting whatever the model produces — has moved real revenue onto code that no human security-reviewed. The result is not a fringe edge case. It is a measurable, repeatable pattern of critical exposures shipping to production, and the people who pay for it are not the platforms. They are the small teams and end users whose data was never protected in the first place.

What "vibe coding" actually breaks

Vibe coding does not invent new vulnerability classes. It re-introduces old ones at scale, in projects with no security review step to catch them. The failure modes cluster into three recurring categories, and each maps cleanly to an exposure a security team can detect from the outside.

The first is missing or misconfigured authorization at the data layer — the application trusts the client to ask only for data it is allowed to see. The second is secrets shipped to the browser — API keys, service credentials, and tokens baked into the frontend bundle where anyone can read them. The third is absent rate limiting and authentication on endpoints that quietly assume "nobody will find this." Together they form the anatomy of nearly every vibe-coding incident reported to date.

What makes these dangerous is not their novelty but their invisibility to the person who shipped them. The app works. The demo passes. The vulnerability only becomes visible from the attacker's vantage point — the external perspective — which is exactly the lens that external attack surface management is built to provide.

Case study: CVE-2025-48757 and the Lovable RLS breakdown

In March 2025, security researcher Matt Palmer noticed something while examining a site built on the AI app platform Lovable: modifying a single database query returned every row in the project's users table. The platform generated frontend applications that talk directly to a Supabase backend over its REST API, authenticating with a public, unprivileged anonymous key embedded in the client. The entire security model rested on one assumption — that Postgres Row-Level Security policies would enforce who could read and write what.

That assumption did not hold. The vulnerability, now tracked as CVE-2025-48757 and rated CVSS 9.3 (Critical) under CWE-863, Incorrect Authorization, is described by NVD as "an insufficient database Row-Level Security policy in Lovable through 2025-04-15 [that] allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." Read or write. Arbitrary tables. No authentication.

Palmer wrote a crawler against 1,645 Lovable-powered projects and found 303 insecure endpoints across 170 sites — roughly 10.3% of the fleet — leaking usernames, email addresses, phone numbers, payment and subscription status, developer credentials, and third-party API keys including Gemini and Google Maps credentials. The platform later added a scan feature that flags whether an RLS policy exists on a table, but as reporting noted, it did not verify that the policy actually prevented unauthorized access. The full technical writeup is detailed in Superblocks' analysis of the incident.

An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites.— NVD, CVE-2025-48757

To be fair to the platform: it disputed the finding, arguing that each customer accepts responsibility for protecting their own application's data. That position is defensible in a strict reading of the shared-responsibility model. But it also sidesteps the practical reality that the customers building on these tools are precisely the people least equipped to write a correct RLS policy — which is the entire reason they reached for an AI app builder. A secure default would have prevented the exposure regardless of who is nominally responsible. The deep mechanics of how RLS gaps leak data are worth understanding in full, and we cover them in our companion piece on Supabase RLS data exposure.

The exposed-secrets pattern

The second category is more pervasive and, if anything, easier to exploit. AI coding assistants are trained to make things work, and the fastest way to make an integration work is to put the key where the code can reach it. When the code runs in the browser, that means the key ships to the browser.

We routinely see Stripe keys, OpenAI and Gemini tokens, mapping credentials, and even cloud provider keys hardcoded into JavaScript bundles, sitting one "view source" away from any visitor. This is the leaked API keys in frontend exposure, and it is the natural consequence of a generation process that has no concept of a trust boundary. The same pattern shows up server-side as an exposed .env file when a deployment includes files it never should have, and as an exposed Git directory when the whole repository — secrets, history, and all — is served as static content.

The OWASP community has formalized this risk in CWE-798, Use of Hard-coded Credentials, and in CWE-200, Exposure of Sensitive Information to an Unauthorized Actor. These are not exotic findings. They are among the most consistently exploited weaknesses on the internet, and the AI-generated app boom has multiplied their supply. We go deeper on detection and rotation strategy in our guide to exposed secrets and API keys in the AI era.

Missing auth and missing rate limits

The third pattern is the quietest. AI-generated backends frequently expose endpoints that should require authentication but do not, or that enforce authentication but skip the check on whether the authenticated user owns the resource they are requesting. This is the difference between an unauthenticated API endpoint — where no credentials are needed at all — and broken object-level authorization, where an attacker simply increments an ID and reads someone else's record. BOLA sits at the top of the OWASP API Security Top 10 for a reason: it is trivially exploitable and devastating in impact.

Rate limiting is the companion gap. Without it, an unprotected API can be brute-forced, scraped, or used to run up a six-figure cloud bill against a metered AI backend. A December 2025 study by Tenzai tested applications across five major AI coding platforms and found that every single tool introduced server-side request forgery vulnerabilities in its output — the kind of flaw that turns a missing-validation endpoint into a pivot point against internal infrastructure. SSRF as a generated-by-default behavior is a sobering signal; our exposure reference covers server-side request forgery in detail.

That last row matters more than it looks. Vibe-coded stacks lean heavily on managed and self-hosted backing services wired up from quickstart templates. When those templates bind to a public interface without a password, you end up with an exposed Redis instance or an exposed MongoDB database — entire datasets reachable from the open internet, no application bug required.

Scanner noise versus a validated finding

Here is where most security tooling fails the vibe-coding generation. A traditional vulnerability scanner crawls your endpoints, matches signatures, and produces a report full of "potential" issues: maybe-RLS-is-missing, possibly-this-key-is-live, perhaps-this-endpoint-is-unauthenticated. The person who vibe-coded the app cannot triage that. They do not have the security background to separate a theoretical CWE match from an actively exploitable hole, and a wall of unconfirmed alerts produces exactly the false positives that train teams to ignore the dashboard entirely.

A validated finding is different in kind, not degree. Instead of "this table may lack an RLS policy," it demonstrates that an unauthenticated request actually returned rows that should have been protected. Instead of "a key pattern was detected," it confirms the key authenticates against the live service. This is the contrast at the heart of exposure validation: a finding you can act on without a security degree, because the proof is in the response, not in a signature database. We unpack the methodology in validated findings versus scanner noise.

Security performance remained flat regardless of model size or training sophistication. The models got better at writing code that works — not code that is safe.— Veracode 2025 GenAI Code Security Report

How attack surface monitoring catches this pre-breach

The defining property of every exposure above is that it is visible from the outside. You do not need source access to find a leaked key in a bundle, a table that answers an unauthenticated query, or an endpoint with no rate limit. You need to look at the application the way an attacker does — through reconnaissance and asset discovery — and then confirm what you find. That outside-in perspective is precisely what Legba Adversary is built to deliver.

Run against the Lovable failure pattern, an external monitor would have surfaced the problem before any researcher disclosed it. The workflow is mechanical and continuous:

1. Discover the asset and its backend — the public Supabase endpoint and anonymous key are right there in the client bundle.
2. Probe the data layer as an unauthenticated client, the same way an attacker would, to see which tables answer queries they should reject.
3. Validate the response: if rows come back that should be protected, that is a confirmed missing-RLS exposure, not a maybe.
4. Flag exposed secrets in the same pass — any frontend-leaked key is tested for whether it is live.
5. Re-run on every deploy, because the next AI-generated change can re-introduce the same gap, which is the entire point of continuous attack surface monitoring.

The same loop catches the broader exposure family that AI-generated stacks tend to leave open: an exposed admin panel with default credentials, directory listing enabled on a misconfigured static host, or a dangling DNS record pointing at a decommissioned preview deployment ripe for subdomain takeover. The common thread is that none of these require breaking in. They require only looking, which means the defender and the attacker are running the same playbook — and whoever runs it first wins.

A balanced verdict

It would be easy, and wrong, to conclude that AI-assisted development is inherently unsafe. The evidence says something more precise. AI generates functional code reliably and insecure code frequently, and it does so without flagging the difference. Veracode found the secure-versus-insecure choice came down on the wrong side 45% of the time, and Carnegie Mellon researchers found that while a strong majority of generated code functions correctly, only a small fraction passes security review. The gap between "it works" and "it is safe" is real, wide, and not closing on its own as models improve.

The responsible path is not to abandon these tools. It is to pair their speed with a verification step that operates at the same speed — automated, continuous, external, and validated. For a security team or MSSP, the job to be done is simple to state: know what is exposed before someone else does, and prove it well enough to fix it. For the broader picture of how this fits into a modern program, see our external attack surface management guide for 2026.

Vibe coding shifted the bottleneck from writing software to securing it. The teams that thrive in this era will be the ones who treat every shipped app — human-written or AI-generated — as an asset on an attack surface that must be watched. The vulnerabilities are not exotic. They are old failures arriving faster than ever. The defense is to look first.