Where should API keys live, and what if one leaks?

Direct answer

A private API key authorizes service use. Read it from protected server-side configuration, never frontend code, a public repository, or ordinary chat. Next.js documentation explains that NEXT_PUBLIC_ values can enter browser code, making that prefix suitable for public configuration, not private keys. Environment variables are a configuration mechanism, not complete protection: returning a secret in a response or printing it in logs still exposes it. Obtain your own credentials through a supported, authorized provider flow rather than asking AI to reveal internal sandbox credentials.

When to use

• You are connecting a model, database, object store, or mail service.
• Local use works but deployment reports missing configuration.
• A key appeared in code, a screenshot, logs, or Git history.

Step by step

Inventory configuration and classify public versus private

Record names, purposes, and owning services without real values in requirements. Public site keys or site IDs differ from private secret keys and database passwords. Separate development, test, and production according to actual needs, and grant only required permissions.

Configure authorized credentials in the right environment

Follow framework conventions locally; Next.js environment files belong at the project root rather than inside src. Configure each deployment environment on its hosting platform instead of assuming local files upload automatically. Restart or redeploy as required and verify the real feature afterward.

Have browsers call a protected application endpoint

The server validates input, identity, and quota before reading the key and calling the provider. Return only the necessary business result, not the entire upstream configuration. An unprotected server proxy can still let others consume your API budget.

Inspect common exposure locations

Check staged files, history, browser builds, requests, logs, and screenshots. Ignore rules can prevent later additions but cannot erase committed history. Share variable names, request IDs, and redacted excerpts for debugging instead of a complete environment dump.

Invalidate the exposed credential first

On confirmed or evidence-based suspected exposure, follow provider procedures to revoke the old credential, create a suitably scoped replacement, update actual environments, and verify. Then inspect usage and billing and clean exposed locations. Coordinate with collaborators and preserve work before rewriting Git history; force-pushing is not a universal first response.

Worked example

Hypothetical exercise: renaming a key does not repair exposure

A page previously referenced NEXT_PUBLIC_MODEL_KEY. A developer later renamed it MODEL_KEY and removed the value from code, but old web bundles or commits may still contain a usable credential. Revoke the old key, configure a new server-only key, inspect authentication and limits on the calling endpoint, and verify that browser code and responses contain no replacement secret.

Action checklist

• Private and public configuration are separated.
• Browser bundles, responses, and logs contain no private credentials.
• Local, preview, and production environments are configured separately and correctly.
• Private-call entry points enforce necessary permission and quota checks.
• Exposed credentials are invalid and replacements have been verified through real calls.

Reusable templates

Credential configuration checklist

Working template
Variable name: [never the real value]
Service and purpose: [description]
Public or private: [choose]
Environment: [local / preview / production]
Read location: [server file or platform configuration]
Least privilege: [required operations]
Verification: [real feature and redacted diagnostics]
Rotation impact: [environments needing updates]
Report presence and appropriate permissions only, never the credential itself.

Pitfalls

• A value in .env still needs protection from Git, deployment mistakes, logging, and response leakage.
• Adding NEXT_PUBLIC_ so a browser can read a key publishes the secret.
• Cleaning history before revocation does not invalidate a credential somebody already copied.

Related guides

• Is working login enough? How do I keep each user’s data private?
• How do I verify that an AI API can do my job rather than just a demo?
• How do I deploy a local website, and why is a successful build not enough?

Official references

• Next.js: Environment Variables — Documents browser inlining of public values, local file location, and values fixed at build time. Recorded reference review date: 2026-10-18.

• OWASP: Secrets Management — Discusses least privilege, secret lifecycles, and revocation after exposure. Recorded reference review date: 2026-10-18.