Description
Logging passwords, tokens, API keys or session identifiers directly may leave secrets in log collectors, console output, operational dashboards and error reports. Logs are often shared more widely or retained longer than application data, creating opportunities for account takeover or privilege escalation.
Potential impact
- Credentials may remain in operational logs, central collectors or error reports for a long time.
- Someone with log access may reuse a token or API key to take over an account.
- Sharing logs during incident response may disclose the data further.
Remediation
- Do not log secrets. Record a fixed masking value or a tracking identifier only when needed.
- Use a shared redaction helper to remove fields such as
password,token,secret,apiKey,authorizationandcookie. - Allow-list the fields to record in structured logs and exclude sensitive fields.
- Apply the same restrictions to direct
stdoutandstderroutput, which may be collected as operational logs.
Examples
getTokenId is an application-defined helper. It must return only a tracking identifier that cannot be reused for authentication. Token verification and restrictions on log access and retention are also required separately.
Before
javascript
function login(req) {
const token = req.headers.authorization;
console.info("login token", token);
}
After
javascript
function login(req) {
const tokenId = getTokenId(req.headers.authorization);
console.info("login token accepted", { tokenId });
}
Explanation:
- Before: The complete authentication token is logged and may be reused by someone with access to the log.
- After: Only a tracking identifier is recorded, rather than the secret itself.