App Services and Function Apps serving traffic with EasyAuth not enforcing authentication

Anonymous by default

A freshly deployed App Service or Function App answers anyone who finds its URL, and *.azurewebsites.net hostnames are enumerable, indexed, and scanned continuously. If the application does not implement its own login, every route it exposes is effectively public: admin panels, staging builds of internal tools, HTTP-triggered functions with side effects. App Service’s built-in authentication layer (EasyAuth) exists to close exactly this: it intercepts requests at the platform level and validates identity before your code runs.

Both switches must be on

The subtlety this rule encodes: EasyAuth can be enabled yet still wave anonymous traffic through. In authsettingsV2, platform.enabled turns the feature on, but only globalValidation.requireAuthentication makes unauthenticated requests actually get rejected. ZopNight’s discoverer stamps auth_enabled true only when both hold, so a half-configured site (feature on, enforcement off) is still reported. Detection targets the functionapp canonical type, which covers web apps and function apps alike, because EasyAuth is a per-site property, never a property of the App Service plan.

Query authsettingsV2 yourself

az rest --method post \
  --uri "https://management.azure.com$(az webapp show -n <app> -g <rg> --query id -o tsv)/config/authsettingsV2/list?api-version=2022-03-01" \
  --query "{enabled: properties.platform.enabled, require: properties.globalValidation.requireAuthentication}"

Anything other than both values true is the state rule RC-1312 reports.

The 404 that counts as evidence

Azure Resource Graph does not index the authsettingsV2 sub-resource, so the discoverer issues that same ARM GET .../config/authsettingsV2/list per site. A 404 means auth settings were never configured at all. That is the strongest possible “no authentication” signal, and it is stamped as "false". A transport error or an undecodable response, by contrast, leaves the key absent and the rule abstains: it fails closed rather than flagging a site it could not actually inspect. The old customer-spoofable authentication tag plays no part.

What EasyAuth does and does not cover

Fixing the finding means adding an identity provider under the site’s Authentication blade (Microsoft Entra ID for internal tools, or social providers for consumer apps), then requiring authentication for unmatched requests. Genuinely public sites (marketing pages, open APIs with their own key scheme) are a judgment call: the rule cannot distinguish intentionally-public from forgotten, so expect to triage some findings into an accepted list rather than remediating them.