Remote debugging should be turned off for API App

What does the recommendation "Remote debugging should be turned off for API App" check?

Flags any API App (a Microsoft.Web/sites resource) whose 'remoteDebuggingEnabled' property is set to true in its siteConfig, which lets a developer attach a debugger from Visual Studio over the network. It reads the app's own configuration only: it does not check inbound network controls, access restrictions or whether anyone is actively attached, and it does not cover Function Apps, which have a separate recommendation. Note that this specific API App recommendation is deprecated by Microsoft and folded into the broader 'App Service apps should have remote debugging turned off' control, so treat it as one of a family that covers every App Service site type.

Why does "Remote debugging should be turned off for API App" matter?

Enabling remote debugging opens additional inbound ports on the App Service so a debugger can attach to the live process. Although that connection is authenticated, it widens the attack surface of a production app and, more practically, a paused breakpoint freezes a real request thread, so a forgotten debug session can stall traffic and expose stack-level detail, in-memory secrets and request payloads to whoever is attached. Debugging is a development behaviour that has no place on an internet-facing API serving real users, and an attacker who compromises developer credentials, or simply finds a session left open, gains a direct foothold into the running code. The business consequence is twofold: a self-inflicted availability incident when a held breakpoint backs up customer requests, and a confidentiality breach if sensitive data is read out of the attached process. The setting auto-disables after 48 hours, but that window is more than long enough for an incident, so you should not treat the timeout as a control.

How do I fix "Remote debugging should be turned off for API App"?

1. Turn it off in the portal under your API App's Configuration, then General settings, by setting Remote debugging to Off; or run 'az webapp config set --resource-group <rg> --name <app> --remote-debugging-enabled false'.
2. Bake the safe default into infrastructure as code: in Bicep set 'siteConfig: { remoteDebuggingEnabled: false }' on the Microsoft.Web/sites resource so redeploys cannot silently re-enable it.
3. Enforce it at scale by assigning the built-in policy, looking the definition up by exact name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='App Service apps should have remote debugging turned off'].name" -o tsv); az policy assignment create --name no-remote-debug --policy "$pid" --scope /subscriptions/<sub-id>.

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"