# Azure App Service Authentication Not Enabled

> App Services and Function Apps without EasyAuth enforcement accept anonymous traffic on every endpoint. ZopNight's discoverer stamps auth_enabled true only when both platform.enabled and requireAuthentication hold in authsettingsV2; rule RC-1312 fires on "false", including the 404 case where auth was never configured, and abstains when the key is absent.

Source: https://zop.dev/integrations/azure/recommendations/azure-app-service-authentication-not-enabled
Updated: 2026-08-19

---

## 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

```bash
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.