Vibe coding security: how to keep AI-built apps safe to ship

AI-built apps fail along four repeating lines: injection flaws, exposed secrets, missing authorization checks, and outdated or fabricated dependencies. The pattern holds across scans of thousands of apps, so the risk is a property of how the code gets written, not bad luck on any single project.

Injection and other common web flaws show up because generation models produce them at high rates. Veracode's 2025 GenAI Code Security Report tested more than 100 models across 80 coding tasks and found 45% of AI-generated samples failed OWASP Top 10 security tests, with Java at 72% and cross-site-scripting tasks secure only 12 to 13% of the time. Checkmarx found up to 70% of AI-generated code insecure, and CSA's own July 2025 research put 62% of solutions carrying design flaws or known vulnerabilities even with recent models.

Exposed secrets are the second signature, and they reach production because generators embed credentials where clients can read them. Escape.tech scanned 5,600 vibe-coded apps and found more than 2,000 vulnerabilities, 400-plus exposed secrets, and 175 instances of exposed PII. Independent review found Supabase credentials sitting in client-side bundles in 10 of 38 Lovable-built apps.

Missing authorization is the third, and it produces the largest breaches. CVE-2025-48757 documents Lovable apps missing Supabase Row Level Security, with a scan of 1,645 apps finding 303 vulnerable endpoints across 170 apps that exposed PII, financial records, and admin credentials. Agentic tools shift the mix rather than remove it. CSO Online tested five platforms building identical apps and found 69 vulnerabilities across 15 apps, mostly API authorization and business-logic failures, with zero exploitable SQL injection.

Dependency risk rounds out the four, driven by models suggesting packages that do not exist. A study of 576,000 generated Python and JavaScript samples found 19.7% of suggested dependencies were hallucinated, and 43% of those fake names recurred across repeated queries, which is the basis for slopsquatting attacks.

The named breaches confirm these classes cause real damage. Moltbook exposed 1.5 million API tokens and 35,000-plus email addresses after RLS was disabled on the database. The Tea App suffered two breaches within three days, one exposing government-issued IDs and a second exposing more than a million private messages. Chat & Ask AI ran a Firebase instance with a default allow read: if true rule and exposed 406 million records for roughly 25 million users. The failures trace back to how AI-written code moves from prompt to production, which the next section explains.

Why these bugs ship: speed outpaces review#

These vulnerabilities ship because review capacity has not grown to match how fast AI coding tools generate code. A single prompt can produce hundreds of lines in seconds. The review process that catches injection flaws, exposed secrets, and missing auth checks still runs at human speed, and the volume outpaces it.

Developer confidence widens the gap. Over 75% of surveyed developers believed AI-generated code is more secure than human-written code, while 56% of the same respondents admitted it sometimes or frequently introduces security issues (CSA). That contradiction predicts the behavior that follows. Fewer than 25% ran software composition analysis on AI suggestions, and roughly 80% admitted bypassing security policies in AI-assisted workflows. Code that feels trustworthy gets waved through the checks that would have caught the flaw.

Fixing by prompting compounds the problem instead of resolving it. After GPT-4o revised code up to 40 times, the codebase held 37% more critical vulnerabilities after just five iterations (CSA). Asking the model to patch its own output can add defects faster than it removes them, so the developer who trusts the tool and skips review inherits a growing pile of issues.

None of this points to a model quality problem that a better model will solve. Security performance stayed flat across model generations in Veracode's testing, so waiting for the next release does not close the gap. The failure sits in the process. Generation scaled and review did not, and the confidence gap removed the manual check that used to compensate. A remediation workflow that runs at generation speed is what restores the balance.

A remediation workflow that catches what review misses#

The gap the Cloud Security Alliance guide leaves is a repeatable process for a lead managing team output at scale. The CSA guide stops at prompting advice and "review your code." A lead needs an ordered sequence that runs the same way on every diff, whoever or whatever wrote it. The five steps below cover detection through re-scan and treat AI-written and human-written code under one standard.

1. Scan every change on commit#

Run static analysis and secret detection on each pull request before a human reads it. The scan should cover the four classes that show up most in AI-built apps: injection points, exposed secrets, missing authorization checks, and outdated or unknown dependencies. Wire the scan into CI so no change reaches review without it. The same rule applies to a senior engineer's commit and a diff generated from a chat prompt.

2. Classify by domain and severity#

Sort each finding into a domain and a severity before anyone triages it. A hardcoded database password and a missing rate limit are both security issues, but one blocks the merge and one becomes a follow-up task. Grouping findings by domain also shows patterns. Repeated missing auth checks across endpoints point to a habit worth fixing at the source, not case by case.

3. Verify the fix before it moves#

Confirm each proposed fix actually closes the issue and does not break the tested behavior. This step matters most for AI-assisted remediation. Asking a model to fix its own output can introduce a new fault while resolving the first, so a fix that passes only a prompt-based check has not been verified. Run the test suite against the change and re-run the same scanner that flagged the finding. A fix that clears both is verified. A fix that clears neither goes back.

4. Deliver the fix as a pull request behind a review gate#

Submit every verified fix as a pull request that a person approves before merge. No fix reaches the main branch automatically, regardless of how confident the tooling is. The review gate gives the lead a record of what changed and why, and it keeps a human accountable for the code that ships. A short description of the vulnerability class and the fix lets the reviewer approve in seconds rather than reconstruct the problem.

5. Re-scan the merged branch#

Run the full scan again after merge to catch issues that only appear once changes combine. A fix verified in isolation can interact with other recent commits, and a dependency update can pull in a new transitive vulnerability. The re-scan closes that window and feeds anything new back to step two.

Apply these steps to the whole repository, not a separate lane for vibe-coded output. Junior developers pasting AI-generated code and senior engineers writing by hand produce the same vulnerability classes. A single standard finds and fixes them consistently and keeps the review load predictable as generation speed climbs.

Where Hyrax fits in this workflow#

Hyrax runs the detect-classify-verify-review-rescan loop continuously, so the workflow does not depend on an engineer remembering to trigger it. It reviews the repository, finds issues, and submits fixes across six domains: security, correctness, maintainability, performance, architecture, and operations. A missing Row Level Security policy and a hardcoded credential both fall inside the security domain, but the same pass also catches the business-logic and authorization failures that agentic tools produce most often, the class CSO Online found accounted for most of the 69 vulnerabilities across 15 test apps.

Each fix ships as a pull request that a human reviews before merge. Hyrax pre-verifies the fix so the diff arrives already checked against the original issue, but it never auto-merges. The review gate stays where an engineering lead controls it. That design answers the iterative-degradation problem directly, since a verified, human-approved change replaces the loop of re-prompting a model that adds critical vulnerabilities with each pass.

Hyrax reviews all code in the repository, not the AI-written diffs alone. The Moltbook and Tea App breaches came from configuration and access-control gaps that no "vibe-coded output" filter would isolate, because the vulnerable code sat next to hand-written code and depended on it. Applying one standard across the whole codebase catches the injection-prone samples Veracode measured and the credential exposure Escape.tech found, without asking anyone to sort commits by author first.

Access runs on a credit-based model with a Free plan and a Paid plan. Credits meter the review and fixing work rather than charging by seat alone, so a small repository can run the full loop at no cost and a larger one scales spend to the volume of code under review.

Hyrax complements the scanners already in the pipeline. Snyk, Sonar, and CodeRabbit each cover a slice of the review surface, and Hyrax adds the fixing layer that turns a flagged finding into a verified pull request. Running it alongside existing tools closes the gap between detection and remediation, which is where most of the documented AI-app breaches lived. The scanners find; Hyrax finds and fixes.

Building review into the vibe coding habit#

AI coding tools let a small team ship features in hours that used to take weeks. That speed holds only when review scales with it. The teams that keep moving fast treat continuous code review and fixing as a standing part of the pipeline, not a gate they add after an incident.

Make the review habit apply to every commit, human-written and AI-written alike. A scan runs on each change, findings get classified by domain and severity, and verified fixes arrive as pull requests an engineer approves. Hyrax runs that loop across security, correctness, maintainability, performance, architecture, and operations, so the backlog of small flaws never grows into the next Moltbook or Tea App breach.

Speed and safety stop competing once the workflow does the finding and fixing in the background. The engineer keeps the merge decision. The codebase stays clean while the team keeps shipping. Build the habit early, apply it to all code, and the fast path becomes the safe path.

Hyrax makes your code better. Ship clean code.

FAQs#

Does AI-generated code need different review than human code? No. AI-written code fails the same way human code fails, with injection flaws, exposed secrets, and missing authorization checks. Hyrax reviews all code in the repository under one standard rather than treating AI-written diffs as a separate lane. Applying the same gate to every commit closes the gap where 53% of developers found issues that passed initial review (Autonoma).

What's the fastest way to catch exposed secrets before deploy? Scan every commit for hardcoded credentials before it reaches the branch, since API keys and tokens embedded in client bundles are the most common finding in AI-built apps. Hyrax finds exposed secrets and submits a pre-verified fix as a pull request. A pre-deploy scan gate stops the credential from reaching production, which is where breaches like Moltbook exposed 1.5 million tokens.

Do hallucinated package risks need separate tooling? A study of 576,000 generated samples found 19.7% of suggested dependencies did not exist, the basis for slopsquatting attacks (CSA). Hyrax reviews dependency usage as part of code review across all six domains, so hallucinated or outdated packages surface alongside other findings. Dependency scanners like Snyk complement this by tracking known vulnerabilities in real packages.

How do teams keep review from slowing shipping velocity? Automate detection and fixing so the review step becomes a check on a proposed fix rather than manual triage. Hyrax delivers pre-verified fixes as pull requests that are never auto-merged, so a person approves the change without writing it. That keeps velocity while a human retains the merge decision.