Suspicious Credential Leakage in Logs

Problem

Your logs carry data that looks like credentials: passwords, access tokens, API keys, or other secrets. It shows up in log bodies, log attributes, event names, and structured or embedded JSON payloads — typically from log statements that write whole request bodies, or serialize objects with toString and take the secret fields along.

Insights reports where it found the value and what kind of credential it looks like. The matched value itself is never stored.

This finding scores against Instrumentation Score rule LOG-003.

Impact

• A credential in telemetry is live attack surface: anyone with dashboard access can read and use it.
• The data spreads: every backend, every retention window, every export now holds a copy, far outside the systems the credential was scoped to.
• A detected credential has to be treated as compromised. Rotation and access review cost far more than never emitting it.

Example

Leaking:

INFO retrying webhook delivery payload={"url": "...", "token": "ghp_8c1zX..."}

Safe:

INFO retrying webhook delivery url=... token=REDACTED

How to fix

1. Treat every detected credential as compromised: rotate or revoke it, then review access made with it.
2. Find the log statements that write request bodies or serialize DTOs with toString, and stop logging them. Exclude secret fields from generated toString methods and turn off framework request-body logging in production.
3. Configure logging-framework masking at the source, and use the Collector redaction or transform processor to mask credential values until the source is fixed. Restrict or purge the copies already stored.

Expected gains

Credentials stop landing in your log storage, where retention windows and broad dashboard access make them the easiest secrets to find.

See the Insights catalog for everything Insights can detect.