Vibe Coding Security Checklist: 12 Checks, Each With a Test (2026)

Use this vibe coding security checklist at three moments: before signups, before payments, and every month after launch. It applies to apps built with Lovable, Bolt, Base44, Replit, Cursor, Claude Code or v0, on Supabase, Firebase or whatever database sits behind them. Each of the 12 checks names a test and the failure signal to look for, so the list produces evidence instead of a row of unchecked security topics.

Times are our own rough estimates for a founder doing each check once, not a benchmark.

Vibe coding security best practices, in the order real risk arrives

Three tiers, not one long list. Run tier 1 before you share any public URL, because a browser-delivered secret does not wait for someone to sign up. Run tier 2 before you expose a paid or metered route or accept a customer payment. Tier 3 is ongoing: the difference between an incident you catch and one a customer has to report. The figures below come from AxonBuild’s fixed June-July 2026 corpus of 26 AI-built app audits; they describe that selected cohort, not every vibe-coded app. A vibe coding security guide will teach you the vulnerability classes; this is the version you run instead of read.

Tier 1: before a public URL or signup (auth, RLS, keys)

These four become relevant as soon as you share a public build. A stranger does not need an account to inspect browser-delivered code, and a public signup lets them exercise authenticated routes.

1. Unauthenticated writes

Grep your route list for anything that mutates or deletes data and confirm it sits behind a real login check, not a secret passed as a URL query parameter. The fail is the write going through from a logged-out private window, a data change with no session anywhere behind it. Unauthenticated routes doing privileged work turned up in 11 of 21 apps.

2. Elevated-privilege database functions

List every database function or route that runs with elevated privileges and check whether it verifies the caller’s identity or just accepts whatever id it’s handed. On Supabase that means Postgres functions marked SECURITY DEFINER plus any route holding the service role key, which Supabase documents as a key that can bypass row level security. The fail is a call carrying another account’s id coming back successful, rows changing in an account that never made the request. Row-level-security gaps sat in 9 of 21 apps, and this variant is the one an RLS policy scan can’t see, because the policies themselves are fine; how to test Supabase RLS covers the policy half.

3. Cross-account data access

Create two accounts, log in as the second, and try to read or edit the first account’s data by changing an ID directly in an API call rather than clicking through the UI. On Firebase the same test runs against your Firebase security rules, which are the access control layer for Firestore, the Realtime Database and Cloud Storage. A row that comes back, or a write that goes through, is the same failure confirmed in 7 of 21 audited apps: a customer reading or editing someone else’s data with a login that worked perfectly.

4. Secrets in browser code

Search the files a browser downloads for confirmed secret values and provider-specific secret formats, then inspect every match. A label or public identifier is not automatically a leaked credential. The fail is a working private key in browser-delivered code; 6 of 21 apps exposed a real secret, and three had one in git history. Private keys belong in your builder’s secrets or environment-variable store, never in a file the client downloads. Rotate a confirmed leak immediately. Removing it from the current file does not remove it from existing history, clones, or caches, even if you later rewrite the repository history.

Tier 2: before paid or metered actions (rate limits, webhooks, entitlement)

The checkout and billing side gets its own posts elsewhere on this blog. These are the compressed checks to run before a public route can spend your provider budget or a customer can pay.

5. Metered API spend caps

Confirm every endpoint that calls an AI model or another metered API enforces its intended access rule and a server-owned usage ceiling. For a private feature, the fail is a real model response to a logged-out request. For an intentionally public feature, the fail is exceeding the documented anonymous allowance or finding no global spend cap. In the fixed cohort, 12 of 14 AI-featured apps had a confirmed path for a stranger or free account to trigger paid AI work without an effective ceiling.

6. Payment webhook signatures

If you use Stripe, confirm the webhook verifies Stripe’s signature before it grants anything. Stripe requires the raw body of the request to perform signature verification, so a framework that parses and re-serializes the body breaks it silently. Send a valid event in test mode, then send a separate request with a missing or invalid signature. The valid event should be processed, and the invalid request should be rejected without changing an entitlement. Other payment providers have their own verification contract. A public webhook URL with no verification lets a forged event claim a payment that never happened, the exact failure 6 ways a vibe-coded checkout leaks money opens with.

7. Entitlement follows cancellation and refund policy

Write down when access should end under your cancellation and refund policy, then test that timestamp. An immediate cancellation should revoke access immediately. An end-of-period cancellation should keep access through the period already paid for, which Stripe documents for cancel_at_period_end. Test refunds according to the policy your product promises. The failure is access changing too early, too late, or not at all, not merely access continuing after any cancellation event. An entitlement that never changes won’t show up on any dashboard, which is how an app ends up giving away paid access for free.

Tier 3: ongoing (dependencies, logging, deploy gates, backups)

None of tier 3 is a one-time pass. Each one gets worse the longer it goes unchecked, and none of the five throws an error to tell you that.

8. Tests that touch checkout

Confirm you have one automated test that actually calls your signup and checkout functions, not a suite that stays green without ever touching them. At least 23 of 26 apps in the fixed cohort had zero working automated tests.

9. Errors that reach you

Break a request on purpose and confirm the failure lands somewhere you’re actually watching. 17 of 21 apps recorded errors nowhere at all, so a real bug and one that got fixed look identical from the outside.

10. A deploy gate that blocks

Put a deploy gate in front of production and include the type checker plus boundary tests that call the important signup, authorization, or checkout paths. The fail is a deliberately broken test or type error that still reaches production. At least 17 of 21 apps had no deploy gate at all, and several had disabled their own type and lint checks at build time.

11. Reachable dependency alerts

Run a dependency audit and trace whether each flagged vulnerability is reachable from running code rather than counting package alerts alone. In 3 of 21 apps the scanner flagged 33 to 44 vulnerabilities and traced zero as reachable; 9 of 26 apps had at least one known critical that was reachable. Prioritize confirmed reachable paths, and record the evidence behind anything classified as not currently reachable. Then check that every package your assistant added actually exists on npm or PyPI under the name and publisher it claims, and that your lockfile is committed. Assistants invent package names often: across 576,000 LLM-generated code samples, one study measured package hallucination at 5.2% for commercial models and 21.7% for open-source models. Someone registering one of those invented names is the attack people call slopsquatting.

12. A restore you have run

Restore from a backup once, on purpose, before you ever need to do it for real. The fail is a restore that errors out, comes back missing tables, or lands hours staler than the dashboard promised. A backup switched “on” does not prove a usable restore, which is the whole argument behind running a restore drill.

A check nobody has ever watched fail is an assumption with a checkbox next to it.

The prompt to paste into your AI builder

Paste this into Lovable, Cursor, Claude Code or whatever assistant has your codebase open. It forces the assistant to report the test it ran rather than an impression of the code.

Act as a security reviewer for this codebase. Work through these 12 checks in
order. For each one, report four lines and nothing else:

CHECK: <name>
TEST: <the exact command, request, or file search you ran>
RESULT: PASS / FAIL / NOT VERIFIED
EVIDENCE: <the file and line, or the response you observed>

Use NOT VERIFIED whenever you cannot run the named test. A source or bundle
search may pass from its search output. For a behavioral check, a code line can
identify a candidate control but cannot prove the behavior. Report PASS only
after you run the behavior and observe the expected response.

1.  Unauthenticated writes: every route that creates, updates or deletes data
    sits behind a real session check, not a secret in a URL parameter.
2.  Elevated-privilege database functions: every SECURITY DEFINER function and
    every route using a service role key verifies the caller's identity instead
    of trusting an id it was handed.
3.  Cross-account data access: every read and write is scoped to the caller's
    account on the server, not by hiding UI controls.
4.  Secrets in browser code: no private key, service role key or API secret
    appears in files the browser downloads, or in git history.
5.  Metered API spend caps: every endpoint that calls a paid model or API has a
    server-side access rule and a usage ceiling.
6.  Payment webhook signatures: the webhook verifies the provider's signature
    against the unmodified raw body before granting anything.
7.  Entitlement follows billing policy: test the promised effective timestamp
    for refunds, immediate cancellations, and end-of-period cancellations.
8.  Tests that touch checkout: at least one automated test calls the real
    signup and checkout functions.
9.  Errors that reach you: server errors are recorded somewhere outside the
    process that failed.
10. A deploy gate that blocks: type checks and tests run before production and
    can fail the deploy. Report any disabled type or lint check.
11. Reachable dependency alerts: every flagged advisory is traced to running
    code, every package exists on its registry under the publisher it claims,
    and the lockfile is committed.
12. A restore you have run: restore into a scratch database and report the
    observed result. Documentation without an executed restore is NOT VERIFIED.

Finish with a list of every check you marked NOT VERIFIED and what you would
need in order to verify it.

A prompt gives you findings to confirm, not a pass. The assistant is grading code it helped write, so treat every PASS as a claim, and re-run the four tier 1 tests by hand.

How these checks map to the OWASP Top 10

The list above is ordered by when a risk arrives, not by category name. If you need the category names for a questionnaire or a customer, here is the mapping against the OWASP Top 10:2025 and, where an AI surface is involved, the OWASP Top 10 for LLM Applications.

When this checklist isn’t enough

Every item above catches a shape the corpus has seen often enough to name and order. A new bug in your specific schema can still sit outside the list, and one pass through the tiers does not replace a deeper attempt to break the important flows. This list goes furthest on authorization, secrets, AI abuse, and deploy hygiene. Full authentication flows and data integrity need more time. For the vulnerability classes behind these checks rather than the tests, read the broader vibe coding security guide. Security is also one of twelve readiness areas in the same corpus; whether your app is actually ready to launch covers the other eleven.

What this list deliberately leaves out

Nine classes commonly covered by broader security checklists are outside this twelve-check priority pass: cross-site scripting, SQL injection, CORS rules, content security policy and other security headers, input validation, password and session controls, file-upload limits, and internal-error leakage. They still require assessment when they apply. Framework and provider defaults can reduce risk, but the app’s configuration and use of each layer decide whether the control holds. Add explicit tests for every applicable class, especially when the app customizes or bypasses the default layer.

Common questions

What should I check before real users can sign up?

Tier 1: confirm anything that mutates data requires a real login, check every database function or route running with elevated privileges, run the two-account cross-tenant test, and search browser-delivered files for a confirmed private secret. Run these before sharing a public URL. Some failures need an account; a client-side secret does not.

What should I check before I take payments?

Tier 2: a server-owned allowance on anything that calls a metered API, signature verification on your payment webhook, and a check that access changes at the timestamp promised by your cancellation or refund policy rather than only updating a ledger. In the fixed cohort, 12 of 14 AI-featured apps had a confirmed path for a stranger or free account to trigger paid AI work without an effective ceiling.

Can I just ask the AI to make my app secure?

Not on its own. An assistant will tell you the code looks secure, which is an impression of the code it can read, not a test result, and it is grading work it helped write. Use the prompt above, which makes it report the test it ran and allows “not verified” as an answer, then re-run the four tier 1 tests by hand.

Is vibe coding safe?

Vibe coding is as safe as the checks you run before you ship. The failures in these 26 audits were not exotic: missing login checks, missing ownership checks, secrets in browser code, and no spend ceiling on paid APIs, all testable in an afternoon. The risk is not the tool writing the code, it is shipping without ever watching a check fail.

How do I keep API keys out of my vibe-coded app?

Keep every private key on the server, in your builder’s secrets or environment-variable store, never in a file the browser downloads. Then verify it: search the built client bundle for the actual secret values and for provider key formats, and search your git history too. If you find a real one, rotate it first, because deleting the line does not remove it from clones, caches or existing history.

What is slopsquatting?

Slopsquatting is when someone registers a package name that AI coding assistants invent, so the next developer who accepts the suggestion installs the attacker’s code. One study of 576,000 LLM-generated code samples measured package hallucination at 5.2% for commercial models and 21.7% for open-source models. The check is cheap: confirm every package your assistant added exists on npm or PyPI under the publisher it claims, and commit your lockfile.

What is the biggest security risk in AI-generated apps?

Broken access control: routes that do privileged work with no login, and routes that trust an account id handed to them by the caller. In the fixed cohort, 11 of 21 third-party apps had an unauthenticated endpoint doing privileged work, 9 of 21 had a row-level-security gap, and 7 of 21 had confirmed cross-account access. It beats secrets and dependencies on both frequency and blast radius.

Is this different from a general security checklist?

Yes. It is grouped by when each risk becomes relevant, with fixed-cohort evidence where a comparable count exists. A general security checklist often assumes a technical team will interpret it. This one names a fail signal for every item so you know what a bad result looks like when you see it.

Do I need tier 3 if I don’t have real users yet?

A working test and a deploy gate are easier to establish before customers and daily workflows depend on the current behavior. At least 23 of 26 apps in the fixed cohort had no working test, and at least 17 of 21 third-party apps plus all five founder-built apps had no deploy gate. Add both while the protected paths and expected outcomes are still small enough to name explicitly.