Skip to main content
On this page

Suspicious Credential Leakage in Spans

Critical Signal: Traces

Problem

Your spans carry data that looks like credentials: passwords, access tokens, API keys, or other secrets. It shows up in span attributes, span event names and attributes, URL query parameters, HTTP headers, and nested JSON — usually because HTTP instrumentation captured a full query string, an Authorization header, or a request body wholesale.

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 SPA-006.

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:

# span attributes
url.full: "https://api.example.com/v1/sync?api_key=sk_live_4eC3...zdp7"

Safe:

# span attributes
url.full: "https://api.example.com/v1/sync?api_key=REDACTED"

How to fix

  1. Treat every detected credential as compromised: rotate or revoke it, then review access made with it.
  2. Stop capturing request or response bodies and Authorization or cookie headers; filter sensitive parameters out of url.query and url.full at the instrumentation level, and prefer attribute allow-lists.
  3. Until the source is fixed, use the Collector attributes, redaction, or transform processor to delete or mask credential attributes, and restrict or purge the copies already stored.

Expected gains

Credentials stop flowing into your observability stack, and your security review surface shrinks to the systems that were meant to hold them.

See the Insights catalog for everything Insights can detect.