The Vibe-Coded App Security Checklist for Founders

Why do apps built with AI tools need a security check?

Because a generator optimizes for an app that runs, and nothing in "it runs" proves it is safe. Security failures are invisible in a demo and expensive with real users and real data.

Veracode's GenAI Code Security Report tested code from more than 100 large language models across Java, Python, C# and JavaScript and found that 45% of code samples failed its security tests and introduced OWASP Top 10 vulnerabilities. For JavaScript the failure rate was 43%, and for cross-site scripting the tools failed to defend in 86% of relevant samples. Veracode also reported that newer and larger models did not do meaningfully better.

Academic work points the same way. A peer-reviewed paper, "Vibe Coding in Practice", concludes that fast code generation leads to technical debt through architectural inconsistencies, security vulnerabilities and maintenance overhead. It does not tell founders to stop. It tells them to add governance, which is what a checklist is.

Are API keys exposed in my app's browser bundle?

Check 1: anything with a VITE_ or NEXT_PUBLIC_ prefix is shipped to every visitor, so it must never be a secret. Open your deployed site, view the JavaScript in dev tools and search for "key", "secret" and "token".

The frameworks say this plainly. Vite's documentation states that VITE_ variables should not contain sensitive information such as API keys because their values are bundled into your source code at build time. Next.js inlines NEXT_PUBLIC_ variables into the JavaScript sent to the browser. If a payment secret key, an AI provider key or a database service-role key is in that bundle, treat it as already public.

Some keys are meant to be public: a Firebase web config, a Supabase anon or publishable key, a Stripe publishable key. The test is what the key can do. If it can only do what an anonymous visitor should be allowed to do, it is fine. If it can read other people's data, spend your money or send email as you, it belongs on a server. Fix: move the call into a server function, rotate the exposed key, and only then redeploy.

Are my Supabase or Firebase database rules left open?

Check 2: every table needs a rule that says who may read and write it. This is the most common serious finding in published incidents and the first thing to verify.

Supabase's documentation is direct: a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and the guidance is to enable RLS on every such table. It also warns that adding a policy does not remove grants that already exist, so test the result rather than assuming.

For Firebase, the same idea applies to Firestore and Storage rules. Google's getting-started guide shows an allow-everything rule set and warns: never use this rule set in production; it allows anyone to overwrite your entire database. Search your rules file for if true. How to test: sign out, call your own API with the public key from a terminal, and confirm you get nothing back.

Does every endpoint check who is asking, and for what?

Check 3: every endpoint that reads or changes data must verify, on the server, that the caller is logged in and is allowed to touch that specific record. Hiding a button in the interface is not a permission check.

The failure has a name, insecure direct object reference, or IDOR. OWASP ranks broken access control first in its Top 10 and lists permitting viewing or editing someone else's account by providing its unique identifier as a typical example. OWASP's 2021 data found some form of it in 94% of applications tested.

Test it in two minutes. Log in as user A and open an invoice, order or profile. Copy the ID from the URL or the network tab. Log in as user B, then request user A's ID. If it loads, you have an IDOR. Do the same for admin pages and for write actions, not just reads. Fix: look up the record by the logged-in user's ID on the server, never trust an ID sent by the browser, and make admin checks server-side.

Is every input validated on the server?

Check 4: treat everything arriving from a browser as untrusted, and validate type, length and allowed values on the server. Form validation in the interface only helps honest users.

This is where the Veracode cross-site scripting number matters. Untrusted text rendered back onto a page without encoding is how one user ends up running script in another user's session. Check that user-supplied text is escaped when displayed, that database queries use parameters rather than string-built SQL, that uploads are limited by type and size, and that prices, quantities and roles are never accepted from the client as truth. A schema library on every endpoint is a cheap, repeatable fix.

Are secrets sitting in my git history?

Check 5: search your repository history, not just the current files. A key deleted in a later commit is still readable in the earlier one, and generated projects often commit an env file before anyone notices.

GitGuardian's State of Secrets Sprawl 2026 reports 29 million new hardcoded secrets on public GitHub in 2025, up 34% year over year, with leaked secrets tied to Supabase up 992%. The same report found that 64% of secrets leaked in 2022 were still valid. Detection is not the hard part. Rotation is.

GitHub notes that its secret scanning covers your entire Git history on all branches, so turn it on. When it finds something, rotate the credential first. Make sure .env files are in .gitignore before the next commit.

Do my endpoints have rate limits?

Check 6: limit how often one client can call login, signup, password reset, contact forms and anything that costs you money per call, such as an AI model request or an email send.

OWASP's API Security Top 10 observes that it's common to find APIs that do not limit client interactions or resource consumption, and that exploitation can mean denial of service and higher infrastructure costs. For a small product, the realistic version is a bot hammering your signup form or a script running up your AI-provider bill overnight. Put limits at the edge or in middleware, and set a spending cap with every paid provider.

Do my payment webhooks verify their signatures?

Check 7: a webhook endpoint that trusts any POST request lets anyone mark an order as paid. Verify the provider's signature on the raw request body before doing anything.

Stripe's documentation spells out the risk: without verification, an attacker could send fake webhook events to trigger actions like fulfilling orders or granting account access. Stripe signs each event in the Stripe-Signature header, and it needs the raw body for the check, so a framework that parses or reformats the body first will break verification. Use the official library, keep the signing secret server-side, and never use a tolerance of 0. Also confirm that the amount and currency your app records come from the verified event, not from the browser. Test with the provider's CLI, then send a deliberately forged request and confirm it is rejected.

Are my dependencies carrying known vulnerabilities?

Check 8: run your package manager's audit command and turn on automated dependency alerts. A generated project can pull in dozens of packages at once, and nobody on your team chose them deliberately.

Run npm audit (or the equivalent for your stack) and read what it reports rather than running the automatic fix blindly, because major-version bumps can break the app. Remove packages you do not use, pin versions, and confirm the lockfile is committed. Do this on a schedule, not once.

When is a self-run checklist not enough?

When the app holds regulated data, takes meaningful payments, or you cannot explain your own permission model, a checklist is a starting point and a second pair of eyes is cheaper than an incident.

Be honest about the limits of this page. It covers the common, published failure classes. It does not replace threat modeling, an independent penetration test, or legal obligations such as breach notification and privacy rules in your market. It also cannot see your code: a pass on every item here means you removed the known holes, not that none remain. If you found a problem in check 2 or check 3 and real users are on the app, assume exposure, rotate keys and review access logs before anything else.

If the checklist turns up more than you want to fix alone, our Vibe Code Rescue guide walks through the full 10-point triage and the rescue-versus-rebuild decision. The Vibe Coding for Founders hub has the wider context.

FAQ

Keep reading: Vibe Code Rescue, Vibe Coding for Founders, what is vibe coding, and what Claude Code cannot do.