# Azure App Service Authentication Not Enabled

> Flags web and function apps whose built-in authentication is off or allows anonymous requests through to the application.

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

---

## Easy Auth only protects an app when it requires sign-in

App Service and Azure Functions include
[built-in authentication and authorization](https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization),
often called Easy Auth, that signs users in with Microsoft Entra ID or other identity
providers before a request reaches your code. It has two modes for unauthenticated traffic.
**Require authentication** rejects anonymous requests. **Allow unauthenticated requests**
lets them through and leaves the decision to the application.

So an app can have Easy Auth switched on and still serve anonymous callers. For an internal
tool or an admin API that relies on the platform for identity, either state means an open door.

## Inspecting an app's authentication settings

```bash
az webapp auth show --resource-group my-rg --name my-app
```

With the `authV2` extension, look at `platform.enabled` and
`globalValidation.requireAuthentication`. For a function app, run the same command against the
function app's name; both kinds of app are sites under the hood.

## Two settings must both be on

ZopNight treats an app as protected only when built-in authentication is enabled and
authentication is required. It reads both values from the app's V2 authentication settings and
fires when the combination comes back false. Web apps and function apps are evaluated the same
way. There is no traffic metric or window involved.

## Apps ZopNight does not flag

If the authentication settings could not be read for an app, for example because the request
failed, ZopNight treats the state as unknown and raises nothing. Tags on the app are not
consulted. App Service plans are not evaluated, because authentication is a per-app setting,
not a plan setting.

## Unauthorized access risk, no saving

This compliance rule claims no saving. The risk is that sensitive endpoints are reachable by
anyone who finds the URL, with no identity attached to the request for auditing.

## Requiring sign-in on the app

1. Open the app in the portal, go to **Authentication** and add an identity provider, such as
   Microsoft, if none is configured.
2. Set unauthenticated requests to be rejected or redirected, for example
   `az webapp auth update --resource-group my-rg --name my-app --enabled true --action RedirectToLoginPage`
   (use `Return401` for APIs). These `--action` values come from the `authV2` CLI extension; the
   core command accepts only the older V1 values.
3. Restrict which users can sign in; by default any user in your Entra tenant can request a
   token for the app.
4. Test with and without credentials, including health probes and webhooks that may need an
   excluded path.

**Note**
Enabling built-in authentication also redirects all HTTP requests to HTTPS, regardless of
the app's HTTPS Only setting.