API keys and secrets: preventing accidental exposure

Identify which values are actually private

Some services deliberately provide publishable browser keys; others provide privileged credentials that must never reach the browser. Use the provider’s documentation to distinguish them. Renaming a private key or placing it in a browser environment variable does not protect it.

Look beyond the source code

Credentials can appear in deployment settings, build output, screenshots, support tickets and logs. Review who can read each location. Use a secret-management facility for private values and keep environments separate so a development compromise does not immediately grant production access.

Reduce the damage a key can do

Give each integration only the permissions it needs and use separate credentials where practical.

• Restrict scope and allowed resources
• Remove credentials for retired integrations
• Keep ownership and expiry information
• Avoid copying secrets into AI prompts or issue trackers
• Monitor unusual usage and costs

If a private key leaks

Revoke or rotate it promptly and update legitimate consumers. Removing the visible value is not enough: it may remain in repository history or copied logs. Investigate usage, assess affected data and follow your incident process. Do not test an exposed credential by posting it to a third-party checker.

Make prevention routine

Use secret detection in development and delivery workflows, but review findings because not every matched string is a private credential. Document how to rotate important integrations and test the procedure before an incident makes it urgent.