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
- Search the repo for NEXT_PUBLIC_. The values are public. Allowed examples: a site URL, a Stripe publishable key, a Supabase anon key.
- Search for sk_live, sk_test, service_role, whsec_, and private keys. None of those strings should be in the repo.
- Open a production deployment, load a JavaScript chunk, and search for the secret prefix.
- Rotate any key that was exposed. Removing the line does not undo a key that was already downloaded.
Prompt
Fix prompt
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.