Skip to main content
emnode
Sign up
Compliance High severity MCSB IM-4

Microsoft Defender for Cloud · Azure API Management

API endpoints in Azure API Management should be authenticated

Written and reviewed by Emnode · Last reviewed

What does the recommendation "API endpoints in Azure API Management should be authenticated" check?

Surfaced by Defender for APIs as part of API security posture, this assesses each API endpoint published in an Azure API Management instance and flags any that complete a call with no authentication enforced. It looks for a subscription key on APIs or products that require a subscription, and for an inbound policy that actually runs to validate a credential: 'validate-jwt' for Microsoft Entra or OpenID Connect tokens, or 'validate-client-certificate' for mutual TLS. If none of these execute during a call, the endpoint is reported as unauthenticated. It only covers APIs onboarded to Defender for APIs in an API Management gateway; it does not inspect raw App Service or Function endpoints, does not judge whether your authorisation logic is correct once a token is accepted, and does not verify the strength of the issuer or scopes.

Why does "API endpoints in Azure API Management should be authenticated" matter?

An unauthenticated endpoint means any caller who can reach the gateway URL can invoke the operation and read or change whatever sits behind it, with no identity attached to the request. Internal-only APIs routinely get published this way during a rush, then stay public for months because nothing visibly breaks. The business consequence is direct: a single open endpoint exposing customer records, pricing logic or an order-mutation call becomes a credential-free data tap that attackers find by enumerating the gateway, and the access leaves no per-caller trail to revoke or investigate after the fact.

How do I fix "API endpoints in Azure API Management should be authenticated"?

  1. Decide the right credential per API: a subscription key for internal service-to-service traffic, or a token for user-facing APIs. For subscription keys, open the API in the portal under Settings and tick 'Subscription required', or set 'subscriptionRequired' to true on the API resource in Bicep.
  2. For token-based APIs, add a 'validate-jwt' policy to the inbound section pointing at your identity provider's OpenID configuration, for example <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" /> with a required-claims audience check, so requests without a valid Entra token are rejected at the gateway. For mutual TLS, use 'validate-client-certificate' instead.
  3. Confirm the gate works: az apim api show --resource-group <rg> --service-name <apim> --api-id <api> should report subscriptionRequired as true, and a call without the key or token should return 401. Bake the policy into your API Management policy fragments or Bicep modules so newly imported APIs inherit it rather than shipping open.

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 endpoints in Azure API Management should be authenticated" a false positive?

A deliberately anonymous endpoint, such as a public health probe, an OpenAPI document route or a webhook receiver that authenticates by verifying a signed payload in code rather than at the gateway, will still flag because no subscription key or inbound validation policy runs. That is a legitimate exception: keep the design, but document why it is safe and, where you can, move the signature check into a 'validate-jwt' or custom inbound policy so the gateway, not the backend, becomes the enforcement point.

Full lesson Harden Azure API Management Step-by-step remediation with CLI, code and persona-specific context.
Defender for Cloud recommendations ↗ Check your own account →
Part of the learning path Harden Azure workloads

More Azure API Management controls