Keeping a secret out of the browser is only the first step. Production API-key safety also depends on scope, rotation, storage, logging and incident response.
Some client configuration values identify a project but are designed to be visible in a browser. Other credentials authorize privileged actions and must remain server-side. Treat every credential according to what possession of that credential allows an attacker to do.
Payment secret keys, database passwords, signing secrets and private service credentials belong in server environment variables or a dedicated secret store. They should not be committed to a repository, embedded in JavaScript, written into support tickets or copied into analytics.
Use the narrowest permissions the provider allows. Separate production and development credentials, restrict origins or IP addresses where the provider supports it, and avoid sharing one powerful credential across unrelated systems.
When a service supports multiple keys, give each application or integration its own credential. That makes rotation safer and helps you identify which integration generated suspicious traffic.
Authorization headers, cookies, signed URLs and request bodies can all contain credentials. Redact sensitive headers before storing HTTP traces and avoid logging full environment variables. Debugging tools should mask common secret patterns before data is saved or shared.
Rotation should be a documented operating procedure, not a panic response invented during an incident. Know where a credential is used, how to deploy a replacement without downtime and how to revoke the previous key once the new value is active.
If a privileged key is published, assume it may have been copied. Rotate it, review provider logs, inspect unusual transactions or requests, and document the exposure path so the same leak is less likely to happen again.