Azure Functions access keys stop casual access to an HTTP trigger, but they identify a shared secret, not a person or a service. Microsoft's guidance is that the only way to truly secure endpoints is positive authentication of clients, so that authorization decisions can be based on identity. Keys are a first layer, not the whole design.
What keys do
Unless you set the HTTP access level of a function to anonymous, requests must include an access key. The key is a shared string. Anyone who holds it can call the function, and the function cannot tell who they are. Keys get pasted into scripts, tickets and browser code, and rotating them means updating every caller.
The documentation puts it directly: access keys can help prevent unwanted access, but the way to truly secure your endpoints is to implement positive authentication and make authorization decisions based on identity.
Microsoft's ladder of options
The security guidance lists techniques for public HTTP endpoints, ordered from basic to most restrictive:
- Require HTTPS, and the latest TLS version.
- Require access keys.
- Enable App Service Authentication and Authorization, which uses Microsoft Entra ID and other identity providers.
- Use Azure API Management to authenticate requests, and restrict the function app to accept traffic only from the API Management address.
- Deploy the function app to a virtual network.
- Deploy it in isolation, for example in an App Service Environment.
Use the lowest rung that matches the sensitivity of the data and the caller. A webhook from a known service may be fine with a key plus IP restrictions. An endpoint that returns customer records needs identity.
The admin endpoints
Function apps can expose administrative endpoints under the admin route, for status information and test invocations. Requests to them must carry the app's master key. The documentation tells you how to disable them with the functionsRuntimeAdminIsolationEnabled site property. If you do not use them, turn them off.
Related settings people forget
- CORS. A wildcard in the allowed origins list defeats the purpose of CORS. List the specific domains instead.
- FTP. Each function app has an FTP endpoint enabled by default. If you are not using it, disable it. If you are, enforce FTPS.
- Remote debugging. Keep it off except when actively debugging.
- The scm endpoint. It handles deployments and advanced tools, so account for it when you isolate the app on a network.
A review checklist
- List every HTTP triggered function and its authorization level.
- For each anonymous one, record why.
- For each key based one, decide who holds the key and how it rotates.
- For endpoints that touch sensitive data, require identity, not just a key.
- Disable administrative endpoints, FTP and remote debugging that you do not use.
Quick check
Is a function key the same as an API token for a user?
No. It is a shared secret for the endpoint. It does not identify who is calling.
Should I make everything anonymous behind API Management?
Only if you also restrict the function app to accept traffic from the API Management instance. Otherwise callers can bypass it.
If your functions bundle third party packages, Safeguard's free scan can list their known vulnerabilities.
Sources
Last reviewed: 19 October 2026.
