Vibe-coded apps expose secrets and RLS gaps at scale

At a glance

What this is: This is a methodology-led analysis of vibe-coded application security that found large-scale exposure across public apps, including vulnerabilities, secrets and PII.

Why it matters: It matters because low-code and AI-assisted app creation can bypass normal review and identity controls, creating access, data and secret-management risks that IAM, PAM and security teams still have to govern.

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.

👉 Read Escape's full report on vibe-coded application security findings

Context

Vibe coding lowers the barrier to building and publishing applications, but it also lowers the barrier to shipping insecure defaults, exposed credentials and weak access control. In this article, the primary security problem is not the tooling itself but the way public app creation can outpace normal review, testing and governance, especially when non-specialists deploy full-stack systems.

That creates an identity and access problem as much as an application security problem. Exposed JWTs, permissive backend rules and misconfigured row-level security turn browser-side code into an access pathway, which means application teams, IAM leads and NHI governance owners all need to think about who can authenticate, what the token can do and how those privileges are constrained.

Key questions

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. The real failure is not only secret leakage. It is the collapse of the trust boundary between the client and the service, which can expose data, permissions and internal routes.

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. In practice, that means authentication may succeed while authorization fails to restrict records, actions or tenants. The risk grows when the app is built quickly and the policies are copied, generated or assumed rather than validated.

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. If users can change headers, replay requests or hit generated endpoints and still see data, the policy is not doing its job, even if the application appears normal.

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.

Technical breakdown

How public frontend bundles expose backend identity and access paths

Modern web apps often embed API routes, configuration objects and tokens in JavaScript bundles so the browser can communicate with backend services. In a vibe-coded workflow, that convenience becomes risky when anonymous JWTs, service keys or other secrets are shipped to the client. Once a token is visible in source output, an attacker does not need to break in through the normal login path. They can inspect the code, replay requests and test whether backend authorization actually holds. This is especially dangerous when the application treats the frontend as trusted or assumes obscurity will protect the backend.

Practical implication: treat client-side code as an exposed control surface and remove any secrets or privileged tokens from it.

Why row-level security fails when the API and database are loosely governed

Row-level security, or RLS, is meant to limit which records a requester can read or change based on identity and policy. In systems like Supabase, the API layer can be generated automatically from the database schema, which is useful for speed but dangerous if the policies are not explicitly designed and validated. If a public token can reach an endpoint and the RLS policy is permissive, stale, incomplete or misaligned with the application logic, the database becomes overexposed. The issue is not just authentication. It is the gap between authentication, authorization and data boundary enforcement.

Practical implication: validate RLS policies against real requests, not just schema assumptions, before any internet-facing deployment.

How scan-driven attack surface management finds hidden routes and exposed secrets

The methodology described here combines asset discovery, browser crawling, static analysis and passive testing to build a live map of externally visible services. That matters because vibe-coded apps often hide useful attack paths in JS bundles, embedded endpoints and auto-generated schemas rather than in obvious menus or documentation. A lightweight read-only scanner can surface those paths without triggering destructive behaviour, then feed them back into dynamic testing. For defenders, that means the real exposure is often broader than the published application surface. The challenge is discovering which assets are actually controllable and which are merely visible.

Practical implication: extend asset inventory beyond domains to include routes, schemas and embedded endpoints before testing authorization.

Threat narrative

Attacker objective: The attacker objective is to turn publicly exposed app code and permissive backend rules into unauthorised data access and secret harvesting at scale.

1. Entry occurs through publicly reachable vibe-coded applications whose frontend bundles expose anonymous JWTs, API routes and backend schema hints.
2. Credential access follows when exposed tokens or permissive endpoints allow unauthorised requests against generated APIs and underlying data services.
3. Impact appears as secret exposure, weak authorization and PII leakage across public applications that were assumed to be low risk.

NHI Mgmt Group analysis

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.

Anonymous tokens in browser-delivered apps are a trust boundary problem, not a tooling convenience. When JWTs or service keys sit in the frontend, the application is effectively delegating trust to anyone who can inspect the bundle. That is especially relevant to NHI governance because machine-readable credentials are being used as ambient access mechanisms rather than constrained identities. The distinction between authentication and authorization becomes critical, and the practitioner conclusion is clear: secrets belong server-side unless the access model is explicitly designed for client exposure.

Row-level security is only effective when it is tested against the actual request path, not the intended design. The article’s Supabase discussion shows how database policy and application logic can drift apart, leaving data exposed even when authentication exists. This is a classic control-assurance failure: the access layer looks present, but the effective guardrail is absent. Security teams should validate policy enforcement with real requests and treat policy drift as a production risk.

Attack-surface management for modern app builders needs an identity-aware lens. The most useful finding here is not just that vulnerable apps exist, but that their exposure often starts with tokens, routes and schemas that govern who can do what. That makes NHI-style credential discipline relevant even in application development contexts, because leaked tokens operate like unmanaged identities. Practitioners should conclude that app inventory, secret discovery and authorization testing now need to move together.

What this signals

Shadow identity risk is expanding beyond traditional NHI estates into application builders and generated backends. The practical signal for security teams is that secret scanning, policy validation and asset inventory now need to cover no-code and low-code publishing paths as well as conventional CI/CD. Where browser-exposed credentials exist, the question is no longer whether a token is sensitive but whether it can be governed like any other production identity.

The next control gap is likely to be a gap in ownership, not just in tooling. When non-specialists can create deployable systems, security teams need clear accountability for secret exposure, backend policy design and publish-time review, or public applications will continue to outpace governance.

For practitioners

• 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.
• Review no-code and low-code deployment guardrails Require pre-publish security review for non-specialist builders, including secret scanning, authentication checks and policy validation before any application is made public.

Key takeaways

• Vibe-coded applications can expose secrets, APIs and PII at scale before teams notice the control gap.
• The underlying failure is boundary drift between client code, authentication and database authorization.
• Governance must extend into low-code publishing workflows, exposed tokens and record-level access enforcement.

Key terms

• Vibe-coded Application: An application built through low-code or AI-assisted tools by a non-specialist or semi-technical user. The security risk comes from speed and accessibility outpacing review, so secret handling, authorization and deployment guardrails can be weak or missing.
• Row-Level Security: Row-level security is a database control that restricts which rows a session can read or modify based on policy. For multi-tenant apps, it is valuable because it pushes tenant enforcement below application code, reducing the chance that a forgotten filter exposes another organisation's data.
• Browser-exposed secret: A credential, token, or other sensitive value that can be accessed through client-delivered code or related front-end workflows. These exposures are especially risky because they can be copied at scale, reused outside intended context, and remain valid until explicitly revoked.
• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.

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

👉 Escape's full article includes the dataset methodology, detection flow and validation approach behind the findings

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management and workload identity. It helps practitioners connect identity controls to the broader security programmes they already run.