Remote debugging should be turned off for Web Applications

What does the recommendation "Remote debugging should be turned off for Web Applications" check?

Flags any App Service web app whose remote debugging configuration is on, by reading the 'remoteDebuggingEnabled' property under the site's web config (Microsoft.Web/sites/config). When it is true, App Service opens extra inbound ports so a developer can attach a debugger from Visual Studio to the running app and step through its code. The check looks only at this one app-level toggle on production web apps: it does not inspect deployment slots, Function apps or the now retired API Apps, each of which is governed by its own separate recommendation. It is a configuration check, so it reports whether the door is open, not whether anyone is currently attached through it, and it does not account for the fact that the setting will eventually lapse on its own.

Why does "Remote debugging should be turned off for Web Applications" matter?

Remote debugging is meant for short troubleshooting sessions, not steady-state operation, yet the toggle is easy to leave on after a deploy. While it stays on, the app exposes additional ports and a debugging endpoint, which widens the attack surface and gives an attacker who has gained a foothold a path to pause execution, read variables holding secrets or connection strings, and step through code in production. App Service does turn remote debugging off automatically after 48 hours, but a worker recycle can restart that clock, so the window is not as self-closing as it looks, and access to the port is authenticated rather than blocked outright. The business consequence is a debug channel into a live, customer-facing application that should simply not be reachable, and an avoidable finding sitting against your posture score for as long as the toggle stays on.

How do I fix "Remote debugging should be turned off for Web Applications"?

1. Turn the toggle off on the affected app with 'az webapp config set --resource-group <group> --name <app> --remote-debugging-enabled false', which sets remoteDebuggingEnabled to false. In Bicep, set 'remoteDebuggingEnabled: false' in the Microsoft.Web/sites/config 'web' resource so redeploys cannot reintroduce it.
2. Repeat for any deployment slots, since each slot carries its own configuration and the production-only fix leaves a staging slot debuggable.
3. Enforce the safe state across the estate by assigning the built-in policy by its exact display name so you never paste 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 webapp-no-remote-debug --policy "$pid" --scope <scope>.

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"