Ensure API app has Client Certificates Incoming client certificates set to On

What does the recommendation "Ensure API app has Client Certificates Incoming client certificates set to On" check?

Flags an App Service app hosting an API where 'Client Certificates (Incoming client certificates)' is not set to 'On', meaning the app does not request and require a TLS client certificate from callers. Technically it audits the 'clientCertEnabled' property on the Microsoft.Web/sites resource and reports any app where it is false. Note this only governs mutual TLS at the App Service front end: it does not check whether your application code actually validates the presented certificate's thumbprint, issuer or expiry (the platform forwards the cert but does not authorise on your behalf), and it does not cover outbound client certificates, API Management's own validate-client-certificate policy, or apps fronted by a separate gateway. The underlying built-in policy was deprecated in July 2022, partly because HTTP/2 does not support incoming client certificates, so treat this as a configuration baseline rather than a live Defender assessment.

Why does "Ensure API app has Client Certificates Incoming client certificates set to On" matter?

An API with client certificates off accepts any caller that can reach its hostname, leaving authentication entirely to whatever token or key logic the app implements, with no transport-layer proof of the caller's identity. For service-to-service APIs that should only ever be called by a handful of known clients, that is a meaningful gap: a leaked bearer token or a server-side request forgery flaw is enough to impersonate a legitimate consumer. Requiring a client certificate adds a second, hard-to-steal factor bound to the TLS handshake, so a stolen token alone no longer reaches the API. The business consequence of leaving it off is a wider blast radius on any credential compromise and a finding against baselines such as CIS Azure that auditors will expect you to remediate or formally justify.

How do I fix "Ensure API app has Client Certificates Incoming client certificates set to On"?

1. In the Azure portal open the App Service, go to Configuration then General settings, and set 'Client certificate mode' to 'Require' (this writes clientCertEnabled=true), or run: az webapp update --resource-group <rg> --name <app> --set clientCertEnabled=true clientCertMode=Required
2. Express the same in your Bicep so it cannot drift: under resource site 'Microsoft.Web/sites' set properties.clientCertEnabled: true and properties.clientCertMode: 'Required', and deploy through your pipeline.
3. Make the app actually validate the forwarded certificate: read the X-ARR-ClientCert header (or use clientCertMode 'OptionalInteractiveUser' carefully) and check the thumbprint, issuer and validity in code, because App Service requests the certificate but does not authorise the caller for you.

SUB="/subscriptions/00000000-0000-0000-0000-000000000000"
RG="rg-app-prod"

# Harden every app that is not already HTTPS-only.
for app in $(az webapp list -g "$RG" \
    --query "[?!httpsOnly].name" -o tsv); do
  # 1. Force HTTPS on the site itself.
  az webapp update -g "$RG" -n "$app" --https-only true
  # 2. Turn off the remote debugger.
  az webapp config set -g "$RG" -n "$app" --remote-debugging-enabled false
  # 3. Drop any wildcard CORS origin (replace with your own origins after).
  az webapp cors remove -g "$RG" -n "$app" --allowed-origins '*'
  echo "$app: HTTPS forced, remote debugging off, wildcard CORS removed"
done

# Ratchet it shut: deny any future app that is not HTTPS-only.
# Look the built-in policy up by display name, never hardcode the GUID.
pid=$(az policy definition list \
  --query "[?displayName=='App Service apps should only be accessible over HTTPS'].name" -o tsv)
az policy assignment create \
  --name deny-appservice-http \
  --policy "$pid" \
  --scope "$SUB"