Security Review for Vibe Coders · 20 min · Claude Code, Cursor, Lovable, v0, Bolt.new, Replit Agent, or similar

Why Vibe-Coded Apps Get Hacked

AI can build you a working app and a secure app for the same amount of typing — the difference is entirely in what you ask for and what you check.

Real-world application: Every real vibe-coding breach so far traces back to the same root cause: nobody told the AI to secure a specific thing, and nobody checked whether it had. Spotting that pattern is the one habit this whole course is built around.

What you will learn

Explain what actually went wrong in the Moltbook and Lovable breaches, in plain English
Distinguish authentication (are you logged in) from authorization (should YOU see THIS) — the single most common failure
State the one habit that would have prevented both breaches

Objective

Answer three honest questions about your own (real or planned) app so you know, before writing any security checks, exactly what's actually at stake if it gets breached.

Two vibe-coded apps made real news in 2026 — for the wrong reason. Both stories are short, both were avoidable, and both come down to the exact same mistake.

The Problem

Moltbook, an AI social network where autonomous agents posted and messaged each other, launched on January 28, 2026. Its founder said publicly he "didn't write a single line of code" — the whole thing was AI-built. Three days later, security researchers found the entire production database sitting open to the internet: 1.5 million API tokens, 35,000 email addresses, and thousands of private agent-to-agent messages — some of them containing plaintext OpenAI API keys the agents had shared with each other.

The cause wasn't exotic. The AI tool had wired the app up to Supabase (a common backend-as-a-service vibe coders use for a database and auth in one). It exposed the project's API key in the site's client-side JavaScript — completely normal, that key is supposed to be public — but it never turned on Row Level Security (RLS), the setting that actually restricts what that public key can read and write. Without RLS, the "public" key had full read/write access to every table in the database. The entire fix was two SQL statements.

Lovable, a $6.6B vibe-coding platform used by 8 million people, has had three separate public security incidents. The most recent: a BOLA vulnerability (more on this in a second) that stayed open for 48 days after Lovable's own team closed the bug report without escalating it.

One pattern, two breaches
Neither of these happened because an engineer made a subtle mistake under pressure. They happened because nobody — not the AI, not the founder — ever asked the specific question "who is allowed to see this data, and did we actually restrict it to them?" AI coding tools will happily ship an app that works without ever being asked to make it safe. Working and safe are two different requests.

Authentication vs. authorization — the distinction that keeps causing this

Almost every vibe-coding breach comes down to confusing these two questions:

Authentication: "Is this person logged in?"
Authorization: "Should this specific logged-in person see this specific piece of data?"

AI tools are good at building authentication — login forms, password fields, "you must be signed in" walls — because it's a well-known, heavily-documented pattern. They're much worse at authorization by default, because it requires knowing your app's actual data model: this order belongs to this user, so that user shouldn't be able to fetch it by guessing its ID in a URL. That exact gap — checking "are you logged in" but never checking "should you see this one" — is called BOLA (Broken Object-Level Authorization), and it's the Lovable vulnerability mentioned above.

Your AI coding tool just told you: "I've added authentication, so your app is secure now." What's the most important thing to check before you believe that?

"Authentication" only means someone proved who they are. It says nothing about whether they're allowed to see any specific piece of data. An app can have flawless login and still let User A read User B's private messages just by changing a number in a URL — that's exactly what happened at Lovable. Polish, password length, and a privacy policy page don't touch this at all.

Why this matters even for a "small" project

"It's just a side project, nobody's going to hack it" is the exact sentence in front of both breaches above. Moltbook wasn't a bank — it was a hobby AI-agent social network. It got scanned and breached within 72 hours of being publicly reachable, not because it was a big target, but because automated scanners constantly sweep the internet for exactly this pattern (a public Supabase URL and key with no RLS). If your app is on the public internet and touches any real data — emails, messages, API keys, anything a user typed expecting privacy — this applies to you starting the day you deploy, not the day you get popular.

Your practice rep

Before the next lesson, spend 10 minutes threat-modeling your own app (a real one you're building, or one you're about to start):

Open a new file called threat-model.md.
Answer three questions in it, honestly: - Does this app store any real user data (emails, messages, files, API keys)? - Does it have a login / user accounts? - Does it call any paid API (OpenAI, Anthropic, Stripe, etc.) from code that runs in the browser?
For each "yes," write one sentence: if this leaked or was misused, who would that actually hurt, and how?

You'll use this file again in Lesson 4 — it's the starting point for your real pre-launch security pass.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Build, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account — the opening phases of 29 of 35 courses are free, no credit card.