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.
Editorial analysis by NHI Mgmt Group, based on content published by Symbiotic Security: “We Scanned 1,072 Vibe Coded Apps, 98% Had Security Flaws!”.
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.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: The article shows that generated applications can reach production with public data paths because authorization was never established as a build requirement.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:15 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Vibe coded apps expose a broad identity and data access gap