Azure Function HealthCheck does not inject x-ms-auth-internal-token

Question

Azure Function HealthCheck does not inject x-ms-auth-internal-token

Anonymous

When CORS is set, HealthCheck normally injects x-ms-auth-internal-token into request header.

Due to some needed changes, we removed CORS from the Azure setup and moved this logic into a middleware. This removal of CORS caused HealthCheck to be Degraded due to 401s returned.
Upon logging the request headers I noticed that x-ms-auth-internal-token is not sent when CORS is removed.
Our current solution is to remove this security check from the HealthCheck and make it public.

Is this desired behavior or a bug?

0 comments

Answer accepted by question author

David Broggy 6,801 MVP

Hi Milena,

This is desired behavior, not a bug.

The x-ms-auth-internal-token header is automatically injected by Azure App Service when:

1. Authentication is enabled on the App Service

2. The request originates from within the same App Service environment (internal calls)

3. CORS is configured, which signals to Azure that cross-origin requests should be handled

When you remove CORS from Azure configuration, the platform no longer recognizes these as internal/trusted requests, so it stops injecting the authentication token.

Here are some suggested solutions, rather than making the HealthCheck public:

1. Use IP restriction - Allow health check endpoint from Azure's internal IP ranges

2. Custom health check endpoint - Create a separate /health-internal endpoint that bypasses auth, restricted to local/internal IPs only

3. Configure CORS minimally - Re-add CORS with restrictive settings just to re-enable the internal token injection

4. Use App Service's built-in health check - Configure it in Azure Portal under Monitoring > Health check, which automatically bypasses auth

5. Anonymous auth for specific path - In your middleware, allow anonymous access only for /health or /healthzpaths

Recommended approach:

// In your middleware

if (context.Request.Path.StartsWithSegments("/health") &&

context.Connection.LocalIpAddress?.Equals(context.Connection.RemoteIpAddress) == true)

{

// Allow health check from localhost/internal

await next();

}

Or use Azure's native health check feature which doesn't require the auth token.

Anonymous

2025-10-07T09:24:02.98+00:00
Authentication is enabled on the App Service

Auth is not enabled on our Function App. But if we enabled it and then just omitted all endpoints from auth, would we then get the token? All endpoints are public, so we don't need auth.

2. The request originates from within the same App Service environment (internal calls)

We are using the native Azure Health check - so I assume it originates from internal calls? The header was present when we had CORS configured in Azure.

As for the suggestions:

1. Use IP restriction - Allow health check endpoint from Azure's internal IP ranges

I would prefer to avoid this as it comes with quite an overhead in setting up virtual networks just for the health check.

2. Custom health check endpoint - Create a separate /health-internal endpoint that bypasses auth, restricted to local/internal IPs only

What's the difference between this approach and option 1?

3. Configure CORS minimally - Re-add CORS with restrictive settings just to re-enable the internal token injection

We need CORS * for all endpoints but ONE, where we need Access-Control-Allow-Credentials for a specific domain (domain is not part of fixed list we can allow). Adding any restrictive settings in Azure CORS setup overrides anything we do in middleware. So I believe this is not an option for us unless you have other ideas?

4. Use App Service's built-in health check - Configure it in Azure Portal under Monitoring > Health check, which automatically bypasses auth

We are already using the built-in health check.

5. Anonymous auth for specific path - In your middleware, allow anonymous access only for /health or /healthzpaths

I don't see the difference from this and option 1 + 2? Please elaborate.

1 additional answer

Your answer

Anonymous

2025-10-07T09:24:02.98+00:00

Authentication is enabled on the App Service

Auth is not enabled on our Function App. But if we enabled it and then just omitted all endpoints from auth, would we then get the token? All endpoints are public, so we don't need auth.

2. The request originates from within the same App Service environment (internal calls)

We are using the native Azure Health check - so I assume it originates from internal calls? The header was present when we had CORS configured in Azure.

As for the suggestions:

1. Use IP restriction - Allow health check endpoint from Azure's internal IP ranges

I would prefer to avoid this as it comes with quite an overhead in setting up virtual networks just for the health check.

2. Custom health check endpoint - Create a separate /health-internal endpoint that bypasses auth, restricted to local/internal IPs only

What's the difference between this approach and option 1?

3. Configure CORS minimally - Re-add CORS with restrictive settings just to re-enable the internal token injection

We need CORS * for all endpoints but ONE, where we need Access-Control-Allow-Credentials for a specific domain (domain is not part of fixed list we can allow). Adding any restrictive settings in Azure CORS setup overrides anything we do in middleware. So I believe this is not an option for us unless you have other ideas?

4. Use App Service's built-in health check - Configure it in Azure Portal under Monitoring > Health check, which automatically bypasses auth

We are already using the built-in health check.

5. Anonymous auth for specific path - In your middleware, allow anonymous access only for /health or /healthzpaths

I don't see the difference from this and option 1 + 2? Please elaborate.

Answer 1

Thomas Döör - Mover 0

I hosting a .net 10 web app on Linux, and I see the header x-ms-auth-internal-token header only when starting the app.
When running the app the header is no longer there. Why is that?

Thomas Döör - Mover 0 Reputation points

2026-09-15T13:23:57.17+00:00

Obviously calling a configured health endpoint