Vibe coded apps expose a broad identity and data access gap

At a glance

What this is: This research shows that vibe coded apps built on Supabase frequently ship with public data access paths, missing row-level controls, and exposed sensitive records.

Why it matters: It matters because IAM and application teams need to treat generated code as an access-control risk, not just a software delivery shortcut, especially where human and non-human identities share backend permissions.

By the numbers:

• 98% of vibe coded applications have at least one security flaw.
• 172 sites allow anyone to delete records from the database without any authentication.
• 39 sites have tables fully readable by anyone who holds the public Supabase key.

Context

Vibe coding changes how applications are built, but it does not change the security obligations that sit behind them. When a generated app connects to a database backend through a public key and no row-level policy, the result is not just a coding defect, but an access control failure that can expose production data immediately. That makes authorization design a first-order governance issue, not a later-stage hardening task.

This article is really about the gap between application creation and security configuration. The identity problem is not limited to human users: public keys, service access patterns, and backend tokens are effectively non-human identities that need ownership, scope, and lifecycle control. Where those controls are absent, generated apps inherit trust they never verified.

The pattern is typical of fast-generated, database-backed apps that prioritise working functionality over control-plane discipline. The same weakness will keep recurring until teams treat backend access policy as part of the build, not as a post-deploy audit.

Key questions

Q: What fails first when a vibe coded app is deployed with public database access?

A: The first failure is not the UI, but the authorization layer behind it. If row-level security is missing or incomplete, public keys and direct API endpoints can reach data that should have been restricted, including reads, writes, updates, and deletes. That makes access control the first thing to validate before users ever see the app.

Q: Why do generated apps expose data even when the backend key is public by design?

A: Because the key is only one part of the trust model. In systems like Supabase, the public key is expected, but security depends on authorization policies that limit what that key can do. If those policies are missing, the application behaves as though every request is trusted, which turns public access into data exposure.

Q: What are the signs that vibe coded applications are failing security controls?

A: Common warning signs include authentication that is missing or easily bypassed, public databases, hardcoded secrets in prompts or configuration files, and apps that were never registered or reviewed. In builder platforms, public default settings and exposed registration endpoints are especially risky. In agent-driven workflows, excessive permissions and long unmonitored sessions usually signal that controls are not keeping pace with usage.

Q: How should teams secure AI-generated applications before they reach production?

A: Treat security as a precondition of generation, not a review step at the end. Start with approved templates, shared authentication libraries, runtime secret retrieval, CI gates, and default-deny network policy. The goal is to make the safe path the easiest path, so generated code inherits controls instead of inventing them under pressure.

Technical breakdown

Why public Supabase keys become an authorization problem

Supabase uses a public anon key by design, so the key itself is not the trust boundary. The real control is row level security, which decides whether unauthenticated or minimally authenticated requests can read, write, update, or delete data. In vibe coded apps, that control often never gets configured, so the public key becomes a convenient path into tables, RPC functions, and exposed APIs. The issue is architectural, not cosmetic: if authorization is missing at the data layer, the application behaves as if every visitor is trusted.

Practical implication: enforce database-side authorization as a release gate, not as a follow-up fix.

How unauthenticated CRUD access turns into data exposure

When a backend allows DELETE, PATCH, or GET without identity verification, the blast radius depends on the table, not the front-end. The article shows examples ranging from record deletion to full-table read access, plus exposure of sensitive columns such as emails, password hashes, tokens, and phone numbers. That means the risk is not limited to nuisance edits. It becomes integrity loss, privacy loss, and in some cases credential compromise, all from the same misconfigured access path.

Practical implication: test every exposed table and API verb, not just login and signup endpoints.

Why AI-generated code misses control-plane governance

Generated code can assemble pages, forms, and database calls quickly, but it usually does not reason about access lifecycle, scope reduction, or policy completeness. That leaves a gap between what the app does and what the backend permits. In NHI terms, the public key, API token, and service integration behave like machine identities without ownership or offboarding discipline. Without lifecycle controls, security depends on manual review that rarely happens before launch.

Practical implication: add identity and secret review to the same pipeline that approves generated code.

Threat narrative

Attacker objective: The attacker objective is to manipulate or exfiltrate application data by abusing public backend access paths that were never constrained by identity-aware authorization.

1. Entry occurs through publicly exposed application code that reveals a Supabase key or direct API path, giving an attacker a usable request surface without needing credentials.
2. Credential access is unnecessary in many cases because the public anon key and missing row-level controls already permit unauthenticated reads, writes, updates, or deletion.
3. Impact follows as data loss, integrity corruption, or exposure of sensitive records such as payments, messages, administrator data, and authentication material.

Breaches seen in the wild

• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

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

Generated code creates governance debt when identity controls are not part of the build. The core issue here is not that low-code or vibe coding is insecure by default, but that the operational model assumes security can be bolted on later. In practice, public keys, backend APIs, and database policies need ownership and lifecycle treatment from the moment an app is created. Security teams should treat generated applications as governed systems, not prototypes that magically become safe in production.

Identity-aware authorization is the control plane that decides whether a vibe coded app is usable or exposed. A public key does not protect data, and authentication alone does not prevent broad table access if row-level controls are absent. That makes authorization design, not secret secrecy, the decisive control in Supabase-backed apps. Practitioners should read this as evidence that backend access policy is now a first-class application governance requirement.

Non-human identity governance is the missing discipline in generated app stacks. The Supabase key, API tokens, and related service connections behave like machine identities, yet they are often deployed without inventory, ownership, or revocation planning. This is where IAM and NHI practice meets application security: if backend identities are not governed, generated apps can expose business data at scale. Teams should align generated-app review with NHI lifecycle controls, not just code scanning.

Broad exposure at scale signals a market shift from app generation to access governance. Once tools can create functional applications in minutes, the differentiator becomes not output speed but whether the surrounding control framework can keep pace. That will push buyers to re-evaluate how they approve generated apps, which teams own backend authorization, and where security checks sit in the delivery chain. The practical conclusion is that speed without governance is now a predictable exposure pattern.

Broad access-control failure: public backend trust assumptions are the real vulnerability. This article shows that the weak point is not the generated interface, but the assumption that a public key and default API surface are acceptable until someone audits them later. That assumption fails because the app can already be live, indexed, and handling real data. Security teams should prioritise control-plane review for every generated app before exposure becomes user impact.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Authorization debt is the defining risk in vibe coded applications. The build can be fast, but the trust model is still slow to catch up. Once a generated app is live, missing row-level security turns a public key into an open data path, so teams need release controls that treat access policy as part of the product definition.

Only 5.7% of organisations have full visibility into their service accounts. That gap matters here because generated apps often depend on backend identities, API keys, and service integrations that nobody owns clearly enough to review. If the identity layer is invisible, the application layer will almost always ship with exposure.

Vibe coded apps are creating an identity governance blind spot, not just a code quality problem. The control question is who owns the non-human identities behind the app, how their permissions are scoped, and when they are revoked. If that answer is missing, security teams should expect the same failure pattern to repeat across every generated application.

For practitioners

• Make row-level security a release requirement Block deployment of any Supabase-backed app until read, write, update, and delete paths are covered by explicit row-level policies. Treat missing policies as a launch-stopping defect, not a post-launch hardening task.
• Inventory exposed backend identities and keys Catalogue public anon keys, service keys, API tokens, and related backend credentials in generated apps, then assign ownership and rotation responsibility before the app is allowed to process real data.
• Test every exposed table and verb Validate whether anonymous users can query, insert, update, upsert, or delete against each table and RPC endpoint, with special attention to payments, admin records, messages, and user-role tables.
• Gate generated apps on data-classification review Require a quick classification step for tables and columns before go-live so that sensitive fields such as emails, phone numbers, tokens, and password hashes cannot be left reachable through default APIs.
• Align AI code generation with IAM oversight Add identity and authorization reviewers to the same workflow that approves generated code, so that backend trust decisions are checked before the app reaches production users.

Key takeaways

• The article shows that generated applications can reach production with public data paths because authorization was never established as a build requirement.
• The scale is broad: 98% of scanned apps had at least one flaw, and the most serious failures included unauthenticated deletion and full database exposure.
• The control that changes the outcome is identity-aware database authorization, backed by policy review, secret inventory, and release gating.

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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Public Anon Key: A public anon key is a client-facing credential that allows limited access to a backend by design. It is not meant to protect data by itself, so its security value depends on the authorization policies enforced behind it.
• Authorization layer: The authorization layer is the control point that decides whether a subject can perform a specific action on a resource. It separates access decisions from application features, which makes enforcement more consistent, easier to change, and easier to evidence during reviews.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the governance discipline needed to control backend identities and access paths in modern delivery pipelines.