Checklists /Cursor or Claude Code, Next.js and Vercel /Security

Critical

Keep secrets out of NEXT_PUBLIC variables

Next.js inlines any NEXT_PUBLIC_ variable into the browser bundle. Cursor and Claude Code often put a server key behind that prefix because the preview then 'works'. Anyone can read it in the built files on Vercel.

How to check

  1. Search the repo for NEXT_PUBLIC_. The values are public. Allowed examples: a site URL, a Stripe publishable key, a Supabase anon key.
  2. Search for sk_live, sk_test, service_role, whsec_, and private keys. None of those strings should be in the repo.
  3. Open a production deployment, load a JavaScript chunk, and search for the secret prefix.
  4. Rotate any key that was exposed. Removing the line does not undo a key that was already downloaded.

Prompt

Fix prompt
Paste into Cursor or Claude Code
You are working in this repository. Do not add features.

Goal: secrets are read only in server code, and no NEXT_PUBLIC_ variable holds a secret.

Steps:
1. Search for NEXT_PUBLIC_ and for key material.
2. Move secret reads into server components, route handlers or server actions. Rename the env vars so they do not start with NEXT_PUBLIC_.
3. If a real secret was committed or shipped, tell me to rotate it. Do not print it.
4. List the env var names Vercel needs, split into public and server-only.
5. Do not change product behaviour except where the client was calling a secret API directly. Move that call to a route handler.

This uses the same ticks as the checklist page, saved in this browser.

Related error fixes