Vibe-coded apps expose secrets and RLS gaps at scale

At a glance

What this is: Escape’s analysis shows that vibe-coded applications can expose secrets, PII and row-level security gaps at scale before security teams have any realistic chance to review them.

Why it matters: IAM and application security teams need to treat low-friction app generation as an identity and access problem, because exposed tokens and weak row-level controls can turn rapid deployment into broad unauthorized access.

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.
• Escape found 175 instances of PII in the sampled applications.

Context

Vibe-coded application development lowers the barrier to shipping software, but it also lowers the barrier to shipping insecure access patterns. When non-specialists can publish working apps quickly, identity controls such as token handling, row-level access and backend exposure often become afterthoughts rather than design constraints.

In this article, the core issue is not low-code itself. It is that public deployment workflows and permissive defaults can expose secrets, APIs and personal data before governance catches up, which makes the problem relevant to IAM, NHI governance and application access control alike.

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. Attackers can replay those tokens against APIs or backends, and if database rules are weak, they can reach data the app should have hidden. The failure is structural: the secret is no longer secret, and the authorization layer must carry the full burden.

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. Together, they turn a single public app into a broad data exposure path. The risk is highest when teams assume authentication is enough and never validate database-side authorization independently.

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. Read-only crawling and replay testing are useful because they show what an unauthenticated or low-privilege user can actually reach, not just what the platform claims to protect.

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.

Technical breakdown

Why exposed frontend tokens become an access problem

Anonymous or service tokens embedded in JavaScript bundles are dangerous because frontend code is inherently inspectable. If a token can be recovered from the browser, it no longer behaves like a secret and can be replayed against APIs, databases or backend services. In Supabase-style architectures, the token is not the only control point. Its effective scope depends on database-side authorization, session validation and whether row-level policies actually constrain the data returned to the caller. When permissive development settings move into production, the attack surface becomes public and reusable.

Practical implication: treat any frontend-recoverable token as compromised by default and verify that backend authorization still enforces least privilege.

How row-level security fails when API and database rules diverge

Row-level security works only when the database policy matches the application’s intended authorization model. Misalignment happens when developers rely on a public API layer, assume authenticated requests are enough, or leave default policies unchanged after launch. In that state, users may authenticate correctly but still retrieve rows they should never see. This is an authorization failure, not just a configuration mistake, because the app appears functional while enforcement quietly breaks at the data layer. That is why public app generation without policy review is especially risky.

Practical implication: validate database-side row filtering separately from app-level login and do not assume authentication implies authorization.

Why scale changes the secrets-management problem

At small scale, a leaked key looks like a point issue. At the scale described here, it becomes a governance pattern. Hundreds of exposed secrets across thousands of apps mean the organisation is dealing with repeated lifecycle failure, not isolated developer error. That changes the remediation model from manual cleanup to inventory, detection and revocation discipline. It also creates a distinct non-human identity concern, because secrets and tokens function as machine credentials. Once those credentials are distributed through public code or bundles, they need the same lifecycle controls as any other NHI secret.

Practical implication: inventory exposed machine credentials centrally, rotate them on discovery and assign ownership for revocation workflows.

Threat narrative

Attacker objective: The likely objective is to turn publicly exposed application artefacts into unauthorized data access and reusable backend credentials.

1. Entry occurs through publicly accessible vibe-coded applications whose frontend bundles, routes and exposed tokens are easy to enumerate.
2. Credential access follows when anonymous JWTs or similar secrets are recovered from public code or browser-visible artefacts.
3. Escalation happens when those credentials are used against misconfigured APIs or database layers that lack effective row-level enforcement.
4. Impact is unauthorized access to application data, exposed PII and broader abuse of backend services at scale.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Exposed tokens in frontend code turn non-human identity governance into a browser problem. When anonymous JWTs and service credentials are recoverable from JavaScript bundles, they stop behaving like hidden machine credentials and start behaving like public artefacts. That collapses the trust boundary between the frontend and backend. The practical lesson is that NHI inventory, secret ownership and revocation need to extend to developer-generated apps.

Row-level security is the control that separates authentication from authorization in these architectures. The article’s findings show that login alone does not constrain data exposure when database policies are weak or misaligned. This is where many public app platforms create a verification gap: the app appears authenticated while the data layer remains broadly readable. Security teams should treat policy validation as a release gate, not a post-release fix.

Public-by-default deployment creates a repeatable secret leakage pattern that security tooling will not fix on its own. Scanning can find exposures, but it does not stop inexperienced builders from reintroducing them in the next app. That means governance has to move upstream into templates, policy defaults and access design. Practitioners should focus on removing the conditions that make secret leakage easy to repeat.

Named concept: public-by-default access drift. This is the pattern where fast app generation, permissive defaults and weak policy review combine to widen access faster than governance can narrow it. It matters because the drift is structural, not accidental. Practitioners should measure how often public scaffolding turns into persistent data exposure before the app ever reaches formal review.

From our research library:

• 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.
• Read next: Ultimate Guide to NHIs

What this signals

Public-by-default app creation changes the control point. The main risk is no longer whether a scanner can find a flaw after launch. It is whether the generation workflow itself allows credentials, API routes and data access rules to be created in an unsafe default state. That is why teams need governance at the point of app issuance, not only at the point of review.

Public-by-default access drift: the combination of rapid app generation, permissive defaults and weak policy review that widens access faster than teams can narrow it. In practice, this means platform owners should design for secret detection, policy validation and revocation as standard release conditions, not optional hardening steps.

NHI governance now extends into low-code build pipelines. Exposed service keys and anonymous tokens are machine credentials, even when they are created by non-developers. Teams that already manage NHI lifecycle and secret rotation should apply the same discipline to generated apps, because the credential boundary has moved into the browser and the builder workflow.

For practitioners

• 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.
• Use safe discovery scans as a release gate Add read-only scanning for exposed secrets, routes and schema clues to pre-production checks so public deployments do not ship with obvious access flaws.

Key takeaways

• Vibe-coded apps can expose machine credentials, backend routes and data policies at the same time, which turns convenience into a governance problem.
• The article’s scale matters because thousands of applications produced hundreds of exposed secrets and widespread authorization gaps, not just isolated bugs.
• Security teams should shift controls upstream into generation, policy validation and revocation ownership so public app workflows do not become persistent exposure paths.

Key terms

• 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.
• Scoped JWT: A scoped JWT is a JSON Web Token that carries limited permissions for a specific purpose, resource, or time window. It encodes claims that define what the token holder may access, such as an API, action, audience, or tenant, so systems can enforce least privilege without exposing broader credentials.
• Public-By-Default Deployment: Public-by-default deployment is a release pattern where applications, routes or credentials are made reachable before governance, policy validation or hardening has been completed. It increases the chance that secrets, access paths and data exposure remain visible to anyone on the internet.
• Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security and secrets management for practitioners building control models around fast-moving development workflows. It helps IAM, security and platform teams apply identity discipline where apps, tokens and policy defaults converge.