Vibe coded apps expose a broad identity and data access gap

At a glance

What this is: This research shows that vibe coded applications built on Supabase frequently ship with unauthenticated database access, exposed keys, and missing web security controls.

Why it matters: It matters because IAM, application security, and data security teams must treat public API keys and missing authorization as an identity governance problem, not just a coding defect.

By the numbers:

• 98% of vibe coded applications have at least one security flaw.
• 172 sites allow data deletion without authentication.
• 39 sites expose their entire database for reading to anyone.
• Only 26 out of 1,072 scanned sites had zero issues detected.

👉 Read Symbiotic Security's research on security flaws in vibe coded applications

Context

Vibe coded applications compress design, development, and deployment into a short workflow, but that speed often leaves authorization and data protection unverified. In practice, the risk is not only code quality. It is the absence of identity-aware controls around public APIs, database roles, and row-level security, which turns a functional app into an exposed service.

Supabase-based backends make this especially relevant because the public anon key is intended to exist in client code while security depends on correctly enforced policies. When those policies are missing, the application behaves as if every visitor is trusted. That creates a clear intersection with IAM and NHI governance, since machine-access patterns and service identities are being used without lifecycle oversight or entitlement validation.

Key questions

Q: What breaks when generated apps rely on public backend keys without row-level security?

A: The application’s data plane becomes effectively public. A visible client key is not the issue by itself, but without row-level security and authenticated policy checks, attackers can read, write, update, or delete records through normal API paths. That turns a functional app into an open database with a UI on top.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: How do you know if a vibe-coded app is actually secure enough to deploy?

A: It is only secure enough when security controls are demonstrable, not implied. You should be able to show that inputs are validated, sensitive routes are authorised, cookies are protected, secrets are out of code, dependencies are current, and abuse controls such as rate limiting are active.

Q: Who is accountable when generated applications expose customer data or admin tables?

A: Accountability sits with the application owner, the platform team, and the control owner for the backend service. If policy enforcement was absent, the failure is governance, not just a coding mistake. Teams should map responsibility to release approvals, security testing, and data access review rather than assuming the generator carries that burden.

Technical breakdown

How public Supabase keys become a control problem

Supabase uses a public anonymous key by design, so key secrecy alone is not the security model. The real control boundary is row-level security, authenticated session state, and endpoint policy enforcement. When generated applications expose the anon key in JavaScript and fail to define restrictive policies, the API still functions, but every request is treated as untrusted or, worse, effectively authorised for broad read and write actions. This is a control design failure, not merely a secret leakage issue.

Practical implication: teams must validate policy enforcement on every generated backend before production use.

Why missing row-level security creates unauthenticated read and write paths

Row-level security is the database layer that decides which rows a caller can see or modify. Without it, a public API key can reach tables directly through the REST interface, and endpoints may allow reading, inserting, updating, or deleting data without identity verification. In these environments, table names such as payments, admin_users, or chat_messages are not just data structures. They become exposed assets. The failure mode is especially dangerous because it looks like normal app behaviour until a test request proves otherwise.

Practical implication: require authenticated access tests for every table and deny production release until unauthorised actions fail.

Where AI-generated development hides authorization drift

AI-assisted app builders can generate working code faster than teams can review security assumptions, which creates authorization drift. The app owner may assume the backend is protected because authentication screens exist or the frontend looks polished, but the actual data plane may still accept requests from anyone holding a public key. That gap widens when developers rely on defaults, reuse example schemas, or never inspect exposed tables and endpoint behaviour. The broader issue is governance of machine-generated configuration, not only code correctness.

Practical implication: add policy checks, schema review, and runtime access testing to the release gate for generated applications.

Threat narrative

Attacker objective: The attacker seeks unauthenticated control over application data, including reading sensitive records and altering or deleting production content.

1. Entry occurs through publicly reachable application code that exposes a Supabase anonymous key and backend endpoints to any site visitor.
2. Escalation happens when missing or weak row-level security lets the attacker use that public key to read, modify, insert, or delete database records.
3. Impact follows as sensitive business, user, and administrative data becomes exposed or alterable without authentication.

NHI Mgmt Group analysis

Public keys are not the failure here. Missing authorisation is. The research shows a common misunderstanding in modern app security: a public client key can be acceptable when the backend enforces strict policy. The breach pattern appears when teams treat the presence of a key as the problem and ignore the absence of row-level controls. For identity practitioners, this is the same governance error seen in unmanaged machine access. The practitioner conclusion is to test policy, not just inventory secrets.

Generated applications create a new class of identity governance debt. AI-assisted development can produce complete apps before anyone has defined durable access policy, lifecycle ownership, or release-time verification. That means the entitlement model is often an afterthought rather than a design constraint. In NHI terms, the backend service identity is acting without enforced guardrails. The practitioner conclusion is to treat generated code as an identity-bearing system that needs policy baselines before it reaches production.

Unauthenticated data paths turn application backends into shadow systems of record. When tables like payments, admin_users, or chat_messages are reachable without identity verification, the application no longer has a meaningful boundary between public interaction and protected data. This is where application security intersects with IAM and data governance. The practitioner conclusion is that backend exposure must be assessed as a governance issue, not only as a vulnerability finding.

Continuous scanning of generated apps is now a governance requirement. The scale of the findings shows that one-off review is not enough when teams can create and redeploy apps quickly. A named concept here is authorization drift: the gap that emerges when the deployed access model no longer matches the intended one. The practitioner conclusion is to monitor policy drift continuously across generated applications and their backing data services.

What this signals

Authorization drift: AI-assisted development increases the likelihood that the intended access model and the deployed access model diverge. Security teams should add negative testing, backend policy validation, and schema review to release governance so generated applications cannot quietly expose data services.

Generated apps are likely to become a recurring source of machine-access risk because the backend identity layer is often implicit. That makes runtime verification, entitlement review, and lifecycle ownership essential controls for any programme using code generation at speed.

For practitioners

• Validate row-level security before release Test every generated Supabase-backed app with unauthenticated read, write, update, and delete requests against each exposed table. Block deployment if any operation succeeds without an authenticated, least-privilege identity.
• Inventory exposed database tables and sensitive columns Build a release checklist that flags payments, admin_users, chat_messages, tokens, and personal data fields wherever they appear in generated schemas or REST responses.
• Treat public anon keys as expected, not safe Assume the client-side Supabase anon key is visible and design for policy enforcement at the database and API layers instead of relying on key secrecy.
• Add policy tests to CI and staging Automate negative tests that confirm unauthorised users cannot query protected rows, call RPC functions, or bypass CORS controls before code reaches production.

Key takeaways

• Vibe coded applications fail when public keys are treated as secrets instead of policy inputs.
• The scale of exposure is material, with 98% of scanned sites showing at least one flaw and many allowing unauthenticated database operations.
• Teams should block release until backend policy tests prove that generated apps cannot read, write, or delete protected data without authentication.

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.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.
• Supabase Anonymous Key: A Supabase anonymous key is a public client-side credential used to reach Supabase services under controlled conditions. It is not meant to be secret, so security depends on strong database policies, endpoint restrictions, and careful separation of public and protected operations.
• Generated Application: A generated application is software assembled largely by an AI or low-code platform from prompts, templates, and defaults. The risk is that functional output can be produced before security design is fully reviewed, leaving policy, lifecycle, and access controls under-specified.

What's in the full report

Symbiotic Security's full research covers the operational detail this post intentionally leaves for the source:

• Per-vulnerability breakdowns across 80 security rules, including the exact conditions that triggered read, write, update, and delete exposure.
• Discovery methodology across 19 sources and 2,052 queries, useful if you need to replicate or adapt the scanning approach.
• Table-level exposure examples such as payments, admin_users, and chat_messages, which show how risky data appears in real deployments.
• Implementation context for the scanner's autonomous analysis pipeline, including how findings were prioritised and summarised.

👉 Symbiotic Security's full research covers the scan methodology, table-level exposures, and vulnerability breakdowns in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and IAM. It helps practitioners connect identity controls to the broader release and governance decisions that shape modern application security.