An API key, access token, or private signing key can authorize actions as your account. Treat it as a credential: do not paste a live value into a public prompt, commit it to source control, or ship it to browser code unless the service explicitly designed it to be public and restricted.
Separate credentials from examples
When asking an AI assistant for help, replace real values with obvious placeholders such as YOUR_API_KEY. Remove secrets from terminal output, screenshots, logs, and copied configuration too. A prompt can include more context than the code snippet you intended to share.
Keep server credentials in a server-side secret store or deployment environment. In Next.js, variables prefixed with NEXT_PUBLIC_ are inlined for browser use; they are not a safe place for private credentials. A .env file should be excluded from Git, but ignoring a file does not remove a secret that was already committed or printed elsewhere.
Generate and store a secret safely
Use the provider’s credential creation flow or a cryptographically secure generator suited to the required format. The Toolsnix Secure Key Generator can create random strings for compatible use cases, but check the target service’s allowed character set and length. A generated string is not automatically a valid API credential; the service usually has to issue or register it.
Store the value in a secret manager or deployment environment, limit its permissions, and use separate credentials for development and production. Do not reuse one credential across unrelated projects.
If a secret reaches a prompt or repository
Assume a live credential is exposed if it entered a service or repository you do not fully control. Revoke or rotate it with the provider first, review its recent use, and update every legitimate consumer. Removing the value from the latest file is not enough: it may remain in Git history, logs, caches, or provider records. Follow the provider’s incident process before rewriting history, since that can disrupt collaborators.
FAQ
Are environment variables always private?
No. Server-only variables can stay server-side when handled correctly, but public prefixes and client-side code expose values to site visitors. Verify how the framework handles each variable.
Is a public identifier a secret?
Not always. Some services issue publishable keys intended for client use with restrictions. Read the provider’s documentation and never assume that a string is public just because it appears in a sample.
Does deleting a committed key fix the leak?
No. Revoke or rotate it first. Deletion does not invalidate the credential or guarantee removal from every copy.