Vibe Coded App Security Checklist: What to Check Before Launch

A vibe coded app security checklist should block launch until you have proved that secrets stay server-side, every private record has server-enforced access control, untrusted input cannot become code, and production settings are actually deployed. Start with authorization and data exposure because a polished interface, a passing build and a security header score cannot prove that one user is unable to read or change another user's data (OWASP Authorization Cheat Sheet and OWASP Input Validation Cheat Sheet, checked 18 Oct 2026).

Disclosure: ZeroRaised is a launch and discovery site for bootstrapped indie makers who have taken no institutional VC or accelerator equity, and it publishes this guide. This is an editorial checklist, not a security certification, legal opinion or substitute for a review matched to your product's risk.

TL;DR#

Do not interpret “stop the launch” as “delete the project.” It means fix or deliberately remove the affected feature, repeat the test, and keep evidence of the result. If the app handles payments, health information, sensitive identity data, children’s data, high-value accounts or access to other systems, get specialist security and legal help before release.

Why this vibe coded app security checklist matters now#

Dated note, 17 Oct 2026: ShipSniffer operator Jake Cyr posted a Hacker News submission linking to his passive scan of 155 Show HN URLs associated with tools or descriptions such as Lovable, Bolt, Replit, v0, Cursor and “vibe coded.” Cyr reports that 99 were reachable and scannable. Among those 99, his scan found one app exposing a secret key, 91% without a Content Security Policy, 88% without the tested framing protection and 37% exposing a Supabase anon key (ShipSniffer research, checked 18 Oct 2026).

Those numbers need careful reading. Cyr says the work used public GET requests and static inspection, did not log in, query databases or exploit apps, and can produce false positives and negatives. A Supabase anon key is also designed to be public, so its presence is not evidence of a leak. The security question is whether grants and Row Level Security restrict what that public client can do (ShipSniffer method and Supabase API keys, checked 18 Oct 2026).

The report is therefore a useful prompt, not a verdict on all AI-assisted software. Generated code changes how quickly a maker can assemble unfamiliar components, but the release question stays conventional: who can do what, to which data, through which path, with which credential? This checklist turns that question into tests a maker can run before submitting a product to ZeroRaised, applying for maker perks, or using the broader product launch checklist.

Start by drawing the real trust boundary#

Before fixing individual findings, write down the production path. Include the browser or mobile client, server functions, database, object storage, authentication provider, payment processor, email service, AI provider, analytics, webhooks and any tool allowed to fetch a user-supplied URL. If the AI builder created a proxy, background job or edge function, include it even if you did not ask for it explicitly.

For each component, answer four questions:

1. What untrusted data enters here?
2. Which identity or credential does it use?
3. What data or action can that identity reach?
4. Where do failures, tokens and personal data get logged?

This is editorial procedure, but it follows OWASP's separation of authentication, session management and authorization. Authentication establishes identity; authorization decides whether that identity may perform a specific operation; a session carries the authenticated state between requests (OWASP Authentication and OWASP Session Management, checked 18 Oct 2026).

Compare public values with privileged secrets#

“Visible in DevTools” is not a complete secret test. Some identifiers and client keys are intended to be shipped, while others grant privileged access.

The key classifications come from Supabase's API key guide and Stripe's API key guide, both checked 18 Oct 2026. Do not paste an unfamiliar value into a public-code allowlist just because its name contains “public.” Confirm the issuer's current documentation and the exact permissions in your own account.

Vibe coded app security checklist step 1: remove and rotate exposed secrets#

Search more than the current source files. Check the full Git history, generated client bundles, source maps, build output, hosting settings, logs, screenshots, issue text, sample configuration, copied AI chats and downloadable files. GitHub says its secret scanning covers Git history on all branches and also scans locations such as issues, pull requests, discussions, wikis and secret gists; an alert should lead to credential rotation, not merely deletion of the visible string (GitHub secret scanning, checked 18 Oct 2026).

Use this sequence when you find a real secret:

1. Disable, expire or rotate it at the issuing service.
2. Review provider logs and the secret's permissions for unauthorized use.
3. Replace it in the server-side secret store and redeploy every component that needs it.
4. Remove it from code, public artifacts and logs.
5. Add a preventive control so the same pattern cannot be pushed again.

Deleting a secret from the latest commit does not make the credential safe because older Git history may still contain it. GitHub's guidance says to rotate the affected credential immediately; its push protection can block recognized secrets before a push reaches a repository (GitHub secret scanning and push protection, checked 18 Oct 2026).

Environment variables are a delivery mechanism, not an automatic security boundary. For example, Vercel says its variables are configured outside source code, changes apply only to new deployments, and local values may be written to a plain-text .env file. Confirm that secret values are marked as secrets, exposed only to the intended environment and redeployed after rotation (Vercel environment variables, checked 18 Oct 2026).

Also inspect naming conventions that deliberately expose variables to the browser. Many frameworks copy specially prefixed values into client bundles at build time. The safe test is empirical: build the production app, search its output for privileged values and inspect network requests in a signed-out browser. Never put a privileged key in client-visible configuration and assume an interface hides it.

Step 2: prove database, storage and API authorization#

Authorization is not the same as hiding a button. Open the browser's network panel, copy the request behind each sensitive action, and repeat it outside the interface. Change the object identifier, organization identifier, owner field and role field. The server must derive the caller's identity from a validated session or token and make an authorization decision for the requested object and action.

OWASP recommends least privilege, denial by default, permission checks on every request and tests for authorization logic. Its REST guidance likewise says each endpoint should check whether the caller may perform the requested operation (OWASP Authorization and REST Security, checked 18 Oct 2026).

Build a small access matrix using your real roles and real resources. Do not invent a generic “user” test if the product actually has owners, members, support staff and signed-out visitors.

This matrix is a test template, not a universal role model. Replace the labels with the identities your app really uses. Run the checks for reads, lists, searches, creates, edits, deletes, exports, file downloads and background jobs. A protected detail endpoint can still leak data through an unfiltered list, autocomplete result, CSV export, storage URL or error message.

Supabase: test grants and RLS together#

Supabase documents two database checks: table grants decide whether a role may perform an operation at all, and RLS policies decide which rows the operation may affect. It advises setting both for every exposed table. Its secret and legacy service_role keys bypass RLS, so a server route using either key must perform its own authorization before querying data (Supabase RLS and Supabase API keys, checked 18 Oct 2026).

For each table and storage bucket reached by a public client:

• List the allowed operations for signed-out and signed-in roles.
• Enable RLS and remove grants the role does not need.
• Write separate policies for the allowed operations and ownership rules.
• Test the policy with the intended user's token, another user's token and no user token.
• Repeat the test after a schema change or a new table is generated.

Do not treat a policy that returns rows as proof that it is narrow enough. Inspect which rows it returns. A permissive condition can make a test “work” while giving every authenticated account the same access.

Firebase: test every matching path#

Firebase says Security Rules sit between clients and data for Cloud Firestore, Realtime Database and Cloud Storage. Matching rules are evaluated with OR behavior, so a broad rule that allows access cannot be narrowed by a more specific matching rule. Firebase recommends testing rules with its emulators before deployment (Firebase Security Rules, checked 18 Oct 2026).

Run the same identity matrix against each collection, document path and storage path. Watch for rules copied from a prototype, time-limited test mode, broad authenticated access and mismatches between database and storage rules. Test queries as well as individual records because Firestore rules are not filters; design the query so it can be proven to return only authorized documents, following the product's current query security guidance, checked 18 Oct 2026.

Step 3: verify authentication, recovery and session boundaries#

Use the authentication provider's maintained SDK and server validation path instead of asking generated code to design a password system or token format. Then test the whole lifecycle: sign-up, verification, login, logout, password or magic-link recovery, email change, role change, account deletion and session expiry.

The session token is temporarily equivalent to the authentication that created it. OWASP warns that disclosure, prediction, capture or fixation of a session identifier can lead to session hijacking. It recommends secure session handling and describes Secure, HttpOnly and SameSite cookie attributes as controls with different purposes (OWASP Session Management, checked 18 Oct 2026).

Your manual release tests should cover:

• Logging out in one browser and confirming that the old session cannot keep using protected API routes.
• Removing a user from an organization and confirming that existing tabs and tokens lose the removed access.
• Changing an account email or password and verifying the intended session-revocation behavior.
• Opening a recovery link more than once and after its expiration.
• Attempting login and recovery with an existing and nonexistent account, then comparing the public response for unintended account discovery.
• Requiring stronger protection for administrator and support accounts, including multi-factor authentication where the provider supports it.

For destructive or high-impact operations, require a fresh authorization decision. The user interface may show a confirmation, but the server still needs to verify the actor and permission. OWASP recommends reauthentication after risk events such as account recovery, suspicious behavior or critical account changes (OWASP Authentication, checked 18 Oct 2026).

If your app authenticates with cookies, add CSRF protection to state-changing requests. OWASP recommends using built-in framework protection where available, otherwise validating CSRF tokens on the backend, with the exact pattern chosen for the application's state model. It also notes that SameSite is a defense-in-depth control rather than a replacement for CSRF tokens where tokens are needed (OWASP CSRF Prevention, checked 18 Oct 2026).

Vibe coded app security checklist step 4: constrain every input and output#

Treat route parameters, JSON bodies, form fields, headers, cookies, uploaded filenames, webhook payloads and model output as untrusted. Client validation improves the interface, but the server must repeat the security-relevant checks because a caller can skip the interface.

OWASP separates syntax validation from semantic validation. A value can be a valid integer yet still be an invalid quantity, price, owner or date for the operation. It recommends defining accepted types, formats, ranges, lengths, fields and array sizes, rejecting unknown or invalid input, and using parameterized queries and context-aware output handling as separate injection defenses (OWASP Input Validation, checked 18 Oct 2026).

Review generated endpoints for these recurring mistakes:

• A request body is passed directly into an ORM create or update operation, allowing fields such as role, ownerId, price or isAdmin to be set by the caller.
• A record ID is validated for format but not checked against the caller's ownership or organization.
• A SQL statement, shell command, template or file path is built by string concatenation.
• A URL from the user is fetched by the server without restricting protocols, destinations, redirects or response size.
• A model response is inserted into HTML or used as a command without being validated for that destination.

For XSS, keep framework escaping enabled and avoid escape hatches that render raw HTML. OWASP specifically calls out React's dangerouslySetInnerHTML as unsafe without sanitization and explains that output encoding must match the HTML, attribute, JavaScript, CSS or URL context (OWASP XSS Prevention, checked 18 Oct 2026).

For a feature that fetches a URL, such as link previews, imports, webhooks or image proxies, treat server-side request forgery as part of the design. OWASP describes SSRF as abusing the application to reach external services, internal services or the host itself. Prefer a strict allowlist when the business flow has known destinations, and add network-layer controls as defense in depth (OWASP SSRF Prevention, checked 18 Oct 2026).

Step 5: set browser security headers deliberately#

Headers do not repair broken authorization or unsafe rendering. They reduce particular browser-side risks and make assumptions explicit. Configure them at the actual production edge, then inspect the response from the public URL rather than trusting a local configuration file.

These effects and cautions come from the OWASP HTTP Headers Cheat Sheet, checked 18 Oct 2026. A copied CSP can silently allow too much or break authentication, payments, analytics and media. Build it from observed requirements, test it, and treat each new third-party origin as a security and privacy decision.

CORS is not authentication. It tells browsers which origins may read a cross-origin response; it does not stop scripts, servers or command-line clients from sending requests. OWASP recommends specific allowed origins instead of * unless a resource is intentionally public to every origin (OWASP HTTP Headers, checked 18 Oct 2026). Regardless of CORS, protected endpoints must authenticate and authorize the caller.

Step 6: authenticate webhooks and make side effects repeat-safe#

A webhook endpoint is a public route by design. Do not trust a request because its JSON resembles the provider's event. Verify the provider's signature over the exact raw request body before parsing or acting, reject invalid signatures, and keep the signing secret on the server.

Stripe's current guidance requires the raw request body, the Stripe-Signature header and the endpoint's signing secret for verification. It also advises guarding against processing the same event twice because automatic retries and recovery work can deliver an event more than once (Stripe webhook signature guidance, checked 18 Oct 2026).

Apply the provider's own verification method to every integration, then test these paths:

• a valid event;
• an invalid signature;
• the same valid event delivered again;
• an event delivered out of the order your interface usually creates;
• a valid event referring to an object your system does not know;
• an event handler that fails after starting work but before returning success.

Store a provider event identifier or another stable idempotency key before performing an irreversible side effect. Fetch critical state from the provider when its documentation recommends doing so, and verify that the referenced customer, account or order belongs to the expected tenant. A valid signature proves the provider sent the event; it does not prove that your app has mapped the event to the correct local user.

Use the same thinking for expensive AI, email, export and image-processing routes. Authenticate the caller, authorize the resource, validate request size and shape, and constrain repeated work. The exact limits should come from the product's real workload, provider quotas and abuse model, not a copied number from another app.

Step 7: restrict uploads and generated files#

If users can upload an avatar, document, archive or media file, the file is untrusted even when its extension looks familiar. OWASP recommends an allowlist of business-required extensions, independent file-type validation, generated filenames, size limits, authorization, storage outside the webroot where possible and CSRF protection. It explicitly warns that the request's Content-Type can be spoofed (OWASP File Upload, checked 18 Oct 2026).

Test the full storage lifecycle:

• Can a user overwrite another user's object by choosing a path or filename?
• Does a private upload receive a public, durable URL?
• Can an HTML or SVG upload execute active content in your origin?
• Does image or document processing run with unnecessary network, file-system or cloud permissions?
• Are deleted account files actually removed according to the product's stated retention behavior?

Generated downloads need the same review. CSV exports can disclose fields omitted from the interface. PDF renderers and screenshot services may fetch attacker-controlled URLs. Archive extraction can overwrite paths if names are trusted. Keep the allowed format narrow, isolate processors and authorize every source object before building the output.

Step 8: review dependencies and third-party code#

An AI builder can choose packages, versions and copied snippets faster than a maker can evaluate them. Before release, list direct production dependencies, remove packages the app no longer uses, commit the appropriate lockfile, and review install scripts and packages that receive sensitive data or run in privileged build contexts.

Enable the package ecosystem's maintained vulnerability checks and GitHub's dependency graph where applicable. GitHub says Dependabot alerts are triggered when a reviewed advisory affects the default branch's dependency graph or that graph changes. It also cautions that alerts cannot catch every security issue and that new vulnerabilities may take time to appear (GitHub Dependabot alerts, checked 18 Oct 2026).

Do not merge an automated upgrade only because the alert disappears. Read the advisory and release notes, confirm that the affected code path exists, test the upgrade and check for breaking security defaults. A removed alert is evidence that a known dependency condition changed, not proof that the application is secure.

Apply least privilege to third-party scripts too. A script running on your page can interact with what the page exposes. Remove unused analytics, chat widgets, copied CDN scripts and abandoned experiments. Make each remaining origin visible in the CSP and document why the product needs it.

Step 9: log security events without logging secrets#

You need enough evidence to investigate a report, but collecting every request body creates another sensitive data store. Log authentication outcomes, authorization failures, privilege changes, credential rotations, webhook verification failures, important exports and destructive actions with a time, actor, target, result and request correlation identifier appropriate to your system.

OWASP says application logging should cover security events and that application code has context such as identity, roles, permissions, target, action and outcome that infrastructure logs may lack. Its guidance also says secrets, session identifiers, access tokens and sensitive personal data should not normally be recorded directly (OWASP Logging Cheat Sheet, checked 18 Oct 2026).

Trigger an alert you expect to matter and prove that someone can receive and understand it. Then provoke a handled error and inspect the public response. Users should get a useful but non-sensitive message; stack traces, SQL, filesystem paths, tokens and internal service details belong neither in the browser nor a public server response.

Keep the logs themselves access-controlled, protected from tampering and retained only as long as the documented operational or legal purpose requires. If a support tool can search user events, include that tool and its operators in the authorization review.

Step 10: prepare recovery before the public URL spreads#

Write the first actions for a leaked key, exposed table, compromised administrator, forged payment state and destructive data change. Record where to revoke each credential, who controls the domain and hosting account, how to disable a risky feature, how to contact affected vendors and how to communicate with users if required.

OWASP's secrets guidance recommends centralizing and standardizing secret handling, applying least privilege and supporting rotation rather than relying on manual access to shared credentials (OWASP Secrets Management, checked 18 Oct 2026). Test one non-production rotation so the runbook reflects the real provider and deployment path.

Backups require a restore test. Confirm what the database or hosting provider backs up, what it excludes, how encryption and access work, and whether the restore lands in an isolated environment. Do not make a universal recovery-time promise unless you have measured your own process.

Protect the control plane as seriously as the app. Use multi-factor authentication where available for the domain registrar, source host, deployment platform, database, payment provider and primary email account. Remove stale collaborators and tokens. If one personal email controls every recovery path, document that concentration of risk and add an appropriate recovery method.

Run the vibe coded app security checklist against production#

Preview and production environments differ. Environment variables, domains, cookies, redirect URLs, headers, database projects, storage rules and third-party webhook secrets can all change at deployment. Vercel, for example, states that environment-variable changes apply only to new deployments and distinguishes production, preview and development scopes (Vercel environment variables, checked 18 Oct 2026).

Use a fresh browser profile and test the deployed URL in this order:

1. Inspect the production HTML, JavaScript bundles, source maps and network requests for privileged credentials.
2. Confirm HTTPS, headers, cookies, CORS and authentication redirects on the public domain.
3. Repeat the access matrix as signed out, the resource owner, a different user and each real privileged role.
4. Test create, read, update, delete, search, export and file-download paths rather than only the main interface.
5. Send invalid and duplicate webhook events through the provider's supported test path.
6. Upload allowed and disallowed files, then verify storage access and deletion.
7. Trigger a dependency scan, a failed login, an authorization denial and a handled server error; inspect alerts, logs and public messages.
8. Verify that credential rotation, feature shutdown and data restore instructions identify current owners and current provider controls.

Record each item as pass, fail, not applicable or accepted risk, with a link to the test or configuration. “Not applicable” needs a reason. An accepted risk needs an owner and a concrete condition for revisiting it. This record is editorial advice, not a certification, but it prevents “the AI said it was secure” from becoming the only evidence behind a release.

What an automated scan can and cannot establish#

An external scanner can observe public headers, assets, exposed files and some secret patterns. A source scanner can find known patterns and risky code. Neither can reliably infer every tenant rule, business invariant, recovery path or protected action without the right access and context.

Jake Cyr makes that limitation explicit in ShipSniffer's terms: its automated reports may contain false positives and false negatives, and a good score does not mean an app is secure (ShipSniffer terms, checked 18 Oct 2026). Use scanners to widen coverage and catch regressions, then verify each finding and keep manual authorization tests in the release gate.

Only scan systems and code you own or are explicitly authorized to test. Cyr's terms apply that boundary to ShipSniffer, and the same rule should govern any scanner you choose (ShipSniffer terms, checked 18 Oct 2026).

When this checklist is not enough#

Get a qualified security review when a failure could expose sensitive or regulated data, move money, harm a user, compromise another system, or create a risk your team cannot confidently evaluate. Ask the reviewer to cover the deployed architecture, authorization model, source and configuration, not just the homepage.

Also review the contracts and security documentation of services that store or process your users' data. This article does not determine whether a product meets a law, regulation, customer requirement or security standard. The right scope depends on the data, users, jurisdictions, integrations and promised controls.

After the release gate passes, keep security separate from promotion. Use the guide to launching a bootstrapped app for release sequencing and the Show HN writing guide if that community fits the product. A launch plan answers where and how to present the app; this checklist answers whether its current production surface is ready to be exposed to unfamiliar users.

A release decision you can defend#

The useful outcome is not a perfect score. It is evidence that privileged credentials are controlled, access decisions are enforced outside the interface, untrusted data is constrained, integrations authenticate their requests, browser controls are intentional, known dependency issues are handled, and recovery is possible.

Generated code can be rewritten quickly, which is an advantage when a test fails. Keep the failed test, fix the narrow cause, rerun the surrounding paths and record the new result. Then submit the product through ZeroRaised's launch form only when the release owner can explain what was tested, what remains and who will respond if production behaves differently.

When authentication design is still open, use the passkeys vs passwords guide to choose a rollout and test its recovery path.

Sources#

• Jake Cyr's ShipSniffer research, its Hacker News submission and ShipSniffer terms, checked 18 Oct 2026
• OWASP Cheat Sheet Series, including authorization, authentication, sessions, secrets, headers, validation, XSS, CSRF, SSRF, file upload, REST and logging guidance, checked 18 Oct 2026
• GitHub secret scanning, push protection and Dependabot alerts, checked 18 Oct 2026
• Supabase API keys and Row Level Security, checked 18 Oct 2026
• Firebase Security Rules and secure queries, checked 18 Oct 2026
• Stripe API keys and webhook signature guidance, checked 18 Oct 2026
• Vercel environment variables, checked 18 Oct 2026