PHP should be updated to the latest version for API apps

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

Flags an API app whose PHP runtime is pinned to an older release rather than the newest version App Service offers. The check reads the app's configured stack (the 'linuxFxVersion' value, in the form 'PHP|8.x') and compares it against the latest supported PHP. It only looks at apps that actually run PHP: an API app on .NET, Node or Python is out of scope, and so is the operating-system patch level, your application's Composer dependencies or any third-party PHP extensions. It checks the declared major and minor version, not whether the platform has applied the latest point release underneath, so an app that declares a current branch passes even if a minor update is briefly pending on the host.

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

PHP ships frequent security fixes, and once a branch reaches end of life it stops receiving them entirely. An API app left on a retired branch, say PHP 7.x or 8.0, keeps serving traffic on an interpreter that no longer gets patches for known parser, deserialisation and memory-handling flaws. Because an API app is usually a backend that other services call directly, a compromise there can expose data and credentials for everything downstream. Running a current, supported branch means the next disclosed vulnerability already has a fix you can take, instead of leaving you to rebuild the app under pressure once an exploit is public. Keeping current also avoids the operational debt of a forced, multi-branch jump later, where several years of language changes have to be absorbed at once.

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

1. Confirm the running version with 'az webapp config show --resource-group <rg> --name <app> --query linuxFxVersion', then set a supported branch with 'az webapp config set --resource-group <rg> --name <app> --linux-fx-version "PHP|8.3"'. PHP is only supported on App Service for Linux, so a Windows-hosted app must move to a Linux plan first.
2. Pin the version in your infrastructure as code so it cannot drift back: in Bicep set 'properties.siteConfig.linuxFxVersion: 'PHP|8.3'' on the 'Microsoft.Web/sites' resource, and bump it as branches age out.
3. Test against the new branch before promoting it. Validate on a deployment slot ('--slot staging'), then swap, so any breaking language changes surface before production traffic hits the upgraded runtime.

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"