Concept questionMedium~7 minAPI Security & Auth Essentials / 16 of 20

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would define ownership and rotation for every secret. Deployments need a safe way to roll keys without downtime, and logs need redaction rules. Support/admin tools should never display full secrets after creation. Incident response should answer which users or clients are affected, how to revoke credentials, and how to verify the new secret is in use. Good secret handling is mostly about boring discipline across all the places secrets might accidentally appear.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain token storage trade-offs.
No secret manager or protected config boundary.
No redaction in logs.
No incident response path after credential leakage.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why store only a hash of an API key?
How would you rotate a signing key?
What token storage risks differ between cookies and localStorage?

Continue the section

Next in API Security & Auth Essentials: Headers and TLS

Step 17 of 20

Use security headers, TLS, and cookie flags correctly

Opening drill

Concept questionMedium~7 minAPI Security & Auth Essentials / 16 of 20

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would define ownership and rotation for every secret. Deployments need a safe way to roll keys without downtime, and logs need redaction rules. Support/admin tools should never display full secrets after creation. Incident response should answer which users or clients are affected, how to revoke credentials, and how to verify the new secret is in use. Good secret handling is mostly about boring discipline across all the places secrets might accidentally appear.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain token storage trade-offs.
No secret manager or protected config boundary.
No redaction in logs.
No incident response path after credential leakage.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why store only a hash of an API key?
How would you rotate a signing key?
What token storage risks differ between cookies and localStorage?

Continue the section

Next in API Security & Auth Essentials: Headers and TLS

Step 17 of 20

Use security headers, TLS, and cookie flags correctly

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 the section

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 the section