Security Review for Vibe Coders · 25 min · Claude Code, Cursor, Lovable, v0, Bolt.new, Replit Agent, or similar
The Problem
Security advice online is usually written for engineers, full of terms like "CSRF" and "deserialization" that don't tell a non-engineer what to actually do. Here are the five that matter, in plain English, each with what it looks like and what to check.
1. Exposed secrets in code the browser can see
What it looks like: an API key (OpenAI, Stripe, a paid weather API, anything) typed directly into a file that ends up running in the user's browser, instead of on a server.
Why it matters: anyone can open your site, hit "View Source" or the browser's DevTools, and read that key in plain text. Once it's out, it's out — someone else can run up your bill or impersonate your app.
The check: search your own project for the literal text of any API key you've used. If it shows up in a file your browser downloads (anything under a folder like src/, public/, client/, or similar — ask your AI tool which files those are if you're not sure), that key needs to move to a server-side environment variable instead.
2. Missing database access rules
What it looks like: a database (Supabase, Firebase, and similar tools all have a version of this) where the "who can read/write what" rules were never turned on — this is exactly what happened at Moltbook.
Why it matters: without these rules, anyone with your project's public key — which is often visible in your own site's source — can read or write every row of every table, not just their own data.
The check: ask your AI tool directly: "Does every table in my database have row-level security (or equivalent access rules) enabled, and what exactly do those rules allow?" If the answer is vague, that's your answer.
3. Broken authorization (BOLA)
What it looks like: an API endpoint like /orders/1234 that checks "is someone logged in" but never checks "does this specific order belong to this specific logged-in person."
Why it matters: this is the Lovable vulnerability from Lesson 1. A logged-in user can quietly change 1234 to 1235 and read someone else's data.
The check: for every place your app fetches one specific thing by ID (an order, a message, a document), ask: does the code check that the ID belongs to the current user, not just that a user is logged in?
4. Unvalidated input
What it looks like: a form or search box where whatever the user types goes straight into a database query or a command, unfiltered.
Why it matters: this is the classic "SQL injection" family — someone types something malicious instead of a normal search term, and it does something the app never intended.
The check: ask your AI tool, "Does every place that takes user input use parameterized queries or an ORM, or is any input ever inserted directly into a raw query string?"
5. Missing security headers
What it looks like: the small set of HTTP response headers (like Content-Security-Policy, X-Frame-Options) that tell browsers "don't let this page be embedded elsewhere" or "don't run scripts from unexpected sources."
Why it matters: these are free to add, take one prompt, and close off several common attack types (clickjacking, some XSS variants) almost entirely.
The check: ask your AI tool to add standard security headers for your specific framework and host, and verify by loading your deployed site and checking response headers (most browsers' DevTools "Network" tab shows this).
If you only remember one thing from this lesson
Numbers 1 and 2 (exposed secrets, missing database rules) account for the large majority of real vibe-coding breaches reported so far, including every incident named in Lesson 1. If you only have ten minutes before shipping, spend it there.
You're reviewing a vibe-coded app before launch. It has a login page, HTTPS, and a nice design. Which of the five checks above would catch a Moltbook-style failure specifically?
Moltbook had none of its data actually protected at the database layer — the public API key had unrestricted access because row-level security was never enabled. A login page, HTTPS, and good design say nothing about whether the database itself is locked down; that's a separate check every single time.