Host leaks function/host key verbatim to Application Insights as dependency telemetry

[jvmap]

• Timestamp: 2026-02-11T09:29:59.7474204Z
• Function App version: Dotnet-isolated - 10.0 (linux)
• Invocation ID: 7626f396-74bc-40e9-beae-e6e2e92fc5e7
• Region: West Europe

Repro steps

1. Perform an HTTP call to an HttpTrigger function, defined like this:

public async Task<IActionResult> RunAsync(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req)
{

2. Observe logging in Application Insights resource
3. Notice a dependency telemetry is logged like this:
   http://localhost:39357/<function-path>?code=<the-actual-key>

Expected behavior

The function host should never leak the function key to Application Insights or other logging/monitoring tools.
Instead, the secret value should be redacted like this:
http://localhost:39357/<function-path>?code=REDACTED

Actual behavior

The function or host key (whatever was used to authorize the request) is leaked to Application Insights.

Known workarounds

• Not use Azure functions
• Not use HttpTrigger
• Not use key-based authorization
• Not use isolated process model
• Not have security or compliance needs

Related information

I developed my function in C# on .NET 10.
I was not able to work around this problem with an ITelemetryInitializer. I suspect this is because the telemetry is written by the host and not by my code, so there is nothing I can do about it.

[RohitRanjanMS]

Hi @jvmap, thanks for reaching out. If I’m understanding correctly, one of your functions is calling another HTTP‑triggered function, and that outbound call is generating a dependency telemetry record.

Could you share the sdkVersion value from the dependency telemetry? Also, do you have Application Insights configured on the worker, and can you share how it’s set up?

[jvmap]

Hi @RohitRanjanMS . No, this is just one function. One HttpTriggered function that is being triggered via a GET request in the browser (in this case).

This is the SDK version: rdddsc:2.23.0-29 . This seems to be a related issue: #11433

This is in my host.json:

"applicationInsights": {
  "samplingSettings": {
    "isEnabled": false,
    "excludedTypes": "Request"
  },
  "enableDependencyTracking": true,
  "dependencyTrackingOptions": {
    "enableSqlCommandTextInstrumentation": true
  },
  "LogLevel": {
    "Default": "Debug"
  },
  "enableLiveMetricsFilters": true
}

[RohitRanjanMS]

yeah, this is being tracked by the AppInsights SDK.
Can you disable enableDependencyTracking and check?

[RohitRanjanMS]

Can you also shave your Program.cs? You can remove the business logic from it.

[jvmap]

Here is my Program.cs (relevant bits).

IHostBuilder builder = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        var aiOpts = new ApplicationInsightsServiceOptions
        {
            // This is also configured in host.json, but that doesn't appear to work.
            EnableAdaptiveSampling = false
        };
        services.AddApplicationInsightsTelemetryWorkerService(aiOpts);
        services.ConfigureFunctionsApplicationInsights();
        services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>(
            (module, _) => module.EnableSqlCommandTextInstrumentation = true
        );
        services.Configure<LoggerFilterOptions>(options =>
        {
            // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
            // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/en-us/azure/azure-monitor/app/worker-service#ilogger-logs
            LoggerFilterRule? toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (toRemove != null)
            {
                options.Rules.Remove(toRemove);
            }
        });

        services.AddAzureClients(act =>
        {
            if (storageSettings.KeyVaultUri != null)
                act.AddSecretClient(new Uri(storageSettings.KeyVaultUri));
            act.UseCredential(new DefaultAzureCredential());
        });

        services.AddHttpClient();
    });

IHost host = builder.Build();
host.Run();

Will follow up with enableDependencyTracking later.

I'm thinking maybe the part with LoggerFilterRule might have something to do with it? But it any case, secrets should be masked/redacted (regardless of filters).

[jvmap]

Can you disable enableDependencyTracking and check?

With enableDependencyTracking: false, the offending DependencyTelemetry no longer shows up in Application Insights.
So, this looks like the solution for issue #11433 (which is related, but not the same).

However, even with enableDependencyTracking: false, the function key is still leaked via a Trace telemetry:

This Information type Trace contains the function key in the Message and QueryString fields.

I'd also argue that enableDependencyTracking: false only partially hides the problem, but does not solve it.

[RohitRanjanMS]

Can you share the category for this log? You may be able to add a filter in host.json to filter this out.

Also, you can try the new OpenTelmetry based instrumentation. We have HttpClient instrumentation disabled by default in the host, you should not see these dependency and logs.

I am looking into this issue, will follow-up with my update.