Vibe-Coded App Security: 7 Flaws AI Coding Tools Ship by Default

Vibe coding has changed who gets to ship software. With tools like Lovable, Bolt, Cursor, v0, and Replit, a founder with an idea and a prompt can have a working SaaS app live in a weekend, no engineering team required. That speed is real, and it is genuinely great. But it carries a quiet cost that does not show up until it is too late: security.

AI coding tools optimize for working, not for secure. They will happily generate an app that signs users up, takes payments, and stores data, while leaving the database wide open. And the research backs this up. A 2025 Veracode analysis found that roughly 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability, a pass rate that has not improved over repeated testing. A landmark Stanford study found that developers using AI assistants wrote less secure code, while being more confident it was secure. Other analyses put AI-generated code at roughly 2.7x the vulnerability density of human-written code.

The fallout is already here. Over the past year, researchers have repeatedly found vibe-coded apps leaking secrets and exposing entire databases, often within days of launch. One widely reported Row-Level Security flaw exposed data across 170+ AI-generated apps, including emails, payment details, and API keys.

This guide breaks down the seven vulnerabilities vibe-coded apps ship by default, what each one looks like in the real world, and exactly how to fix it before an attacker, or your enterprise buyer's security team, finds it first.

Why AI-built apps are uniquely exposed

A human engineer who has shipped a few production apps carries a mental checklist: lock down the database, keep secrets on the server, confirm that this user actually owns that record. An AI model has no such instinct. It pattern-matches to the most common code it has seen, and the most common code online is a tutorial, not a hardened production app. Tutorials leave authorization "as an exercise for the reader."

Vibe coding then compresses the timeline. There is no code review, no security engineer, and often nobody who would recognize a missing access-control check if they saw one. The app works in the demo, so it ships. The gap between "it works" and "it is safe to put real users behind it" is exactly where attacks live.

1. Exposed databases (Row-Level Security left off)

This is the single most common, and most damaging, flaw in vibe-coded apps. Backends like Supabase are excellent, but they ship with a sharp edge: new tables have Row-Level Security (RLS) disabled by default. Because the Supabase anon key is, by design, shipped to the browser, anyone who opens your site's JavaScript can query the database directly, bypass your app entirely, and read every row in any table that has no RLS policy.

That is not theoretical. The Moltbook breach in early 2026 exposed a full production database, reportedly including over a million API tokens and tens of thousands of email addresses, after AI-generated code put the Supabase key in the client and skipped RLS.

The fix: Enable RLS on every table (alter table ... enable row level security) and add explicit policies (for example, user_id = auth.uid()). Audit every table, RLS is off by default on new ones. Never rely on the app layer to keep data private when the database is reachable directly.

2. Hardcoded secrets and API keys

Ask an AI to "connect Stripe" or "call this API" and there is a good chance it drops the secret key straight into your front-end code, where anyone can read it in seconds through browser DevTools. Researchers scanning vibe-coded sites have found thousands of live secrets leaking this way: Stripe keys, database credentials, and third-party tokens. A leaked payment or cloud key can be drained or abused within hours, and the bill lands on you.

The fix: Keep every secret server-side, in environment variables, never in client code or the repository. Use only publishable keys in the browser. Rotate any key that has ever been exposed, and add secret scanning to your pipeline.

3. Broken access control (IDOR and BOLA)

AI loves to build endpoints like GET /api/orders/123, fetch the record by its ID, and return it, without ever checking that the order belongs to the person asking. Change the number to 124 and you are reading someone else's data. This is an Insecure Direct Object Reference (IDOR), or its API cousin Broken Object-Level Authorization (BOLA), and it is rampant in AI-built apps because the model treats a valid login as proof of ownership. It is not.

The fix: Enforce ownership on every object access, server-side. Verify the record belongs to the caller (or that their role permits it) before returning, updating, or deleting it. A single, centralized authorization layer beats patching endpoints one at a time.

4. Injection and cross-site scripting (XSS)

Despite sitting on the OWASP Top 10 for over a decade, injection and XSS are still everywhere in AI-generated code. Models concatenate user input straight into SQL queries, or render it into the page without escaping. One study found AI tools failed to prevent XSS in 86% of test cases. The result: an attacker can read your entire database (SQL injection) or run code in your users' browsers to steal their sessions (XSS).

The fix: Use parameterized queries or your ORM's query builder, never string-concatenated SQL. Escape or sanitize all output, and lean on a framework that escapes by default. Add a Content-Security-Policy header as defense-in-depth.

5. Broken authentication

Auth is hard, and AI cuts corners. Common patterns: login endpoints with no rate limiting (so credential-stuffing runs unchecked), password-reset flows that can be replayed, email-change endpoints that work with no re-authentication (a one-click account takeover), and missing or optional MFA. Any one of these turns a stolen or guessed password into a full account compromise.

The fix: Rate-limit and lock out repeated login failures, require the current password (or a fresh re-auth) for sensitive changes, confirm email changes to the old address, and use a vetted identity provider instead of rolling your own.

6. Security misconfiguration

The unglamorous category that quietly enables the others: wildcard CORS that lets any site make authenticated requests on a victim's behalf, open storage buckets that list every uploaded file, missing security headers, and verbose error messages that leak stack traces and internal paths. AI rarely configures these, it focuses on the happy path.

The fix: Reflect only trusted origins in CORS (never pair a wildcard with credentials), lock down storage-bucket permissions, set the standard security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options), and return generic errors in production.

7. Business-logic flaws

The vulnerabilities a scanner will never catch. These are bugs in how your app is supposed to work: a checkout that trusts a price sent from the client (so the user pays whatever they want), a coupon that can be applied infinitely, a workflow step that can be skipped. AI builds exactly what you asked, including the loopholes you did not think to close, and automated tools have no idea what your business rules are.

The fix: Compute anything that touches money or trust on the server, from data you control, never the client. These flaws are found by a human thinking like an attacker, which is the heart of a real penetration test.

Your pre-launch security checklist

Before you put real users (or a paying customer) behind your vibe-coded app, run through this:

• Row-Level Security is enabled on every database table, with explicit policies.
• No secrets, API keys, or credentials anywhere in client-side code or the repo.
• Every record fetch, update, and delete checks that the caller owns it.
• All database queries are parameterized, and all output is escaped.
• Login is rate-limited, and sensitive changes require re-authentication.
• CORS is restricted to trusted origins, and storage buckets are private.
• Security headers (CSP, HSTS, X-Frame-Options, nosniff) are set.
• Prices, totals, and permissions are enforced server-side.
• You have had a human, not just a scanner, try to break it.

Why a scanner is not enough

It is tempting to run an automated scanner, see a green checkmark, and call it done. But scanners are pattern-matchers. They are good at flagging known-bad signatures and missing headers, and useless at the things that actually breach vibe-coded apps: business-logic flaws, chained access-control bugs, and "this endpoint trusts the client" mistakes that require understanding the app to find.

That is the gap a real penetration test fills. A human security engineer attacks your app the way an attacker would, chains small issues into real exploits, and writes up exactly how to fix each one. If you want to see what that looks like, we publish a full sample pentest report, and you can read exactly what we find in an AI-built app.

The bottom line

Vibe coding is not the problem, shipping it unexamined is. The same speed that lets you build an app in a weekend means the security gaps ship just as fast. The good news: the flaws above are well understood and fixable, usually in days, not weeks. Run the checklist, fix what you find, and get a human to pressure-test it before launch.

A real, human penetration test of your AI-built app starts at $499, finds these issues, and hands you a report that clears your enterprise buyer's security review. Get a pentest, or see a sample report first.