Launch security checklist for vibe-coded apps

This checklist is for founders, vibe coders, and small teams shipping a web app built with AI builders, no-code tools, or AI-generated code — Lovable, Bolt, Cursor, v0, Replit, Claude Code, and similar. These tools produce a working demo quickly, but they rarely review the parts that do not show up in that demo: where secret keys end up, which routes are actually protected, and whether your database is open. You do not need a security background to use it.

Two plain definitions used throughout this page. Public exposure means information or files that are reachable without logging in. Authentication confirms who a user is, while authorization controls what that user is allowed to access.

Go through each item before you share your app publicly. For most, you are confirming a setting is correct — not writing new code. The sections after this one explain each area in more detail.

• No config or secret files are reachable on your live domain (.env, .git, backups).

• Secret keys live on the server, not in your frontend bundle.

• Pages with private data require a logged-in user, and admin routes require an admin.

• Database tables holding real data are not open to anonymous read or write.

• The site is served over HTTPS with a valid certificate.

• Core security headers are present and CORS is not open to all origins on credentialed endpoints.

• Production error pages show generic messages, not stack traces or internal paths.

• Only the production deployment and domain are intended to be public.

• Privacy policy, terms, and a working contact method are published.

• You have re-scanned after fixes to confirm each gap is closed.

Public exposure means files or information reachable without logging in. The most damaging incidents for small apps are rarely sophisticated — they are usually a config file anyone can download or a secret key shipped to the browser.

• Visit yourdomain.com/.env — it should return a 404, not file contents.

• Confirm developer files like .git and editor or backup files are not served publicly.

• Make sure only keys meant for the browser appear in your frontend bundle.

• If a real secret was ever public, rotate it — treat exposed secrets as compromised.

For the full explanation of how this happens and what to do if a key leaked, see public .env files and exposed secrets.

AI builders often render a dashboard that looks protected but is reachable by anyone with the URL. The risk is not just the page — it is the data and actions behind it.

• Open your dashboard or admin URL in a private window while logged out — it should redirect or block, not load.

• Confirm one user cannot view another user's data by changing an ID in the URL.

• Confirm admin actions (delete, edit, export) are not callable by regular users.

• Confirm the database enforces access rules, not just the UI.

If you use Supabase, the Supabase RLS checklist covers the table-open-to-everyone mistake. For login, session, and password-reset specifics, see the authentication security checklist.

Headers tell browsers how to handle your site safely, and your responses should not leak internal detail. AI builders often skip these because the demo works without them.

• Confirm HTTPS is enforced and HTTP redirects to HTTPS.

• Check for framing protection so your app cannot be embedded by other sites.

• Confirm CORS is not set to allow all origins on endpoints that use credentials.

• Check that session cookies use Secure, HttpOnly, and a sensible SameSite setting.

• Trigger a bad URL and confirm the error does not reveal stack traces or file paths.

The HTTP security headers checklist explains which browser-facing protections matter and what each one helps reduce.

How your app is deployed can expose it even when the code is fine. Preview URLs, leftover build output, and stray test deployments are common culprits.

• Confirm only the production deployment and domain are meant to be public.

• Make sure preview or staging URLs do not expose real user data.

• Remove or protect test, debug, and seed endpoints before launch.

• Confirm environment variables are set on the platform, not committed to the repo.

On Vercel specifically, the Vercel security checklist walks through environment variables, preview deployments, and deployment hygiene.

GuardMint runs a public, non-invasive scan of your live app and reports launch-readiness risks. It looks at what any visitor could reach, without logging in and without touching your code or dashboards. Our methodology explains how the scan works.

• Exposed files like .env, .git, and source maps reachable on your domain.

• Secret-looking keys and tokens visible in your frontend bundle.

• Missing or misconfigured security headers and HTTPS issues.

• Overly permissive CORS and weak cookie flags.

• Error responses that leak internal details.

A scan sees what is publicly reachable. The items below depend on access rules, admin permissions, or code logic that no external scan can confirm — review them yourself or with a developer.

• Whether your authentication and authorization rules are actually correct.

• Whether database policies block access to other users' records.

• Whether admin and role-based access is enforced for every sensitive action.

• Whether payment, billing, and other business logic behaves safely.

• Settings inside your hosting or database dashboard that are not visible publicly.

What is a launch security checklist?

A launch security checklist is a short, pre-launch review of the public-facing risks that commonly affect web apps before they go live: exposed files and secrets, weak authentication, missing browser protections, and platform misconfiguration. For vibe-coded apps it focuses on the gaps AI builders leave behind, because those tools optimize for a working demo rather than a safe launch.

Do I need to be a developer to use this checklist?

No. Each item describes what to check and why it matters in plain language, and most fixes are settings in your hosting or database dashboard. For anything involving access rules or business logic, ask a developer to review it before launch.

Does passing this checklist mean my app is secure?

No. The checklist covers the most common launch-blocking mistakes, not every possible risk. It cannot verify that your authentication, authorization, or payment logic is correct. Treat it as a strong baseline, not a guarantee or a certification.

How is this different from a penetration test?

A penetration test is a manual, in-depth assessment by a security professional, often including authenticated testing. This checklist and the GuardMint scan are an automated, non-invasive review of your public surface. They are faster and cheaper, but they do not replace a penetration test for high-risk apps.

When should I run through this checklist?

Run through it before your first public launch, and again after any change that touches authentication, your database, environment variables, or deployment configuration. Re-scan after fixes to confirm each finding is closed.

Can GuardMint check everything on this list automatically?

No. GuardMint checks the items that are visible from the public internet — exposed files, secrets in your frontend, headers, HTTPS, CORS, cookie flags, and error leakage. Items that depend on access rules, admin permissions, or code logic still need manual or developer review.