Where should API secrets and tokens be stored, and what mistakes would you avoid?

Protect secrets and tokens in API systems

Explains where secrets and tokens should live, what not to log, how rotation works, and how client storage changes risk.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Server-side secrets like signing keys, database passwords, and API keys should live in a secret manager or protected environment configuration, not in source control. Tokens should be treated as credentials. The API should not log bearer tokens, refresh tokens, reset tokens, or secret values. If a token must be stored server-side, store a hash or opaque identifier when possible.

Full answer below

Practice focus

Secret managers, environment boundaries, token storage, logging redaction, rotation, client storage, and incident response.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Secrets and tokens move through many layers: config, logs, browser storage, databases, support tools, and deployment systems.
Server-side secrets like signing keys, database passwords, and API keys should live in a secret manager or protected environment configuration, not in source control. Tokens should be treated as credentials. The API should not log bearer tokens, refresh tokens, reset tokens, or secret values. If a token must be stored server-side, store a hash or opaque identifier when possible.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For browser clients, storage choice changes the threat model. Tokens in JavaScript-accessible storage are exposed to XSS. Cookies can reduce JavaScript theft when HttpOnly is used, but they bring CSRF and SameSite decisions. Refresh tokens deserve stronger protection than short-lived access tokens. Rotation and revocation need to be designed before an incident, not after a secret leaks.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Committing secrets to source control.
Logging Authorization headers or reset links.
Showing full API keys repeatedly in admin screens.
No rotation or revocation plan.

Where should API secrets and tokens be stored, and what mistakes would you avoid?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant

Tech stacks

Skill areas

Suggest an improvement