Notifications
Clear all
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.
NHIMG editorial — based on content published by Escape: methodology for analysing vibe-coded application security at scale
By the numbers:
- Escape analyzed over 5,600 publicly available applications and identified more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of PII.
- Lovable deployments accounted for about 4,000 applications in the dataset, far more than the smaller Base44 and Create.xyz samples.
Questions worth separating out
Q: What breaks when low-code apps expose secrets in the browser?
A: Once secrets or privileged tokens appear in browser-delivered code, attackers can inspect bundles, replay requests and probe backend APIs without defeating the login flow.
Q: Why do permissive backend rules create risk in vibe-coded applications?
A: Permissive backend rules let a reachable token or public endpoint access more data than the application intended.
Q: How can security teams know whether row-level security is actually working?
A: They should test it with real unauthorised requests, different roles and altered tokens, then confirm that the database rejects access at the record level.
Practitioner guidance
- Map exposed tokens to application trust boundaries Inventory any JWTs, service keys or API credentials that appear in frontend bundles, build outputs or client-side configuration, then classify whether they grant read, write or administrative access.
- Test row-level security with real requests Replay unauthorised requests against generated APIs and verify that row-level security blocks access at the database boundary, not just in the UI or API gateway.
- Expand asset inventory beyond domains Include routes, schemas, embedded endpoints and third-party integrations in your attack surface model so discovered assets can be tested for privilege and data exposure.
What's in the full report
Escape's full report covers the operational detail this post intentionally leaves for the source:
- Platform-by-platform breakdown of where the most frequent secrets, vulnerabilities and PII exposures were found
- Methodology details for the fingerprinting, crawling and passive testing pipeline used against public apps
- Examples of how exposed JWTs, Supabase routes and RLS misconfigurations were validated in practice
- The full scope of the conservative cleanup process and why the published results are a lower-bound estimate
👉 Read Escape's full report on vibe-coded application security findings →
Vibe-coded apps and exposed secrets: what IAM teams should watch?
Explore further
19/08/2026 4:36 pm
Public app creation now creates governance debt faster than review processes can absorb it. The article shows that low-code and vibe-coded workflows can produce working applications before security review has even started. That shifts the control problem from build speed to boundary enforcement, because the first weak policy or exposed token can become the default access model. IAM and application security teams should treat this as a lifecycle governance issue, not a one-time scan result.
A question worth separating out:
Q: Should organisations treat low-code app builders as an IAM issue?
A: Yes, when those builders produce public applications that rely on tokens, API keys or delegated access. The IAM concern is not the builder itself but the identities and privileges it creates, stores or exposes. If the resulting access cannot be reviewed, rotated or constrained, the development model has become an identity risk.
👉 Read our full editorial: Vibe-coded apps expose secrets and RLS gaps at scale
