Vibe Coding Security: The Production MVP Launch Gate

The verdict: security is a release gate, not a prompt

A vibe-coded MVP is ready only when its critical controls produce repeatable evidence. A security prompt may suggest better code, and a scanner may find familiar vulnerabilities, but neither one proves that the finished product enforces your business rules.

The distinction matters because an application can behave perfectly on its intended path while failing at its trust boundaries. A customer may create a project and invite a colleague, yet still be able to read another company's project by changing an identifier in a request. A payment screen may show success while the browser can set its own paid status. A deleted API key may remain valid in Git history.

Use OWASP ASVS 5.0.0 as the verification baseline, not a generic request to "make this secure." Released on 30 May 2025, ASVS provides a basis for testing web application technical security controls and a list of requirements for secure development. The most current released OWASP risk baseline is also OWASP Top Ten 2025.

If you need a wider product-readiness pass first, use the founder's production launch test. This security gate starts where that broader decision leaves off.

Map the trust boundary before testing code

Start with a trust map, because a scanner cannot infer who should be allowed to do what. A trust boundary is the point where data or control moves between users, roles, systems, or privilege levels.

Take an illustrative research-workspace SaaS. A member can read projects inside one workspace. A workspace owner can invite members and manage billing. A support operator can inspect account metadata but should not read private research. Stripe sends payment events. An AI provider receives selected prompts but should never receive billing records or internal access tokens.

Write that model down before opening the repository:

The important column is not the feature. It is the protected object. "Users can edit projects" is too loose. "A member can update a project only when the project's workspace ID matches an active membership" gives a reviewer something precise to attack.

This exercise usually shrinks the first release. If the workflow needs a complex role matrix that nobody can explain, cut roles from the first version. A simple owner-and-member model with clear boundaries is safer than a half-built permissions designer.

Prove identity and tenant isolation with separate accounts

The highest-value manual test is to make one legitimate user attack another legitimate user's data. Authentication proves who the user is. Authorization decides which records and actions that identity may access.

Create a member in Workspace A, a member in Workspace B, an anonymous browser, and an admin. Give both workspaces similar-looking projects so a lucky response is easy to spot. Then capture requests for each protected operation and substitute the other workspace's record identifier.

For Supabase builds, Row Level Security must always be enabled on tables in an exposed schema, and the default exposed schema is public. Supabase enables RLS by default for tables created in its Table Editor, but not automatically for tables created with raw SQL or the SQL editor. Its production checklist is blunt: tables without RLS enabled with reasonable policies allow any client to access and modify their data. Review the current Supabase RLS guidance against the actual schema, not the intended one.

Set authentication controls deliberately too. Supabase recommends a one-time-password expiry of 3600 seconds (1 hour) or lower, alongside SSL Enforcement, database Network Restrictions, account MFA, email confirmations, and CAPTCHA protection where appropriate. Those controls do not replace authorization tests, but they close common paths around them.

Remove secrets and control every dependency

Treat every generated credential and package as untrusted until the repository proves otherwise. Fast iteration makes it easy to paste a key into a client file, add a package without examining it, or accept a generated fix whose side effects nobody reviews.

If a secret has entered the repository, rotate or revoke it first. Deleting the line is cleanup, not containment. Then scan the repository and its history, because the visible branch is only one copy of the credential.

GitHub secret scanning checks the entire Git history on all branches for hardcoded credentials, including API keys, passwords, tokens, and other known secret types. It also performs periodic rescanning when new secret types are added. Make the scan result part of the release evidence, and keep production secrets in the deployment platform or a dedicated secrets manager rather than in code.

Dependencies need the same discipline. GitHub dependency review shows changes and security impact on every pull request, including additions, removals, updates, release dates, usage, and vulnerability data. Its action fails by default when it discovers vulnerable packages, and a required check can block the merge.

For a Node.js repository with a lock file, use this as a CI floor:

npm audit --audit-level=high

The command changes the minimum vulnerability level that causes CI failure without filtering the report. npm audit exits non-zero by default when it finds any vulnerability, and it requires a package lock or shrinkwrap by default. Do not accept an automatic fix as the proof of safety. The current npm documentation warns that some vulnerabilities cannot be fixed automatically and require manual intervention or review.

For each exception, record the affected package, reachable feature, severity, compensating control, owner, and removal date. "The AI added it" is not an exception. If nobody can explain why a package exists, remove it and rerun the product tests.

Treat payments, webhooks, uploads, and AI calls as hostile edges

Anything arriving from a browser, external service, uploaded file, or model response must earn trust on the server. A hostile edge is a boundary where the application receives data or a claimed event it did not create itself.

For an MVP that sells subscriptions, cut the risky custom work first. Stripe Checkout is a low-code prebuilt payment page that Stripe hosts or that can be embedded, using the Checkout Sessions API. It supports one-time purchases and subscriptions. A Stripe-hosted page keeps the first release focused on entitlement logic rather than a custom card interface.

The browser's success screen must not grant paid access. Grant the entitlement only after the server verifies the payment event. Stripe recommends verifying webhook signatures with its official libraries using the event payload, Stripe-Signature header, and endpoint secret. Its official libraries use a default timestamp tolerance of 5 minutes for replay mitigation.

Use an illustrative subscription flow:

• The browser requests a Checkout Session from an authenticated server route.
• The server attaches the internal account identifier to the payment session.
• The payment provider returns the customer through the interface, but the interface still treats access as pending.
• The server receives the webhook, verifies its signature and timestamp, checks the expected account and product, then writes the entitlement.
• A repeated event returns the existing result instead of granting access twice.

Uploads need a similar gate. Validate the authenticated owner, expected content type, file size, storage path, and downstream parser on the server. Store uploads outside public paths until validation completes. For an AI endpoint, keep the provider credential on the server, authorize the workspace, cap input and output, rate-limit by identity, and log usage without copying sensitive prompt content into general logs.

Make failure observable and reversible

Do not launch a product you cannot diagnose, restore, and hand over. Observability means the logs and signals needed to explain what happened without exposing the sensitive data you are trying to protect.

For each privileged action, log the actor, workspace, action, protected object, outcome, and request identifier. Do not log passwords, raw tokens, payment details, or full private prompts. Confirm that a denied cross-workspace request appears in the right place and that someone knows how to investigate it.

Then rehearse failure with an illustrative launch candidate:

CISA and the FBI recommend prioritizing security throughout the product development process. For a founder, that translates into a simple operating rule: security work belongs in scope, acceptance criteria, deployment, and handoff. It is not a cleanup ticket after launch.

Use the launch, harden, or rescue decision rule

Launch only when critical controls pass; harden when the gaps are local; rescue when the build cannot prove isolation, ownership, or safe change. The label follows the evidence, not how quickly the prototype was made.

A missing RLS policy on one newly added table can be a hardening task when the rest of the schema, tests, and ownership are sound. A client-side admin flag, shared production credentials, unknown database policies, and no reproducible deployment point to rescue. New features only make that second situation harder to inspect.

If you are still choosing a build surface, compare the vibe-coding platform and handoff criteria before committing production data. Tool choice affects the exit path, but it never replaces the security gate.