Suspicious PII Leakage in Spans
Problem
Your spans carry data that looks like personal or sensitive data: emails, national or tax IDs, credentials, or financial identifiers. It shows up in span attributes, span event names and attributes, URL query parameters, and nested JSON, often because HTTP instrumentation copied a full query string or a request payload into telemetry wholesale.
Insights reports where it found the data and what kind of data it looks like. The matched value itself is never stored.
This finding scores against Instrumentation Score rule SPA-006.
Impact
- Regulatory exposure: personal data in telemetry falls under GDPR, LGPD, and similar regimes, including breach-notification duties.
- The data spreads: every backend, every retention window, every export now holds a copy, readable by anyone with dashboard access.
- Cleanup after the fact is far more expensive than never emitting it.
Example
Leaking:
# span attributesSafe:
# span attributesurl.query: "email=REDACTED&card_number=REDACTED"# or drop the attribute entirely if you don't query itHow to fix
- Configure the SDK or instrumentation to sanitize or exclude sensitive attributes before they are recorded. Review
url.query,url.full,db.query.text, and exception attributes first. - Prefer attribute allow-lists over capturing all request or response data.
- Until the source is fixed, use the Collector attributes or transform processor to delete or hash sensitive span attributes.
We run this on ourselves
Running Insights on our own ingestion service flagged nine suspicious attribute keys across 74,524 span occurrences, including an auth.api_key.* family: a credential rather than personal data, but caught by the same check. A finding doesnβt always mean data is leaking, but it always deserves a look.
Expected gains
Personal data stops flowing into your observability stack, and your compliance surface shrinks to the systems that actually need the data.
See the Insights catalog for everything Insights can detect.