Skip to main content
emnode
Compliance Medium severity MCSB IM-4

Microsoft Defender for Cloud · Azure API Management

API Management calls to API backends shouldn't bypass certificate thumbprint or name validation

Written and reviewed by Emnode · Last reviewed

What does the recommendation "API Management calls to API backends shouldn't bypass certificate thumbprint or name validation" check?

Flags any API Management Backend entity where TLS validation of the backend's server certificate is switched off, meaning either 'tls.validateCertificateChain' or 'tls.validateCertificateName' is set to false. With validation disabled, API Management opens the upstream TLS connection but accepts whatever certificate the backend presents, so a forged, expired or wrong-host certificate is trusted. The check covers Backend resources created on the gateway; it does not inspect inline backend URLs set directly on an operation, nor does it evaluate the client certificate your gateway presents to the backend, the validate-client-certificate policy that authenticates inbound callers, or whether the front-end gateway listener enforces TLS 1.2.

Why does "API Management calls to API backends shouldn't bypass certificate thumbprint or name validation" matter?

API Management usually sits between the public internet and internal services holding the data those APIs expose. If the gateway does not verify the backend certificate, anyone able to intercept the gateway-to-backend hop, a compromised network appliance, a poisoned DNS record or a hijacked private endpoint, can present their own certificate and the gateway will hand over requests and bearer tokens to the impostor. That is a server-side man-in-the-middle: payloads, credentials and customer records are silently rerouted while every call still returns 200. Because the bypass is a per-backend property, one Backend created from a self-signed test box can quietly disable validation in production and nothing in the response signals the downgrade.

How do I fix "API Management calls to API backends shouldn't bypass certificate thumbprint or name validation"?

  1. Audit every Backend on the service and identify those with validation off: 'az apim backend list -g <rg> -n <apim-service> --query "[].{id:name, chain:tls.validateCertificateChain, name:tls.validateCertificateName}" -o table'.
  2. Re-enable both checks on each affected Backend. The CLI exposes this through the generic update path: 'az apim backend update -g <rg> -n <apim-service> --backend-id <backend-id> --set tls.validateCertificateChain=true tls.validateCertificateName=true'. In Bicep set the same two flags under the backend's 'tls' block. If a backend genuinely uses a private or self-signed CA, upload the root and intermediate certificates to the gateway's CA Certificates store rather than turning chain validation off.
  3. Enforce the baseline at scale by assigning the built-in audit policy so new backends cannot regress unnoticed. Look the definition up by display name rather than pasting a GUID: 'pid=$(az policy definition list --query "[?displayName=='\''API Management calls to API backends should not bypass certificate thumbprint or name validation'\''].name" -o tsv)' then 'az policy assignment create --name apim-backend-cert-val --policy "$pid" --scope <subscription-or-rg-scope>'.

Remediation script · bash

# 1. Enable the Defender for APIs plan on the subscription so onboarded APIs are inspected.
az security pricing create --name Api --tier Standard

# 2. Disable the deprecated direct management endpoint (retired 15 March 2025).
#    'customProperties' on the service controls this gateway behaviour.
az apim update --name apim-prod --resource-group rg-platform \
  --set 'properties.customProperties."Microsoft.WindowsAzure.ApiManagement.Gateway.ManagementEndpoint"=false'

# 3. Re-enable backend certificate chain and name validation on a backend that
#    had it switched off. There is no native 'az apim backend' TLS flag, so PUT
#    the documented 'tls' block via the management API (api-version 2024-05-01).
sub=$(az account show --query id -o tsv)
az rest --method put \
  --uri "https://management.azure.com/subscriptions/$sub/resourceGroups/rg-platform/providers/Microsoft.ApiManagement/service/apim-prod/backends/payments-backend?api-version=2024-05-01" \
  --body '{"properties":{"url":"https://payments.internal/","protocol":"http","tls":{"validateCertificateChain":true,"validateCertificateName":true}}}'

# 4. Ratchet it shut: audit any instance whose management endpoint stays enabled.
#    Look the built-in policy up by display name; never hardcode a definition GUID.
pid=$(az policy definition list \
  --query "[?displayName=='API Management direct management endpoint should not be enabled'].name" -o tsv)
az policy assignment create \
  --name audit-apim-mgmt-endpoint \
  --policy "$pid" \
  --scope "/subscriptions/$sub"

Full walkthrough (console steps, edge cases and verification) in the lesson Harden Azure API Management.

Is "API Management calls to API backends shouldn't bypass certificate thumbprint or name validation" a false positive?

A backend that terminates TLS behind a private endpoint using an internal enterprise CA can legitimately appear to need an exception, but the correct fix is to trust that CA on the gateway, not to disable validation. The one deliberate case where 'validateCertificateChain' is set to false is a backend using a self-signed certificate during early integration testing: there the chain cannot be built because no CA issued it. Treat that as a documented, time-boxed exemption on a non-production gateway and restore both checks before the API is published, rather than leaving the suppression in place.