Azure Functions 4

Use these rules for Azure Functions runtime 4. Apply the relevant language and framework security guidance alongside these rules. Treat each trigger, managed identity, binding, warm instance, and downstream resource as a distinct trust boundary.

Workload identity

• Use managed identity for Azure resources and avoid embedded client secrets, certificates, and storage keys.
• Assign a dedicated identity to each trust boundary with only required data-plane and management-plane roles; use separate function apps for functions requiring different privileges.
• Separate deployment, runtime, administration, and emergency identities.
• Scope role assignments to exact resources, subscriptions, resource groups, and operations.
• Prevent request data from selecting tenant IDs, client IDs, credential chains, subscriptions, or resource endpoints.

Function and host authorization

• Set HTTP authLevel explicitly: anonymous requires no Functions key, function accepts a function/host key, and admin requires the _master key.
• Test authorization after deployment; Core Tools disables key authorization locally unless --enableAuth is used, while local containers enforce authLevel.
• Prefer platform authentication or an API gateway for users and validate tokens again at sensitive boundaries.
• Treat function, host, system, and _master keys as shared credentials; _master grants administrative runtime API access and must never be an application authentication token.
• Rotate or delete access keys explicitly when revoking access; deleting and recreating a function can