Vibe coding security: a pre-launch checklist

Why check an AI-built app before launch?

Because you are the one who answers when it leaks. Wikipedia’s summary of vibe coding notes that it may involve accepting AI-generated code without thorough review, and that critics point to a greater risk of security vulnerabilities. The model does not carry that risk for you.

This checklist follows the OWASP Top 10:2025, which OWASP describes as a standard awareness document representing a broad consensus on the most critical web application security risks. It is a starting point for a launch review, not a security audit. If your app handles payments, health data or other people’s private information, get a professional review too.

Can one user read another user’s data?

This is the top category on the OWASP list, Broken Access Control, and its examples include viewing or editing someone else’s account just by changing an identifier in the request.

Test it with two accounts. Log in as user A, copy the URL or API call that loads A’s record, switch to user B’s identifier, and send it. Every read, create, update and delete endpoint should refuse. Ask the agent to list every route and say what check each one performs.

If you use Supabase, its row level security docs say a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that you should enable RLS on every such table. The service_role key bypasses RLS, so it belongs on the server only.

Are any secrets in your code, history or prompts?

The Twelve-Factor App offers a litmus test: could you open-source your codebase right now without exposing a credential? Search the repository and its history for keys and tokens. On GitHub, push protection blocks pushes that contain detected secrets before they reach your repository. For repositories it requires GitHub Secret Protection and is off by default, so check your settings.

Rotate anything exposed. Deleting a commit does not un-leak a key. Treat anything you pasted into a prompt as exposed too.

Are your production settings safe?

OWASP describes Security Misconfiguration as a system, application or cloud service set up incorrectly from a security perspective. In an AI-built app, look for debug mode left on, an admin page with a default password, a storage bucket or database open to the public, and a permissive cross-origin policy on an API that handles logged-in users.

Does login hold up?

OWASP’s Authentication Failures covers cases where an attacker can trick a system into treating an invalid user as a valid one, including automated attacks such as credential stuffing. Use your platform’s hosted login instead of writing your own. Then test the edges: password reset, email verification, session expiry after logout, and what happens after many failed attempts.

Can user input reach a query, a command or a page?

An injection flaw, in OWASP’s words, lets untrusted user input be sent to an interpreter such as a browser or database. See Injection. Ask the agent to find every place input reaches a database query, a shell command or rendered HTML, and to confirm each uses parameters or escaping. Then try a single quote and a <script> tag in every form field.

Do you verify payments and webhooks?

Stripe’s webhook docs recommend verifying signatures with its official libraries, using the event payload, the Stripe-Signature header and the endpoint’s secret, and they warn that verification needs the raw request body. An endpoint that skips this will accept anyone’s fake event.

Do not grant access because a customer landed on a success page. Stripe’s fulfillment guide says you cannot rely on the landing page alone, because there is no guarantee the customer visits it, and that fulfillment must handle being called more than once for the same payment.

What did the agent add to your dependencies?

Read the dependency list in the diff. For each new package: do you need it, is the name exactly right, and is it maintained? OWASP lists Software Supply Chain Failures as its third category. Commit your lockfile, and run npm audit, which asks your registry for a report of known vulnerabilities in your dependencies. In CI, --audit-level sets the minimum severity that makes it fail.

Will you notice when something goes wrong?

OWASP’s logging category says that without logging and monitoring, attacks cannot be detected, and without alerting, responding quickly is very difficult. Log logins, failures, permission denials and payment errors, and never log passwords, tokens or personal data. Show users a plain error message, not a stack trace.

What can the agent itself do on your machine?

It runs commands as you. Keep permission prompts on, or use a sandbox, and do not run in bypass mode on a computer that holds production credentials. Our guide to bypass flags covers the options.

Have you asked for a second pair of eyes?

Claude Code has a security guidance plugin that reviews its own changes for vulnerabilities, and a /security-review command for a pass over your branch. OpenAI offers Codex Security. These are useful, and they are extra readers, not a guarantee.

Make the checklist a step

In SwarmPane, a Workflow chains up to 16 steps. Each result moves to the next agent, approval steps wait for you, and every run is saved. Put this checklist in a review step, and an approval step before anything ships.

SwarmPane runs the agent CLIs and accounts you already have. Start with a 7-day trial for $1 and make the checklist part of the process.