We Audited 35 Vibe-Coded Apps. 100% Had No Rate Limiting. 95% Had SQL Injection. But That's Not Even the Worst Part.

**TL;DR:** Teyrex audited 35 production vibe-coded apps in early 2025 through mid-2026. 100% had no rate limiting. 95% had SQL injection vulnerabilities. 85% had unprotected API routes. 80% had hardcoded secrets in the codebase. But the worst finding isn't on that list: none of the builders knew these were problems, because the AI tools never told them.

---

The numbers from Teyrex's audit landed like a brick through a window. Thirty-five apps, all built with AI coding tools (Cursor, Lovable, Bolt, Claude, and various combinations), all reviewed because the owners suspected something was off. Every single one had exploitable security failures. Not edge cases. Not theoretical attack chains. Just the classics: SQL injection, missing auth, keys in the browser bundle, rate limits that did not exist.

I keep coming back to one detail from the report. On one project, the first thing the auditors did was enable the linter. It reported over a thousand errors. A thousand. These were failures that had been silently swallowed throughout the entire application. Features looked like they worked because the errors never surfaced anywhere a human would see them.

A thousand errors, silently swallowed, while the demo looks flawless. That's the whole problem in one sentence.

## How bad were the actual findings?

Let me be specific, because the percentages deserve more than a bullet list.

**Rate limiting:** zero apps out of 35 had any. Not one endpoint protected against abuse, scraping, or runaway API bills. Someone could hammer your auth endpoint at 10,000 requests a minute and the app would just keep serving responses until something caught fire.

**SQL injection:** 95%. User input reaching database queries without sanitisation. This is the oldest vulnerability class on the web. It was solved in the 2000s. AI coding tools reintroduced it at industrial scale.

**Unprotected API routes:** 85%. Endpoints with no authentication or authorisation checks. Anyone who found the URL could call it. The UI hid the button. The server did not care.

**Hardcoded secrets:** 80%. Credentials, connection strings, and configuration committed directly into the codebase. In 25% of cases, API keys were actually visible in the client-side JavaScript bundle. Just sitting there in the browser dev tools, waiting to be lifted.

**No tests:** 100%. Zero apps shipped with a meaningful test suite. Every change was a coin flip against silent regressions.

A typical app in the sample carried between 15 and 30 distinct issues. The auditors weren't hunting for exotic zero-days. They were finding things a competent junior developer would catch in code review.

## But the tools are getting better at security, right?

Sort of. Invicti generated 20,000 vibe-coded apps using different LLMs and found that the bigger models (gpt-5, Claude Sonnet 4.5) do produce fewer SQL injection and XSS vulnerabilities than earlier generations. On the happy path, when the AI writes a standard CRUD handler, it often parameterises queries correctly. That's real progress.

Here's the catch: the Teyrex sample wasn't lab-generated code. These were real production apps built by real people shipping real products. And the gap between "the model can write secure code when tested in isolation" and "the shipped app is secure" turned out to be a canyon.

The difference is review. Invicti's generated apps were unreviewed by design. Teyrex's audited apps were unreviewed by accident. The builders assumed the AI had handled it. Nobody sat down and said "let me check every API route has auth" or "let me verify the RLS policies aren't set to USING (true)." Because nobody knew they needed to.

## What's actually the worst part?

I said it up top, but it's worth sitting with.

None of the 35 builders knew these problems existed. The AI tools never surfaced them. No warning. No lint. No "by the way, your database is readable by anyone with a browser." The demo worked, so they shipped.

A second example from Teyrex brings this into focus. Another client was drowning in spam. Their forms had client-side-only protection. Bots bypassed the captcha entirely and pushed spam and injection attempts straight through the front door. The forms worked flawlessly in every demo. Demos do not include attackers.

The structural problem is this: AI code generation optimises for "does the feature work when a well-intentioned user interacts with the UI." It does not optimise for "what happens when a malicious actor sends a request the UI would never send." And it has no runtime feedback loop. The generated code runs, so it must be fine. The thousand swallowed linter errors never interrupt the demo.

Teyrex put it well: AI is a compiler, not a runtime. A compiler needs a goal to evaluate against. Vibe coding skips that step. Nobody writes down what "good" looks like, so generated code gets judged by "does the demo work" and drifts into slop.

## Why do governed platforms not have this problem?

This is where the architectural argument gets concrete.

SecurityScanner.dev scanned 23,711 apps in Q2 2026. On Lovable and Bolt, 7% had databases anyone could read. The public anon key plus no RLS policies meant every table was effectively public. YC-backed companies, scanned as a control group: 0%.

Same backend (Supabase). Same framework (React). Same deployment pipeline. The difference was not the technology. It was what the builder knew, and what they didn't know they didn't know.

Governed platforms eliminate entire classes of these failures by architecture. On **Stacker**, you cannot accidentally expose your database to the public internet because the permission model is baked into every data request, not bolted on afterwards. There is no "oops, I forgot to add auth to this endpoint" because there are no raw endpoints. Every interaction goes through a permissions layer that defaults to closed. On **Bubble**, you cannot inadvertently skip an authentication check on a workflow because the workflow runtime requires you to declare who can trigger it.

This isn't "governed platforms have better security features." It's a different category of thing. One gives you code and wishes you luck. The other gives you a runtime where the dangerous defaults are architecturally impossible. You can still build bad logic on a governed platform, sure. But you cannot accidentally ship a database with no access controls. The platform won't let you.

## What should builders actually do?

If you're building on AI code tools and shipping to production, here's the minimum viable audit, based on what kept coming up across the Teyrex, VibeScan, and Bacancy reviews:

1. **Run a secrets scanner.** `vibe-audit` exists for exactly this. It checks for hardcoded keys, `.env` files in git, and API keys in frontend bundles. Thirty seconds, free.
2. **Check every API route has server-side auth.** Not just a UI wrapper that hides the admin button. Hit the endpoint with curl. If it returns data without a token, you have a problem.
3. **Enable rate limiting on auth endpoints.** 5 requests per minute per IP is a reasonable starting point. Unprotected login and password-reset endpoints are credential-stuffing magnets.
4. **Audit your database access policies.** If you're on Supabase, `USING (true)` is not a policy. It's an open door. Every table needs row-level security that matches your actual authorisation model.
5. **Run the linter.** I cannot believe this needs to be said, but the Teyrex project with a thousand swallowed errors proves it does. If your linter reports errors you didn't know about, those are bugs you didn't know about.

If you're building something that handles real user data and you don't have the budget or expertise for a security review: consider a governed platform. The architecture prevents the most common failures by design. It is not magic. It will not save you from bad product decisions or poorly designed permissions. But it will save you from waking up to discover your database has been publicly readable for three months because you didn't know RLS was a thing.

The vulnerability data from mid-2026 tells a clear story. AI coding tools produce working features at incredible speed. They do not produce secure defaults. They do not warn you about what they skipped. And they will not be the ones explaining to your users why their data leaked. That part is still your job. Or your platform's job to make irrelevant.