Topic starter
19/08/2026 4:00 pm
TL;DR: Publicly available vibe-coded applications are scaling insecure patterns faster than teams can review them, with analysis of more than 5,600 apps finding over 2,000 vulnerabilities, 400+ exposed secrets and 175 PII exposures, according to Escape. The operational lesson is that public-by-default development workflows need identity-aware guardrails, not just faster scanning.
Editorial analysis by NHI Mgmt Group, based on content published by Escape: “Methodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms”.
By the numbers:
- Escape analyzed over 5,600 publicly available applications.
- The research identified more than 2,000 vulnerabilities in those applications.
- The same sample contained 400+ exposed secrets.
Key questions
Q: What breaks when vibe-coded apps expose frontend tokens and secrets?
A: Authentication stops being a meaningful trust boundary when credentials are visible in browser-delivered code.
Q: Why do exposed secrets and weak row-level security create so much risk?
A: Because the first issue hands out a reusable credential and the second fails to constrain what that credential can read or change.
Q: How can security teams find access-control gaps in low-code or vibe-coded apps?
A: Look for three things: frontend-recoverable secrets, public routes that reveal backend structure, and database policies that do not enforce per-user row boundaries.
Practitioner guidance
- Review frontend-visible credentials Search generated bundles, routes and public assets for anonymous JWTs, service keys and embedded API endpoints before release.
- Validate row-level security separately from login Test whether authenticated users can only read their own rows, and verify that database policies still hold when API requests are replayed or modified.
- Establish ownership for machine credentials Assign a named owner for every exposed or generated token so revocation, rotation and incident response do not depend on the original builder.
Bottom line: Vibe-coded apps can expose machine credentials, backend routes and data policies at the same time, which turns convenience into a governance problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:36 pm
Vibe-coded development is creating an access-control debt problem, not just a code-quality problem. The article shows that speed of application creation now outpaces the review of tokens, APIs and row-level policies. Once those controls are left to default settings or post-launch cleanup, the governance model is already behind. Practitioners should treat app generation speed as an access governance risk, not a productivity metric.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: When should teams treat generated apps as a governance issue rather than a development issue?
A: When non-specialists can publish working apps with real data access, governance has to start at creation time. That is the point at which templates, secret handling, policy defaults and review gates can still prevent exposure. If the first security review happens after launch, the organisation is already managing cleanup instead of control.
👉 Read our full editorial: Vibe-coded apps expose secrets and RLS gaps at scale