Vibe coding security checklist: 8 layers to test on your live app before launch

How to use this checklist

This checklist follows the order in which a stranger looks at an app built with Lovable, Bolt, Replit, v0, Cursor or Claude Code: the data first, then the keys, then the accounts. Each item comes with a test you can run on your own live app in a few minutes. Tick it when you have seen the result, not when your coding agent says it is fixed: ask the agent for the evidence, such as the empty query result or the 401.

The live app is what counts. In March 2025, a researcher scanned 1,645 apps built with Lovable: 170 of them, about one in ten, had missing or weak row level security that let unauthenticated visitors read or write data. That scan led to CVE-2025-48757, which Lovable disputes on the grounds that each customer is responsible for their own app's data. For why these bugs keep showing up in generated code, read vibe coding security risks.

Platform scanners help, so run them: Lovable's Quick scan checks database access rules, dependencies and MCP servers exposed without authentication on every publish, and Supabase's Security Advisor lists issues in your database. Both inspect your project from the inside. Neither signs in as two different users and tries each other's records, which is where the worst bugs hide.

1. Data access: rules on every table and every bucket

Your Supabase publishable key, or the older anon key, ships in your frontend, and so does your Firebase config. That is by design. What protects the data is row level security (RLS) in Supabase and Security Rules in Firebase: rules inside the database that decide, row by row, who can read and write. Supabase's own production checklist says it plainly: a table without RLS and reasonable policies lets any client read and change its data.

• RLS is on for every table in every schema your API exposes, including tables your agent created in a SQL migration. The query below returns no rows.
• No policy on a table with personal data uses true as its condition, and no policy for authenticated stops at checking that someone is signed in without comparing a column to auth.uid().
• Tables in the Realtime publication have RLS and policies too. Supabase notes that RLS does not filter Postgres Changes DELETE events, so send sensitive changes through Broadcast with Realtime Authorization.
• Firebase: no rule says allow read, write: if true, and no rule stops at request.auth != null. Firebase's documentation warns that the second one gives any logged-in user access to the data.
• Storage buckets that hold invoices, ID scans or private uploads are private, with a policy that limits each user to their own folder.
• Security Advisor in the Supabase dashboard shows no errors. Treat each warning as a lead and confirm it with the tests here.

-- Tables in public with RLS off. The answer should be empty.
select schemaname, tablename
from pg_tables
where schemaname = 'public'
  and not rowsecurity
order by tablename;

Then test from outside, the way a visitor would. Pick a table your app reads, such as orders or profiles, and ask for it with nothing but the public key:

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/orders?select=*&limit=1" \
  -H "apikey: YOUR_PUBLISHABLE_KEY"

The fixes: policies for the usual cases in the Supabase RLS guide, the per-folder bucket policy in the storage guide, and owner-only rules in the Firebase rules guide.

2. Keys: no secret in the frontend

Anything your build puts in the JavaScript bundle is public. Vite bundles the VITE_ variables your code reads into the JavaScript it sends to the browser, and Next.js inlines NEXT_PUBLIC_ variables the same way. That is fine for a Supabase publishable key, a Stripe pk_ key or a Firebase web config, whose safety comes from the rules behind them. It is a leak for any key that can spend money or skip your rules.

• On your live site, open the developer tools and search all loaded files (Ctrl+Shift+F in Chrome, Cmd+Option+F on a Mac) for sk_live_, sk-proj-, sk-ant-, sb_secret_ and PRIVATE KEY. Nothing matches.
• A legacy Supabase service role key is a JWT starting with eyJ, and its role is encoded inside it, so a text search for service_role misses it. Paste each eyJ token you find into the Supabase key checker: only the anon key belongs in the browser.
• No server secret in your .env has a VITE_ or NEXT_PUBLIC_ prefix. Watch for a fix that adds the prefix to make an "undefined" error go away: it moves the secret into the bundle.
• Calls to OpenAI, Anthropic, Stripe or your email provider go through your server or an Edge Function that holds the key.
• A secret that was ever in a build, a commit or a screenshot has been revoked at the provider and replaced. Deleting the line is not enough: old builds, caches and git history still hold the value.
• After a rotation, a test call with the old key fails.

The API key leak checker names each key in code you paste and says which ones are secret. If one is, follow what to do with a leaked API key: revoke first, then read the provider's usage logs. The longer list of keys that belong only on a server is in API keys exposed in the frontend.

3. Auth: email confirmation, rate limits and the reset flow

Generated sign-up flows work on the happy path. These checks cover what a stranger tries next. The values are Supabase's documented defaults; other auth providers have the same settings under other names.

• Email confirmation is on, under Authentication > Sign In / Providers in Supabase. Without it, a stranger gets a session in one request, and every policy that only checks for a signed-in user lets them in.
• Sign-in is throttled. By default, Supabase Auth allows 30 requests per 5 minutes per IP address on sign-up, magic link, OTP and password recovery, and 150 per 5 minutes on the token endpoint that handles password sign-ins and refreshes, then answers 429. If you wrote your own login route, try a dozen wrong passwords on your own test account and expect a 429 or a CAPTCHA.
• Reset and confirmation links expire within an hour. Supabase's checklist asks for an OTP expiry of 3600 seconds or less, and that one setting also controls confirmation, recovery, email change and invitation links.
• The reset endpoint's answer never contains the reset token, and the link in the email points to your domain even when the request carries another Host or X-Forwarded-Host header.
• Site URL under Authentication > URL Configuration is your production domain, not http://localhost:3000, and the Redirect URLs list holds only your own domains.
• Sign-up, sign-in and reset answer the same way for an email that has an account and one that does not, so nobody can test which addresses are registered.
• Test phone numbers and test accounts with known passwords are gone before launch.
• Auth emails go through your own SMTP. Supabase's built-in provider sends 2 auth emails per hour for the whole project, so confirmations and resets stop arriving on launch day.

4. Per-user access: user B cannot read user A's rows

This is the bug a single-account test never finds, and one we see often in generated apps. The app checks that you are signed in, then returns whatever record the id in the request names. It is called an IDOR, an insecure direct object reference, and it lives in API routes and in database policies alike.

1. 1

   Create two accounts you own

   Use two browsers, or a normal window and a private one, so each keeps its own session. Call them A and B.

2. 2

   Create a record as A

   An order, a note, a file, a message. Copy its id from the address bar or from the request in the Network tab of the developer tools.

3. 3

   Ask for it as B

   Open the same address in B's window. Then replay A's API request with B's session: right-click it in the Network tab, choose Copy > Copy as cURL, and swap the cookie or Authorization header for B's.

4. 4

   Try to change it

   As B, edit and delete A's record through the same requests. Then repeat everything signed out.

5. 5

   Read the answer

   A 403, a 404 or an empty list is a pass. A's data, or a change that sticks, is a leak.

Add one more test: send an update for your own profile with an extra field such as role, plan or is_admin. If it sticks, any user can promote themselves. The fix for both bugs belongs on the server or in the database, on every read and every write: the record must belong to the person asking, and the server decides which fields a user may change.

create policy "Owners read their orders"
on public.orders for select
to authenticated
using ((select auth.uid()) = user_id);

create policy "Owners update their orders"
on public.orders for update
to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

// Before: returns any order to any signed-in user
// const order = await db.order.findUnique({ where: { id } });

// After: the order must belong to the signed-in user
const order = await db.order.findFirst({
  where: { id, userId: session.user.id },
});
if (!order) return new Response("Not found", { status: 404 });

5. AI endpoints: a session, a quota and a budget

Every route that calls a model costs money on each request. OWASP's Top 10 for LLM applications calls the risk Unbounded Consumption, and names one form of it Denial of Wallet: an attacker sends enough requests to run up the app owner's bill. A chat route that answers without a session is a free model API for whoever finds its address in your JavaScript.

• Every route and Edge Function that calls a model requires a signed-in session, checked on the server. The test below returns 401 or 403.
• Each user has a quota per minute and per day, counted on the server, not in the browser.
• The server caps input length and output tokens and picks the model. The client sends a message, not a model name or a token limit.
• A spending cap or usage alert is set in your model provider's dashboard, if it offers one, low enough that you hear about abuse before the invoice.
• The system prompt holds no keys, and no tool the model can call skips the access checks the rest of your API applies.

# Your own app only. No cookie, no token: this must fail.
curl -i -X POST https://your-app.example/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"Say hello"}'

The unprotected AI endpoint guide shows how to add the session check and a per-user quota without breaking streaming.

6. Files and headers

Your host serves what ends up in the build output, and some setups serve more than you meant. These checks take a few minutes with a terminal. For the headers, the security headers guide has the config for each host.

• /.env, /.env.local and /.git/config return 404 on your live domain, or your home page, never their contents.
• Source maps (.js.map files) are not served in production, unless you mean to publish your original source code.
• Your server sends Strict-Transport-Security, a Content-Security-Policy that includes frame-ancestors, X-Content-Type-Options: nosniff and a Referrer-Policy.
• Those headers come from your server or your host's config, not from a meta tag in the HTML: browsers ignore X-Frame-Options and frame-ancestors in a meta tag, so the protection against framing silently disappears.
• Session cookies carry Secure, HttpOnly and SameSite.
• Your API never echoes the caller's Origin in Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials: true.

# Your own domain only. Each file should answer 404, or your home page.
for p in /.env /.env.local /.git/config; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://your-app.example$p"
done

# The security headers on your home page
curl -sI https://your-app.example | grep -iE 'strict-transport|content-security|x-content-type|referrer-policy'

If a .env file does come back, treat every key in it as leaked. The exposed .env file guide covers the cleanup.

7. Framework versions and known CVEs

Your agent installs the version it knows, and nothing upgrades it after launch unless you do. A framework flaw hits every app on the affected versions, however careful your own code is.

• You know the exact versions running: npm ls next react react-dom, or the lockfile, not the ranges in package.json.
• Next.js is on the latest patch of a supported line. The Next.js November 2026 security release, published on 3 November 2026, shipped 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS).
• You are not on a version hit by React2Shell (CVE-2025-55182), remote code execution in React Server Components rated CVSS 10.0. It affects the React server packages 19.0.0, 19.1.0, 19.1.1 and 19.2.0, and Next.js 15 and 16 App Router apps before their fixed versions. The first React fixes (19.0.1, 19.1.2, 19.2.1) were followed by more flaws in the same code, such as CVE-2025-55184, so take the current patch, not the first one.
• Auth does not live only in middleware. CVE-2025-29927 let requests skip middleware in self-hosted Next.js before 15.2.3, 14.2.25, 13.5.9 and 12.3.5, so check the session again in each page, route handler and server action.
• npm audit --audit-level=critical, or your host's dependency alerts, runs on every pull request. The command exits with an error when it finds a critical vulnerability, so it can block the merge.

Paste your package.json into the Next.js CVE checker to see each known CVE that applies to your versions and the version that fixes it. A version tells you what might apply. Keybrum proves a CVE by its behaviour on the live app instead, and never runs remote code execution or denial-of-service payloads to do it. More on the framework side in the Next.js security guide.

8. Deploys: retest after every change

A checklist is a snapshot. The table your agent adds next week, the new API route, the dependency bump: each can reopen a hole you closed. Supabase's own security checklist says to run it again whenever you add tables, sign-in methods or teammates to a live project.

• Every migration that creates a table enables RLS on it in the same file.
• The query from section 1 and Security Advisor run again after each schema change.
• On Lovable, the Quick scan runs on every publish. The Deep scan, which reviews your app's logic and permissions, usually does not run on its own: start it from the Security view before you publish.
• The two-account test from section 4 runs again after any change to routes, policies or auth.
• Preview deployments do not point at your production database.
• You keep a dated log of what was tested and what failed. It is also the start of your answer to the first security questionnaire a customer sends.

This is the part Keybrum automates. It attacks your live app the way a stranger would: it reads your tables with the public key, signed out and then as a brand-new account; with your consent, creates a test record with one account and requests it with another; calls AI routes and Edge Functions without a session; sends eight wrong sign-ins to a probe address to look for throttling; and checks for exposed .env files, source maps and missing headers. Each finding comes with the request that worked, and your coding agent reads the fix through MCP. Plans attack again on every deploy.

The traps that survive a quick scan

• The fix lives in the frontend. Hiding a button or a page does not stop the API call behind it. Every check in sections 1, 4 and 5 has to hold when the request comes from a terminal.
• Views and `security definer` functions. Views run with their owner's rights by default, and security definer functions always do, so either can hand a locked table to the API. The RLS guide shows how to close them.
• Unsigned payment webhooks. A webhook route that grants a plan without checking the Stripe-Signature header against your whsec_ secret and the raw request body gives a paid plan to anyone who posts to it. The Stripe webhook guide has the code.
• Raw SQL and raw HTML. A query built by pasting user input into a string, or user content rendered with dangerouslySetInnerHTML, brings back SQL injection and cross-site scripting. Pass values as query parameters and let React escape text.