Notifications
Clear all
Topic starter
19/08/2026 3:34 pm
TL;DR: A scan of 1,072 vibe coded apps found that 98% had at least one security flaw, including 172 sites that allowed unauthenticated data deletion and 39 that exposed entire databases, according to Symbiotic Security. The security lesson is that fast generation without identity-aware authorization creates exploitable exposure at scale.
NHIMG editorial — based on content published by Symbiotic Security: Introducing Symbiotic Code and the findings from scanning 1,072 vibe coded apps
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.
Questions worth separating out
Q: What breaks when generated apps rely on public backend keys without row-level security?
A: The application’s data plane becomes effectively public.
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.
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.
Practitioner guidance
- Validate row-level security before release Test every generated Supabase-backed app with unauthenticated read, write, update, and delete requests against each exposed table.
- 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.
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.
👉 Read Symbiotic Security's research on security flaws in vibe coded applications →
Vibe coded apps and Supabase access controls: are your guards keeping up?
Explore further
19/08/2026 4:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Vibe coded apps expose a broad identity and data access gap
