IHttpClientBuilder should have extension to redact query parameter from logging

[anktsrkr]

The current implementation of Microsoft.Extensions.Http logging framework redact headers value based on user input however it does not support redact sensitive information from query parameters, which is kind of security issue.

For customers that are more concerned about this logging risk or have to meet audit requirements for all their integrated services it is important to redact query parameters value based on users input.

The problem lies here -

runtime/src/libraries/Microsoft.Extensions.Http/src/Logging/LoggingScopeHttpMessageHandler.cs

Line 133 in 215b39a

private static string? GetUriString(Uri? requestUri)

We could implement this feature same way as we have a extension in IHttpClientBuilder to redact from header.

runtime/src/libraries/Microsoft.Extensions.Http/src/DependencyInjection/HttpClientBuilderExtensions.cs

Line 463 in 215b39a

public static IHttpClientBuilder RedactLoggedHeaders(this IHttpClientBuilder builder, Func<string, bool> shouldRedactHeaderValue)

We might name this extension RedactLoggedQueryParameters

Thanks,
Ankit S

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The current implementation of Microsoft.Extensions.Http logging framework redact headers value based on user input however it does not support redact sensitive information from query parameters, which is kind of security issue.

For customers that are more concerned about this logging risk or have to meet audit requirements for all their integrated services it is important to redact query parameters value based on users input.

The problem lies here -

runtime/src/libraries/Microsoft.Extensions.Http/src/Logging/LoggingScopeHttpMessageHandler.cs

Line 133 in 215b39a

private static string? GetUriString(Uri? requestUri)

We could implement this feature same way as we have a extension in IHttpClientBuilder to redact from header.

runtime/src/libraries/Microsoft.Extensions.Http/src/DependencyInjection/HttpClientBuilderExtensions.cs

Line 463 in 215b39a

public static IHttpClientBuilder RedactLoggedHeaders(this IHttpClientBuilder builder, Func<string, bool> shouldRedactHeaderValue)

We might name this extension RedactLoggedQueryParameters

Thanks,
Ankit S

Author:	anktsrkr
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The current implementation of Microsoft.Extensions.Http logging framework redact headers value based on user input however it does not support redact sensitive information from query parameters, which is kind of security issue.

For customers that are more concerned about this logging risk or have to meet audit requirements for all their integrated services it is important to redact query parameters value based on users input.

The problem lies here -

runtime/src/libraries/Microsoft.Extensions.Http/src/Logging/LoggingScopeHttpMessageHandler.cs

Line 133 in 215b39a

private static string? GetUriString(Uri? requestUri)

We could implement this feature same way as we have a extension in IHttpClientBuilder to redact from header.

runtime/src/libraries/Microsoft.Extensions.Http/src/DependencyInjection/HttpClientBuilderExtensions.cs

Line 463 in 215b39a

public static IHttpClientBuilder RedactLoggedHeaders(this IHttpClientBuilder builder, Func<string, bool> shouldRedactHeaderValue)

We might name this extension RedactLoggedQueryParameters

Thanks,
Ankit S

Author:	anktsrkr
Assignees:	-
Labels:	api-suggestion, area-System.Net.Http, untriaged, area-Extensions-HttpClientFactory
Milestone:	-

[CarnaViire]

Thanks for raising the concern @anktsrkr.

As a quick workaround for the time being, you can consider removing the logging entirely by putting that code after all your HttpClient registrations in ConfigureServices:

services.RemoveAll<IHttpMessageHandlerBuilderFilter>();

[CarnaViire]

Triage: URIs aren’t meant to contain secrets for various reasons, e.g. proxies. But we still might want to add some way to control this. Given there's a workaround, moving to future.

[CarnaViire]

Note that #74339 asked for redacting not only query parameters, but path as well

[MihaZupan]

FWIW, even the new HTTP logging in ASP.NET defaults to logging the path (though it is configurable).