Python should be updated to the latest version for API apps

What does the recommendation "Python should be updated to the latest version for API apps" check?

Flags Linux App Service API apps whose runtime stack ('linuxFxVersion', for example 'PYTHON|3.9') is pinned to a Python minor version older than the latest one App Service offers. It reads the configured framework version recorded in the site's siteConfig, not the interpreter baked into a custom container, the version your virtual environment resolves at runtime, or anything you pip install. The scope is narrow on purpose: it applies only to the built-in Python stack on Linux, since App Service runs Python exclusively on Linux. It does not cover Azure Functions Python apps (a separate, now-deprecated recommendation), Windows-hosted apps, or apps that ship their own Docker image, and it does not analyse your application dependencies or third-party packages for known vulnerabilities. An 'API app' here is simply a Microsoft.Web/sites resource whose 'kind' marks it as an API app rather than a standard web app.

Why does "Python should be updated to the latest version for API apps" matter?

Older Python minor versions stop receiving security patches once they leave App Service's supported list, so a known interpreter or standard-library flaw stays exploitable on an internet-facing API with no upstream fix coming. Because API apps usually sit in front of data stores, internal services or partner integrations, an outdated runtime widens the attack surface on exactly the tier you can least afford to leave unpatched: a single CVE in an unpatched standard-library module becomes a direct route into the systems that API fronts. There is a business cost too. When Microsoft retires a Python version it disappears from the portal stack picker, and an app still pinned to it can be blocked from a clean in-place upgrade, forcing an unplanned migration under time pressure or risking a failed deployment during an incident. Staying on the latest supported minor keeps the app inside the patched, supported window and keeps the upgrade path open before it is forced on you.

How do I fix "Python should be updated to the latest version for API apps"?

1. Confirm the current stack and the versions available: run 'az webapp config show --resource-group <rg> --name <app> --query linuxFxVersion' to see what is pinned, then 'az webapp list-runtimes --os linux' to find the newest supported PYTHON value.
2. Pin the app to the latest supported minor: 'az webapp config set --resource-group <rg> --name <app> --linux-fx-version "PYTHON|3.14"' (or set 'linuxFxVersion: 'PYTHON|3.14'' in your Bicep 'Microsoft.Web/sites/config' siteConfig). Restage and run your tests first, since a minor bump can change behaviour.
3. Enforce it going forward by assigning the built-in audit policy so drift is caught automatically: pid=$(az policy definition list --query "[?displayName=='App Service apps that use Python should use a specified ''Python version''].name" -o tsv); az policy assignment create --name require-python-latest --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"