Vercel security checklist for vibe-coded apps

Vercel makes deployment almost frictionless, which is exactly why a security pass is easy to skip. The app works, the URL is live, and the parts that do not show up in a quick test — how secrets are scoped, which preview URLs are reachable, whether headers are set — go unreviewed. For a vibe-coded app, those are the same gaps an AI builder tends to leave behind.

A quick definition: public exposure means anything reachable without logging in. On Vercel that includes your production URL, every preview deployment URL, and any file that ends up in your public build output.

For the broader pre-launch review across auth, headers, secrets, and more, see the launch security checklist — this Vercel-specific list sits inside that pillar.

Work through each item before launch. Most are quick checks against your live production URL or your project settings.

• Server-only secrets are not given a public/browser-exposed variable prefix.

• Preview deployments do not expose real user data or unfinished admin areas.

• Security headers are present on production responses, and HTTP redirects to HTTPS.

• No source maps, .env, or config files are reachable on your production domain.

• Only the intended production domain is public; stray test domains are removed.

• Environment variables are set in project settings, not committed to the repo.

• You re-checked your production URL after the last configuration change.

Environment variables are where vibe-coded apps most often leak secrets. The rule is simple: a value is either safe for the browser or it is not. Server-only secrets — service keys, private API tokens, database credentials — must never carry a public prefix, because anything exposed to the browser ends up in your frontend bundle for every visitor to read.

• List every variable and mark each as browser-safe or server-only.

• Confirm only browser-safe values use the public prefix (for example NEXT_PUBLIC_).

• Keep service-role and admin keys server-side; never ship them to the client.

• If a server-only secret was ever exposed publicly, rotate it and treat it as compromised.

For the full explanation of how secrets end up public and what to do if one leaked, see public .env files and exposed secrets.

A preview deployment is a live, separately addressable version of your app that Vercel builds for a branch or pull request. These URLs are real and often run against the same backend as production, so an unfinished feature or exposed data on a preview is a real exposure — not a private sandbox.

• Decide whether preview URLs should be publicly reachable at all for your project.

• If previews use production data, restrict who can open them.

• Do not demo admin or debug features on a public preview URL.

• Remember search engines and link scanners can discover shared preview links.

Vercel domains come with HTTPS, but the browser-facing headers that reduce common attacks are something you configure. Configuration and what actually ships can drift, so verify the headers are present on your real production responses.

• Confirm HTTP requests redirect to HTTPS.

• Confirm framing protection so other sites cannot embed your app.

• Confirm content-type and referrer protections are set.

• Check that redirects do not accidentally send users to untrusted destinations.

The HTTP security headers checklist explains what each browser-facing protection helps reduce.

Anything in your public build output is downloadable by anyone. AI-generated projects sometimes leave development files, source maps, or backups where they ship to production.

• Visit yourdomain.com/.env and yourdomain.com/.git — both should return 404.

• Confirm source maps are not served in production if they reveal source detail.

• Remove editor, backup, and temporary files from the public directory.

• Keep secrets out of files that get bundled into the client.

Launch readiness includes knowing exactly what is public. A forgotten staging domain or a leftover test endpoint widens your surface without adding any value.

• Confirm your production domain points to the deployment you expect.

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

• Disable or restrict deployments you no longer want public.

• Publish privacy, terms, and a working contact method on the production site.

GuardMint runs a public, non-invasive scan of your live production URL — the same surface any visitor sees. Our methodology explains how that works.

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

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

• Missing or misconfigured security headers and HTTPS issues.

• Overly permissive CORS and weak cookie flags on public endpoints.

• Error responses that leak internal details.

GuardMint cannot see anything inside your Vercel account. The items below live in your dashboard and project settings, so they are manual review — check them yourself or with a developer.

• Environment variable values and whether each is correctly scoped.

• Which preview and branch deployments exist and who can access them.

• Project-level header, redirect, and access configuration.

• Team membership, deployment protection, and domain settings.

What is a Vercel security checklist?

A Vercel security checklist is a pre-launch review of the configuration choices that affect a Vercel-hosted web app's public security: environment variable scoping, preview deployment visibility, security headers and redirects, and what build output ends up public. It is aimed at founders and vibe coders who deployed quickly and now want a safe launch.

Does GuardMint connect to my Vercel account?

No. GuardMint never connects to your Vercel account or inspects your dashboard. It scans the public surface of your live URL from the outside, the same way any visitor would. Dashboard settings, environment variable values, and project configuration are manual review items you check yourself.

Are Vercel preview deployments a security risk?

They can be. Preview deployments are real, reachable URLs that often run against the same backend and data as production. If a preview exposes real user data or an unfinished admin area, treat it like a production exposure and restrict access.

Which environment variables are safe to expose on Vercel?

Only values you intend the browser to see — typically those prefixed for public use, like a public API URL or a publishable key. Server-only secrets such as service keys and private tokens must stay server-side and must never be given a public prefix.

Can I set security headers on Vercel?

Yes. Headers and redirects can be configured for a Vercel project, and HTTPS is provided by default on Vercel domains. Confirm the headers are actually present on your production responses before launch, since configuration and what ships can drift apart.

Does deploying on Vercel make my app secure by default?

Vercel provides HTTPS and a solid baseline, but it cannot configure your auth, your database rules, or your environment variable scoping for you. Those choices are yours, and they are where most launch risks come from.