Is Your Vibe-Coded App a Security Risk? What Breaks First With Real Users

Is a vibe-coded app a security risk with real users?

A vibe-coded app built with Cursor, Lovable, Bolt, or Replit is a security risk with real users because AI tools optimise for a working demo, not for authentication correctness, database access controls, or production configuration. The app works. That does not mean it is safe.

This is not a rare edge case. When a security firm scanned 1,072 vibe-coded apps in production in 2026, over 300 had database keys exposed in client-side JavaScript and 172 allowed anyone to delete data without authentication. These are not the apps of careless founders. They are the default output of tools built to move fast.

This post covers the three most common security failure modes, three checks you can run in under 15 minutes, and what to do if you find a problem.

What security problems show up first in a vibe-coded app?

Authentication fails first. In 90% of vibe-coded production security incidents, authentication is the failure mode that surfaces before anything else.

1. Authentication — why it always breaks first

Cursor, Lovable, and Bolt generate authentication flows that work perfectly in a controlled test environment. They fail in production for one consistent reason: token expiry and session boundary handling.

In testing, you log in once and the session stays active. In production, real users log in across multiple devices, return after days, or stay logged in through token refresh cycles the AI never handled. When the token expires, the app throws an error it was never given instructions to catch.

The Moltbook breach in January 2026 is the clearest documented example. The AI-generated code exposed the Supabase API key in client-side JavaScript without enabling Row Level Security. A researcher with a regular account made ordinary API calls and accessed 1.5 million authentication tokens and 35,000 email addresses. No exploit was required. The app did exactly what it was built to do. What it was built to do was not secure.

Lovable-built apps had a platform-wide incident in 2025 catalogued as CVE-2025-48757 where access control logic was inverted across 170 production applications. Users could access other users' data. The apps worked exactly as built. The builds were wrong.

2. Database access controls — the invisible exposure

A Supabase or PostgreSQL database that returns data correctly in testing can expose every user's data in production if Row Level Security is not configured.

AI tools generate database queries that work. They do not generate database security policies by default. Supabase's anon key, which is always public by design, provides full read and write access to any table without RLS enabled. This means anyone who obtains your anon key from client-side JavaScript has full access to your database.

Configuration	What it means in production
RLS enabled on all tables	Anon key is safe to expose in client code
RLS disabled on any table	Anon key gives full database access to anyone
Service role key in client code	Complete database control to anyone who finds it

Roughly 40% of AI-generated code contains critical vulnerabilities according to Veracode's 2025 GenAI Code Security Report. A 2026 study by AppSec Santa confirmed the figure at 25.1% with confirmed exploitable defects across six leading AI models.

3. Error handling — why founders never know before users do

Vibe-coded apps have almost no error handling. The AI generates the happy path, the flow that works when everything goes as expected. It does not generate the unhappy path, the flow that handles unexpected inputs, network failures, or edge cases.

When something breaks in production, most vibe-coded apps show the user a blank screen, an unhandled JavaScript error, or a spinner that never resolves. The founder finds out through an angry email from a paying customer, not through a monitoring alert, because there is no monitoring.

Production incidents per pull request rose 23.5% between December 2025 and early 2026 as AI code volume accelerated faster than testing discipline. A founder shipping new features on a Friday with no test coverage is one prompt away from breaking production for every current user.

How do I check if my vibe-coded app has a security vulnerability?

You can run three checks yourself in under 15 minutes. No developer required.

Check 1 — Exposed API keys in client-side JavaScript

Open your live app in Chrome. Open DevTools with F12. Go to the Sources tab. Search for the strings supabase, api_key, secret, token, and NEXT_PUBLIC_.

If you find your Supabase URL and anon key, go immediately to your Supabase dashboard. Go to Table Editor. Check whether Row Level Security is enabled on every table that contains user data. If RLS is off, anyone with your anon key has full read and write access to that table. This is the exact configuration that caused the Moltbook breach and is the most common finding in vibe-coded app security reviews.

Check 2 — Unauthenticated API endpoints

In DevTools, go to the Network tab. Use your app normally by browsing, submitting a form, and loading data. Look at the API calls being made. Copy one of those API URLs. Open it in a private browser window where you are not logged in.

If the request returns data, your API endpoints are not requiring authentication. Anyone who knows the URL can access your users' data without an account.

Check 3 — Database access without authorisation

If your app uses Supabase, open your Supabase dashboard. Go to Table Editor. Check whether RLS is enabled on every table that contains user data. If it is off, your Supabase anon key, which is always public, gives full read and write access to that table to anyone who has it.

Georgia Tech's Vibe Security Radar tracked 35 new CVE entries directly caused by AI-generated code in March 2026 alone. The same month, researchers estimated the true count across the broader open-source ecosystem could be five to ten times higher.

Should I rebuild my vibe-coded app or fix the existing security issues?

For most vibe-coded apps at fewer than 500 users, fixing is faster and cheaper than rebuilding. The decision depends on whether the security issues are discrete or embedded in the architecture.

5 signals that mean fix, not rebuild

Signal	What it means
A developer can read and understand the codebase in under a week	The structure is recoverable
You can ship a small feature in under 2 weeks	Development velocity is not yet destroyed
The core data model reflects your actual business logic	The foundation is correct even if security gaps exist
Security issues are discrete and fixable such as exposed keys and missing RLS	These are patched without structural changes
You have runway to fix incrementally	You are not in a crisis that requires a full restart

5 signals that mean rebuild, not fix

Signal	What it means
A new developer cannot understand the codebase after a week	The structure is not recoverable without a rewrite
Features take 3 to 5 times longer to ship than they should	Technical debt has compounded to the point of blocking growth
Security issues are embedded in the architecture rather than discrete patches	Individual fixes would leave the underlying risk
You have had a security incident or have regulatory exposure	Fixing incrementally is not fast enough
The data model does not reflect how the business actually works	The foundation is wrong and fixing the surface changes nothing

Technical debt visible at 100 users typically means features take 3 to 5 times longer to ship at 500 users. The cost of addressing it compounds with every week it is left.

What does a security audit of a vibe-coded app actually include?

A technical audit of a vibe-coded app is 1 to 2 weeks of structured investigation into your existing product. It produces a written report that identifies exactly what is broken, in what order to fix it, and with what estimated effort.

What the audit covers

Area	What is reviewed	What you get
Authentication and session handling	Token expiry, session boundary logic, multi-device behaviour	List of auth vulnerabilities with remediation instructions
Database security	Row Level Security configuration, exposed keys, query performance	RLS audit results with index recommendations
API endpoint security	Unauthenticated endpoints, authorisation logic, rate limiting	Endpoint map with security status for each
Error handling and monitoring	Error boundary coverage, logging, alerting	Gap analysis with recommended monitoring stack
Deployment and environment	Environment variable handling, staging vs production separation	Environment configuration review
Architecture assessment	Data model soundness, rebuild vs fix recommendation	Written recommendation with rationale

The output is a document you own with no ongoing commitment. If Forgex is not the right fit to implement the findings, the document is yours to take anywhere.

If any of the 3 checks above found a problem, or if you have not run them yet, send one line about what you built to hamza@forgex.systems and I will read it personally and let you know if a security audit makes sense for your situation.