Database credentials are not the same as public keys

Some backends give the browser a deliberately public identifier and enforce access on the server — Supabase anon keys and Firebase web configs work that way.

Others expect the credential to stay on your server. MongoDB Atlas Data API keys, Turso auth tokens, Prisma Accelerate connection strings and search master keys all fall in this group. There is no policy layer behind them that makes publishing them safe.

Two steps, and the order matters. First rotate the credential, because the current one must be assumed public the moment it shipped. Then move it server-side.

Server-side means a route handler, a server component, or a server action — anything that does not get bundled for the browser. Give the front end your own endpoint that returns just the data it needs.

Build the app and search the output for the credential. On Next.js: npm run build, then grep the .next directory. Nothing should match. Also check that the variable name has no NEXT_PUBLIC_, VITE_ or REACT_APP_ prefix — those are public by definition.

Removing the key from the source but not rotating it. Anyone who looked at your bundle already has it, and old deployments may still be reachable. Rotation is the part that actually closes the hole.