The Vibe Coder's Pre-Launch Security Checklist: 25 Checks for Cursor, Lovable, Bolt & Replit Apps

Hack Safe — Thu, 11 Jun 2026 05:22:05 +0000

The Vibe Coder's Pre-Launch Security Checklist: 25 Checks for Cursor, Lovable, Bolt & Replit Apps

I scanned 62 Lovable apps in early 2026.

63% had critical or high severity vulnerabilities. The average app had 10 findings.

These weren't obscure edge-case bugs. They were the same mistakes, over and over: exposed API keys, disabled row-level security, missing authentication on routes, no rate limiting on login endpoints.

The apps looked great. They worked perfectly. They were completely open to anyone who knew where to look.

This is the vibe coding security problem in one sentence: AI tools optimise for working, not safe. Those aren't the same thing.

If you built your app with Cursor, Lovable, Bolt, Replit, or any AI coding tool — this checklist is for you. No security background required. Every item is written in plain English with a specific, actionable fix.

Run through this before you share the link.

Why AI-built apps keep getting hacked

AI coding assistants generate functional code fast. That's the point. But there are three structural reasons why they consistently produce insecure code:

1. They optimise for the happy path. When you prompt "build me a login system," the AI builds something that works for a legitimate user. It doesn't automatically think about what an attacker would do.

2. They're trained on tutorials and demos. Most training data comes from documentation examples and beginner tutorials — content written to be simple and readable, not production-secure.

3. They don't know your full context. The AI doesn't know that your /api/admin route shouldn't be public. It doesn't know your Supabase tables contain payment data. It builds what you asked for, not what you actually need.

The result is a consistent set of vulnerabilities that show up in almost every vibe-coded app. This checklist covers the 25 most common ones.

The 8 categories

The vulnerabilities cluster in the same eight areas almost every time:

🔑 Secrets & Keys — API keys, credentials, environment variables
🔐 Auth & Access — Route protection, RLS, admin access, session management
🗄️ Data & Database — SQL injection, IDOR, data exposure
🌐 API Security — Rate limiting, CORS, input validation, file uploads
🚀 Deployment — Production config, HTTPS, security headers, source maps
🖥️ Frontend — XSS, localStorage misuse, client-side secret exposure
📦 Third-Party — Dependency CVEs, script integrity, webhook verification
📊 Monitoring — Logging, alerting, incident readiness

The checklist — first 10 items free

I'm sharing the first 10 items in full here. The complete 25-item checklist (including 2 full AI audit prompts you can paste directly into Cursor or Claude) is available as a free download at the end of this article.

🔑 SECRETS & KEYS

01 — No API keys in client-side code HIGH

Search your entire repo for strings matching sk-, pk-, AIza, Bearer, or _KEY=. Any key visible in your browser's DevTools Network tab or in your JavaScript bundle is already compromised — anyone can steal it and run up your bill.

Fix: Move all API keys server-side. In Next.js, never use NEXT_PUBLIC_ prefix on secret keys. In Vite, never use VITE_ prefix on anything sensitive. Keys that start with these prefixes get bundled into the JavaScript every user downloads.

02 — .env file is gitignored and not in git history HIGH

Your .env file might be gitignored now — but was it always? Run this in your terminal:

git log --all --full-history -- .env

If that command returns results, your secrets have been committed to git history at some point. Even if you deleted the file later, the secrets are still there in the history and visible to anyone with access to the repo.

Fix: Rotate every secret that was ever in your .env. Then run git filter-branch or use BFG Repo Cleaner to purge the file from history.

03 — No hardcoded credentials in AI-generated code HIGH

AI tools frequently write demo credentials inline. Search your codebase for these strings:

password=
secret=
token=
api_key=
apikey=
DATABASE_URL=

Look specifically inside component files, API route handlers, and any config files. I find hardcoded credentials in roughly 1 in 3 vibe-coded codebases.

Fix: Every credential goes in .env. Reference it as process.env.YOUR_SECRET. Never in the code itself.

🔐 AUTH & ACCESS

04 — All routes check authentication before serving data HIGH

This is the most commonly missed check. Manually test every API endpoint by opening your browser's DevTools, deleting your authentication cookie, and making the same request again.

If you still get data back — auth is either missing or bypassable.

In Next.js App Router, check that every route.ts file that returns user data calls getServerSession() or equivalent at the top. In Supabase Edge Functions, verify every function checks the JWT.

Fix: Add an auth check as the very first thing in every protected route handler. If there's no valid session, return 401 immediately before any database query runs.

05 — Row-Level Security (RLS) is enabled on every Supabase table HIGH

This is the vulnerability behind CVE-2025-48757 — the Lovable breach that exposed 170 production apps and tens of thousands of user records.

RLS is off by default in Supabase. This means any logged-in user can read every row in every table, including other users' data, using the public API key that's visible in your frontend code.

Go to your Supabase dashboard → Table Editor → select each table → check the RLS toggle. It must be ON for every table that contains user data.

Fix:

-- Enable RLS on a table
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

-- Allow users to only read their own rows
CREATE POLICY "Users can only see their own data"
ON your_table FOR SELECT
USING (auth.uid() = user_id);

06 — Admin routes are not accessible to regular users MEDIUM

Test this manually: log in as a regular user account, then try to access /admin, /dashboard/admin, /api/admin, or any privileged endpoint. If you get data instead of a 403 or redirect, you have a privilege escalation vulnerability.

The most common cause: the admin check only runs client-side (hiding the button in the UI) but the API endpoint itself has no server-side permission check.

Fix: Every admin API route needs a server-side check that verifies the user's role from a trusted source (your database), not from a value passed in the request body or JWT claims the user could modify.

🗄️ DATA & DATABASE

07 — User inputs are never inserted directly into queries HIGH

AI-generated database code often uses string concatenation to build queries. This is SQL injection — one of the oldest and most dangerous vulnerabilities in web applications.

Never do this:

// Dangerous — user input goes straight into the query
const result = await db.query(`SELECT * FROM users WHERE id = ${userId}`)

Do this:

// Safe — parameterised query
const result = await db.query('SELECT * FROM users WHERE id = $1', [userId])

If you're using Supabase's JavaScript client with .eq(), .filter(), and similar methods, you're already using parameterised queries. But if you're running raw SQL anywhere, check every query.

08 — Users can only access their own data HIGH

This is called an Insecure Direct Object Reference (IDOR) — and it's the #1 most missed vulnerability in vibe-coded apps.

Test it yourself: Log in as User A. Copy the URL or ID of any resource you own — a post, a document, an order, a profile. Log out. Log in as User B. Try to access that resource by its ID.

If User B can see User A's data, you have an IDOR vulnerability.

Fix: Every database query that fetches a resource by ID must also filter by the current user's ID:

// Wrong — fetches the document if it exists, regardless of who owns it
const doc = await supabase.from('documents').select('*').eq('id', docId)

// Right — only fetches the document if the current user owns it
const doc = await supabase.from('documents').select('*')
  .eq('id', docId)
  .eq('user_id', session.user.id)

09 — Sensitive data is not logged MEDIUM

AI debugging code commonly adds console.log statements that print full request bodies, authentication tokens, and user emails to your server logs. In production, these logs are often sent to third-party services like Sentry, Datadog, or LogRocket.

Search your codebase for console.log in production code paths (not just dev files). Look specifically for logs that print req.body, req.headers, JWT tokens, or anything containing user emails or names.

Fix: Remove debug logs before deploying. If you need logging, use a structured logger that explicitly allows-lists which fields to include.

10 — Rate limiting on auth and payment endpoints HIGH

Without rate limiting, your login endpoint can be brute-forced (attackers try thousands of passwords per minute). Your AI API endpoints can be abused to generate massive bills. Your email/OTP endpoints can be used to spam users.

Check whether your /api/login, /api/register, /api/reset-password, and any AI or payment endpoint has rate limiting applied.

Fix: In Next.js with Vercel, use @upstash/ratelimit. In Express, use express-rate-limit. Minimum: 10 requests per minute per IP on auth endpoints.

import { Ratelimit } from "@upstash/ratelimit"

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "1 m"),
})

The remaining 15 checks

Items 11–25 cover:

CORS misconfiguration (a wildcard * lets any website make requests as your logged-in users)
File upload validation (frontend-only validation is bypassed in seconds)
Production environment configuration (dev mode exposes stack traces to anyone)
HTTPS enforcement and cookie security flags
Security headers (most AI-built apps score F at securityheaders.com)
Source map exposure (lets anyone reverse-engineer your code)
XSS via dangerouslySetInnerHTML
Sensitive data in localStorage
Third-party script integrity
Dependency CVEs (npm audit before every deploy)
Webhook signature verification
Failed login attempt logging
API usage spike alerting
Incident response readiness

The 2 AI audit prompts

The free checklist also includes 2 full AI audit prompts — one for a complete codebase sweep, one specifically for Supabase/database access. Copy either one into Cursor, Claude, or ChatGPT with your codebase open and run it before you launch.

Prompt 01 gives you: severity rating, exact file and line number, plain-English explanation, and the actual corrected code for every vulnerability it finds.

Prompt 02 gives you: a full RLS policy audit, SQL injection check, and service role key exposure check for your database layer.

Get the complete checklist — free

The full 25-item checklist is available as a free PDF download.

It includes all 25 items with risk levels, exact checks, and one-line fixes — plus the 2 full AI audit prompts.

→ Download free at store.dodopayments.com/hack-safe

No email required.

Want the full audit system?

The HackSafe Audit Kit ($3.99) turns this checklist into a live Notion workspace — track every fix, run all 25 targeted AI audit prompts (one per attack category), filter by risk level, and sign off your pre-launch gate.

One-click Notion duplicate. Setup in 20 minutes.

→ Get the HackSafe Audit Kit

Found a vulnerability type I missed? Drop it in the comments — I update this article every 60 days with new findings from real vibe-coded app audits.

DEV Community: Hack Safe

The Vibe Coder's Pre-Launch Security Checklist: 25 Checks for Cursor, Lovable, Bolt & Replit Apps