Java should be updated to the latest version for API apps

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

Flags any App Service API app whose configured Java runtime is behind the latest version Azure offers. The check reads the app's 'linuxFxVersion' setting (for example 'JAVA|17-java17') and compares the major Java line against the newest supported build. It applies to Linux API apps running on a built-in Java stack only. It does not inspect Java libraries bundled inside your deployment artefact, it does not cover function apps or standard web apps, which have their own recommendations, and it cannot read into a custom container image, where you own the runtime and the check is skipped.

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

An outdated Java runtime keeps shipping known, catalogued CVEs in the JVM and base class library, the exact flaws that scanners and exploit kits target first. Because the runtime sits underneath your application code, a single deserialisation or TLS defect in an old JDK can compromise an API that is otherwise well written. Azure patches supported Java lines quarterly, in January, April, July and October, and retires old ones after a notice period, so a pinned legacy version eventually stops receiving fixes entirely. For a public API that is the difference between a routine upgrade and an unpatched, internet-facing entry point that auditors and attackers both notice. Staying current also keeps you eligible for Microsoft support if an incident does occur on the runtime.

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

1. List the runtimes Azure currently supports with 'az webapp list-runtimes --os linux | grep JAVA', then pin the API app to the newest line: 'az webapp config set --resource-group <rg> --name <app> --linux-fx-version "JAVA|21-java21"'. In the portal this is App Service, Settings, Configuration, General settings, Stack, Major version.
2. Test the app on the new JDK in a deployment slot before swapping to production, because a major Java jump can change behaviour around TLS defaults, garbage collection and removed APIs.
3. Enforce it going forward by assigning the built-in audit policy. Look the definition up by name rather than hardcoding its ID: pid=$(az policy definition list --query "[?displayName=='Ensure that ''Java version'' is the latest, if used as a part of the API app'].name" -o tsv); az policy assignment create --name api-java-latest --policy "$pid" --scope <subscription-or-rg-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"