Treat URL attributes as sensitive. The OpenTelemetry HTTP conventions say url.full must not contain credentials and that sensitive query values should be scrubbed. Check what your instrumentation records, add a redaction step in the collector, and keep tokens out of URLs in the first place.
What the specification says
The OpenTelemetry semantic conventions for HTTP spans define url.full, the absolute URL of a request, and url.query on server spans. Three statements matter here:
- url.full must not contain credentials passed in the form of https://username:password@host/. If they appear, the username and password should be masked, so the value becomes REDACTED:REDACTED in their place.
- Sensitive content in url.full and url.query should be scrubbed when instrumentation can identify it.
- A default list of query keys should have their values replaced by REDACTED: X-Amz-Signature, X-Amz-Credential, X-Amz-Security-Token, sig and X-Goog-Signature. The key stays visible, so a URL ends up looking like path?color=blue&sig=REDACTED.
That redaction section is marked as in development, and the list is case sensitive. If you configure your own list, it fully replaces the default rather than adding to it.
What the spec does not cover
The default list names signed-URL parameters from three cloud providers. It does not know about your own parameters: api_key, token, reset, code, session, email. Those are your responsibility. A password reset link carries a one-time secret in the query, and a trace backend that stores it keeps a working credential until it expires.
Where URLs end up in telemetry
| Place | Example | Risk |
|---|---|---|
| Server span url.query | token=abc123 | Anyone with trace access sees it |
| Client span url.full | Signed download link | Link may stay valid for hours |
| Access logs | Full request line | Same data in a second system |
| Error reports | Failed request URL | Third copy, often with wider access |
Fixing one place and forgetting the others is the common failure.
Steps
- Pull a sample of recent spans and search url.query and url.full for words like token, key, secret, code, signature and password.
- Check whether your instrumentation version applies the default redaction. Do not assume; look at a span generated by a signed-URL request in a test environment.
- Add your own sensitive keys to the configuration, remembering that a custom list replaces the default. Include the default keys in your list if you still need them.
- Add a collector-side processor as a second layer, so an application that skips redaction does not leak. See the collector redaction and filter processors post.
- Fix the root cause. Secrets belong in headers or request bodies, not in URLs. See bearer token in header or query string.
- Add a test: send a request with a fake token in the query and assert it does not appear downstream.
Common mistakes
Redacting the value but also dropping the key makes debugging harder and is not needed. The spec keeps the key so engineers can see that a parameter was present.
Matching is case sensitive in the spec, so Token and token are different keys. Include both spellings if your clients are inconsistent.
Quick check
Are credentials in a URL userinfo ever allowed in url.full?
No. The convention says url.full must not contain them, and if they appear they should be masked.
If I set my own list of sensitive query keys, do I keep the defaults?
No. The spec says a configured list is a full override, so include any default keys you still want.
Safeguard scans your dependencies and builds SBOMs, which helps you track the instrumentation libraries involved. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
