Blog · 22 articles · 2 pillars

Practical guides for finding and fixing security flaws in AI-generated apps.

Written for solo developers and small teams shipping on Lovable, Bolt.new, v0, and Replit. Builder-to-builder. Concrete commands. Working SQL.

10 checks vibecheck runs that other scanners miss

Mozilla Observatory and SecurityHeaders.com grade response headers. Vibecheck reads the JavaScript bundle: it pulls Supabase JWTs and decodes them, finds OAuth authorize URLs and inspects parameters, fingerprints Service Worker registrations, locates LLM prompt templates left in client code, and checks whether importScripts calls cross trust boundaries.

The vibe coding security guide

The complete map. Where AI app builders fail in four predictable ways, what real breaches look like, and the five-stage workflow to ship without leaking.

Supabase RLS patterns for vibe-coded apps: every common shape with the SQL

Eight RLS patterns covering ~95% of what vibe-coded apps need: per-user ownership, public-readable, tenant-scoped, profile, member-of-conversation, soft-delete, append-only audit log, visibility levels. With actual policy SQL, the WITH CHECK gotcha, performance pitfalls, and a testing strategy.

Lovable vs Bolt.new vs v0 vs Replit Agent: security comparison

Four AI app builders compared on what they ship by default — hosting model, RLS, secrets handling, sourcemaps, CI. The matrix that tells you which one to reach for and what extra work each one demands.

Anatomy of the Moltbook breach: 1.5M tokens, 35K emails, 72 hours

The textbook vibe-coded breach. RLS never enabled, anon key in the bundle, every table publicly readable. A forensic timeline from launch tweet to data dump, plus the four lines of SQL that would have prevented it.

Your Supabase service_role key is in your client bundle. What to do in the next 15 minutes.

If service_role appears in your client JS, every visitor can bypass Row-Level Security entirely. The four-step response: revoke, rotate, audit, prevent.

Lovable security checklist: 8 things to verify before your launch tweet

20% of Lovable-built orgs had public DB misconfigurations. 10.3% had critical RLS failures. The audit Lovable does not ship — eight items with exact commands to test each one.

Bolt.new security: 7 things to verify before sharing the URL

Bolt ships full-stack apps in WebContainers in minutes. Seven specific failures that show up in Bolt-built apps — env vars in src/, sourcemaps in production, generated CORS holes, exposed dev routes — and how to fix each one.

v0 by Vercel security: 6 things to review before pasting the code

Unlike Lovable and Bolt, v0 doesn't host your app. It generates Next.js code you paste into your repo. The risk is what makes it through your review — six patterns to catch what v0 ships you.

Replit Agent security: 6 things to check before going public

Replit Agent ships full-stack apps fastest because it owns the entire stack. That breadth is also why the security surface is biggest. Six checks to run before flipping from private to public.

Convex security: 6 things to verify before flipping your app public

Convex doesn't have Row-Level Security. Every query and mutation must enforce auth at the function level. Six concrete things to check in any Convex app.

Appwrite security: 6 collection-level checks before going public

Appwrite has rich collection-level permissions but they're permissive by default. Six checks: read/write permissions, document rules, attribute exposure, function auth, storage buckets.

Pocketbase security: 6 collection-rule checks before you self-host

Pocketbase's default rules are blank — which means open. Six checks for any self-hosted Pocketbase deployment, from collection rules to admin UI exposure.

Firebase rules for vibe-coded apps: 6 checks before going public

Firebase test-mode rules grant public access for 30 days — apps regularly ship before the timer fires. Six checks across Realtime Database, Firestore, Storage, Auth, App Check, and the client config — with the exact rule blocks to copy.

Your Stripe live key is in your client bundle. Read this in the next 10 minutes.

If sk_live_ is in your JavaScript, every visitor can issue refunds, drain customers, and pull payment methods. Five-step response: roll, verify, audit, file, prevent.

Your OpenAI or Anthropic key is in your client bundle. Read this in the next 10 minutes.

If sk- or sk-ant- shows up in your bundle, every visitor can drain your API budget. Five-step response: rotate, scope (restricted keys / Workspaces), audit usage anomalies, find every commit and CI log, prevent the next one with a server proxy.

JWT mistakes in vibe-coded apps: 5 patterns that ship to production

JWTs with alg: "none", no exp claim, multi-month expiration, hardcoded admin tokens, stale test fixtures. Five patterns vibecheck flags in client bundles — with the exact jose / jsonwebtoken verifier code to copy.

Your webhook secret is in your client bundle: forge-anything for every provider you use

Stripe whsec_, GitHub webhook secrets, Slack signing secrets, generic WEBHOOK_SECRET strings. When they leak, attackers forge any event your handler accepts. Provider-by-provider rotation walkthroughs.

CORS misconfigurations in vibe-coded apps: how attackers steal authenticated data

The "echo the Origin header" pattern + Allow-Credentials: true = one-step path to cross-origin theft. Five patterns vibecheck flags via active probing, with the exact cors middleware config to copy.

CSP bypasses in vibe-coded apps: 6 weak directives and the strict policy that fixes all of them

'unsafe-inline', 'unsafe-eval', wildcard script-src, data: in script-src, missing default-src, Report-Only forever. Six CSP weaknesses vibecheck flags, why each is exploitable, and the strict-CSP recipe that replaces them.

vibecheck inspects vibecheck: the dogfooding write-up

Every deploy ends with a smoke that runs vibecheck against vibecheck. Current self-scan: grade D, one accepted CSP finding (with the trade-off documented), every other detector clean. The smoke gate prevents the D from quietly becoming an F.

Using Supabase service_role correctly: the production runbook

When you actually need service_role, where it lives, the per-request authorization layer that prevents every caller from getting admin, and how to log every privileged operation. The piece between "leaked service_role" and "don't use service_role at all".

Sourcemap leaks in vibe-coded apps: how attackers reconstruct your codebase from a .map file

Three minutes of an attacker's time and your src/ is on their disk — comments, dead code, and committed secrets included. Per-bundler config fixes for Vite, Next.js, webpack, esbuild, Rollup. The three legitimate reasons to ship maps anyway.

CSRF edge cases in vibe-coded apps: SameSite isn't enough, tokens that don't actually verify, the bearer-token escape hatch

SameSite=Lax blocks most CSRF — but state-changing GETs slip through, === token comparison is timing-attackable, parent-domain cookies cross subdomain takeovers, bearer-token auth (Supabase, Firebase) sidesteps CSRF but creates XSS-amplification problems, and JSON endpoints with permissive content-type checks accept cross-site form posts. Five edge cases.

Coming soon

What's queued.

A "first 30 days as a Supabase admin" guide and a "10 things vibecheck checks that nobody else does" post are next. Inspect your app in the meantime — every detection rule has a dedicated /fix/<rule> page with remediation code.

Run an inspection Browse 135 fix guides