Some instrumentations set url.full without applying URL sanitization #19419

Describe the bug

URL redaction lives inside the extractors rather than at the attribute assignment. There are exactly two production call sites:

• HttpClientAttributesExtractor.stripSensitiveData — applies redactUserInfo then UrlQuerySanitizer.redactUrl, for url.full
• InternalUrlAttributesExtractor — applies redactQueryString, for url.query

Any instrumentation that computes a URL itself and calls attributes.put(URL_FULL, ...) directly silently opts out of both. There's no compile error, no test failure, and no lint to catch it. Three instrumentations currently do this:

Camel is the most significant of the three because it also bypasses redactUserInfo, which — unlike query parameter redaction — is not gated on any configurable list and applies unconditionally everywhere else. Semantic conventions state that url.full MUST NOT contain credentials passed as https://username:password@host/. HttpSpanDecorator.getHttpUrl returns the HTTP_URL/HTTP_URI header or a slice of endpoint.getEndpointUri(), any of which can carry userinfo.

For aws-lambda and elasticsearch, userinfo is structurally absent — the Lambda URL is built from the x-forwarded-proto/host headers, and Elasticsearch uses HttpHost.toURI() — so only query parameter redaction is missing there.

Steps to reproduce

Camel, credentials:

1. Attach the javaagent to an application with a Camel HTTP route whose endpoint URI embeds credentials, e.g. http://user:pass@backend/api.
2. Inspect url.full on the resulting span.

AWS Lambda, query parameters:

1. Deploy a Lambda behind API Gateway with the javaagent.
2. Invoke it with a query string containing a parameter in the configured sensitive set, e.g. ?sig=abc123.
3. Inspect url.full on the resulting span.

Expected behavior

The same output the standard extractors produce: REDACTED:REDACTED@backend/api for embedded credentials, and sig=REDACTED for sensitive query parameters.

Actual behavior

Both are emitted verbatim. The behavioral gap versus every other HTTP instrumentation is exactly the contents of the configured sensitive parameter set, plus userinfo in the Camel case.

Javaagent or library instrumentation version

main (a459b7f)

Environment

JDK: any
OS: any

Additional context

Suggested order of work, since the two fixes interact:

1. Camel — javaagent-only, so AgentCommonConfig.get() is directly reachable; it already pulls getKnownHttpRequestMethods() from there at L49-L50. Apply redaction at the attribute assignment on line 101 only — getHttpUrl() is also consumed by getPath() and HttpServerRoute for span naming, which only need the path.
2. aws-lambda and elasticsearch — library modules with no access to agent config, so the parameter set needs threading through each builder, defaulting to HttpConstants.SENSITIVE_QUERY_PARAMETERS, with the javaagent side wiring the configured value.

Worth pairing with #19418: the default list is currently stale, and API Gateway is where SigV4 query-string parameters are most likely to appear server-side. Fixing only the list leaves that path unprotected, since it never reaches the sanitizer; fixing only this issue means Lambda inherits a list missing the SigV4 names. Both need to land for that case to be covered.

Longer term, the root cause is that redaction is opt-in at the call site. A shared helper for setting url.full, or an ErrorProne/Checkstyle rule flagging direct put(URL_FULL, ...) outside instrumentation-api, would prevent a fourth instance.

The aws-lambda and camel call sites were reported privately by @lucianjohnhouse; the elasticsearch one and the interaction with #19418 turned up while verifying.