Microsoft Defender for Cloud · Azure Functions
Authentication should be enabled on API endpoints hosted in Function Apps (Preview)
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Authentication should be enabled on API endpoints hosted in Function Apps (Preview)" check?
This Defender for Cloud finding, part of the Defender for APIs posture coverage, inspects API endpoints that Defender has catalogued inside your Function Apps and flags any endpoint that does not enforce an authentication requirement. It looks at whether the platform rejects unauthenticated callers, typically through App Service Authentication (the built-in 'Easy Auth' module) or an equivalent gateway in front of the app. It does not inspect authorisation logic inside your function code, it does not validate that scopes or app roles are correct, and it does not cover the host-key or function-key model, which the recommendation treats as shared secrets rather than identity. This is a Preview control and depends on Defender CSPM or the Defender for APIs plan being enabled to discover the endpoints in the first place.
Why does "Authentication should be enabled on API endpoints hosted in Function Apps (Preview)" matter?
An unauthenticated function endpoint is a public API: anyone who can reach the URL can invoke it. Functions are frequently wired straight to databases, queues, storage and downstream systems, so a single open endpoint can leak records, trigger expensive processing, or become a pivot into the rest of the environment. Because function keys travel in query strings and end up in logs, browser history and shared scripts, they are a weak substitute for proper identity. The business consequence is direct: data exposure, fraudulent or runaway invocation that inflates your bill, and a control gap that fails most regulatory baselines. Enforcing platform authentication closes the endpoint to the open internet before a request ever reaches your code.
How do I fix "Authentication should be enabled on API endpoints hosted in Function Apps (Preview)"?
- Add an identity provider in the portal under your Function App, Settings, Authentication, Add identity provider, choosing Microsoft as the provider so callers must present a valid Microsoft Entra ID token.
- Set the unauthenticated request behaviour to return 401 rather than allow anonymous access. From the CLI: az functionapp auth update --name <app> --resource-group <rg> --enabled true --unauthenticated-client-action RejectWith401 (add the authV2 extension first with az extension add --name authV2 if prompted).
- Bake this into deployment so it cannot regress: in Bicep set the sites/config 'authsettingsV2' resource with globalValidation.requireAuthentication = true and unauthenticatedClientAction = 'Return401', then redeploy the module for every function app.
Remediation script · bash
# Close the highest-impact Function app exposure first: wildcard CORS, remote
# debugging, weak TLS, and missing client certificates, app by app.
RG=my-rg
APP=ordersapiprod
# 1. Replace wildcard CORS with the origins that actually call the app.
az functionapp cors remove -g "$RG" -n "$APP" --allowed-origins "*"
az functionapp cors add -g "$RG" -n "$APP" \
--allowed-origins https://app.contoso.com https://admin.contoso.com
# 2. Turn off remote debugging and require modern TLS.
az functionapp config set -g "$RG" -n "$APP" \
--remote-debugging-enabled false \
--min-tls-version 1.2
# 3. Require incoming client certificates where the app expects them.
az functionapp update -g "$RG" -n "$APP" \
--set clientCertEnabled=true --set clientCertMode=Required
# 4. Put App Service Authentication (Easy Auth) in front of an HTTP-triggered app
# so anonymous callers are rejected before they reach your code.
az webapp auth update -g "$RG" -n "$APP" \
--enabled true \
--action LoginWithAzureActiveDirectory \
--aad-client-id "$CLIENT_ID" \
--aad-token-issuer-url "https://sts.windows.net/$TENANT_ID/"
# 5. Ratchet it shut: audit any future app that ships without authentication.
# Look the built-in policy up by its exact display name, never hardcode the GUID.
pid=$(az policy definition list \
--query "[?displayName=='Function apps should have authentication enabled'].name" -o tsv)
az policy assignment create \
--name audit-funcapp-auth \
--policy "$pid" \
--scope "/subscriptions/00000000-0000-0000-0000-000000000000" Full walkthrough (console steps, edge cases and verification) in the lesson Harden Azure Function apps.
Is "Authentication should be enabled on API endpoints hosted in Function Apps (Preview)" a false positive?
A function that is intended to be a public, unauthenticated webhook receiver, for example a payment-provider or GitHub callback that authenticates each request by verifying an HMAC signature in code, will still flag because platform authentication is off by design. That is a legitimate exception: confirm the in-code signature check is enforced, then suppress or exempt the specific endpoint rather than enabling Easy Auth, which would reject the third party's unsigned-token requests.
More Azure Functions controls
- CORS should not allow every resource to access Function Apps
- FTPS should be required in function apps
- Function apps should have Client Certificates (Incoming client certificates) enabled
- Remote debugging should be turned off for Function App
- TLS should be updated to the latest version for function apps
- Unused API endpoints should be disabled and removed from Function Apps (Preview)