Security Best Practices for Azure Functions¶

Security for Azure Functions must align to runtime behavior: triggers execute with app identity, settings are loaded at startup, retries can repeat sensitive operations, and scale-out multiplies blast radius if permissions are broad. This guide provides practical controls for identity, secret handling, app settings, and network hardening.

Why This Matters¶

Default rule: authenticate from Functions to Azure resources using managed identity, not embedded secrets.

Apply managed identity for:

• host and binding storage access where supported,
• Key Vault secret resolution,
• Service Bus, Event Hubs, and Storage SDK clients,
• SQL, Cosmos DB, and other Entra-integrated services.

Why this matters operationally:

• no secret rollover outages from expired connection strings,
• per-resource RBAC scopes reduce breach impact,
• identity usage is auditable through control plane and resource logs.

Portal Walkthrough¶

This section shows the Identity blade for a live Function App (Consumption Y1, Korea Central). PII is masked.

Identity (Managed Identity) Blade¶

[Observed] The Identity blade has System assigned and User assigned tabs. On the System assigned tab, the Status toggle is set to On, and an Object (principal) ID is displayed. The Permissions section provides an "Azure role assignments" button to review RBAC grants for this identity:

[Inferred] With system-assigned managed identity enabled, this Function App can authenticate to Azure resources (Storage, Key Vault, Service Bus, etc.) without connection string secrets. Use the "Azure role assignments" button to verify least-privilege RBAC scopes. If the identity needs to access multiple distinct resource groups, consider whether a user-assigned identity provides better lifecycle management.

Authentication (Easy Auth) Blade¶

[Observed] The Authentication blade shows no identity provider is configured. The "Add identity provider" button is available to enable App Service Authentication:

[Inferred] For HTTP-triggered functions exposed to users, configure Easy Auth instead of relying solely on function keys. Easy Auth validates identity tokens before function code executes, providing per-user claims, conditional access, and audit attribution.

App Keys Blade¶

[Observed] The App keys blade shows the _master and default host keys with hidden values. Each key has "Show value" and "Renew key value" options:

[Inferred] Function keys are shared secrets — treat them as credentials. The _master key should never be exposed publicly. Implement key rotation runbooks and prefer identity-based authentication patterns over keys for production workloads.

Access Control (IAM) Blade¶

[Observed] The Access control (IAM) blade provides tabs for Check access, Role assignments, Roles, and Deny assignments. Cards for granting, viewing, and auditing role assignments are displayed:

[Inferred] Use "View access to this resource" to audit current RBAC assignments for the Function App. Verify that the managed identity has only the minimum roles needed. Use "Add role assignment" to grant data-plane roles (Storage Blob Data Contributor, Key Vault Secrets User, etc.) at resource scope, not subscription scope.

Recommended Practices¶

App settings vs Key Vault references vs environment values¶

Use this decision model:

• Non-sensitive config (feature flags, endpoint names): app settings.
• Sensitive secrets (API keys, passwords): Key Vault reference in app settings.
• Local development values: local environment files not committed to source.

Identity-based connections vs classic secret connections¶

Prefer identity-based setting patterns for supported extensions.

Example pattern for host storage:

• AzureWebJobsStorage__accountName=<storage-account-name>
• AzureWebJobsStorage__credential=managedidentity (or equivalent supported pattern)

Avoid classic secret pattern unless required:

• AzureWebJobsStorage=<connection-string-with-key>

Key Vault reference syntax and common errors¶

Reference format:

@Microsoft.KeyVault(SecretUri=https://<key-vault-name>.vault.azure.net/secrets/<secret-name>/)

Common operational failures:

• typo in secret URI or missing trailing slash behavior mismatch,
• function identity lacks Key Vault get permission,
• vault firewall blocks function outbound path,
• secret version pinned unintentionally and never updated.

Function keys are not complete security¶

Function keys are shared secrets for invocation control, not user identity.

Use auth levels intentionally:

• anonymous: only with compensating controls (Easy Auth, APIM JWT, private network).
• function: shared-secret integration scenarios.
• admin: runtime operations only, never broad exposure.

Why keys alone are insufficient¶

• no per-user identity claims,
• hard to enforce conditional access,
• secret leakage grants direct invocation capability,
• weak audit attribution for caller identity.

Recommended pattern:

1. User-facing APIs: enforce identity token validation (platform or gateway).
2. Service-to-service: managed identity or OAuth token.
3. Keep keys as compatibility fallback, not primary trust boundary.

Identity-based connections and required RBAC¶

For identity-based host and binding access, grant least-privilege roles to Function App identity.

Typical role mappings:

RBAC model for Functions operations¶

Separate operational personas:

• Deployment principal: deploy code/config, no data-plane access unless required.
• Runtime managed identity: data-plane access to dependencies.
• Operations/on-call: monitoring and incident response permissions.

Practical minimums to review:

• deployment identity should avoid Owner where possible,
• runtime identity should avoid general Contributor,
• monitor role assignment drift on app, storage, and Key Vault scopes.

Network security controls that support identity¶

Identity is necessary but not sufficient. Add network boundaries for sensitive workloads.

Core controls:

• access restrictions for approved source IP/ranges,
• private endpoint for private inbound access,
• VNet integration for private outbound dependencies,
• service tags and NSG controls where applicable.

See Platform Security and Platform Networking for design combinations.

CORS done safely¶

CORS only protects browser-origin access behavior; it is not authentication.

Best practices:

• allow only known origins,
• avoid wildcard * in production,
• validate staging and production origin lists independently,
• review CORS when front-end domains change.

TLS and HTTPS enforcement¶

Minimum baseline:

• enforce HTTPS-only on every Function App,
• enforce minimum TLS version 1.2 or higher,
• monitor certificate expiry for custom domains,
• verify redirects and TLS settings after infrastructure changes.

Common Mistakes / Anti-Patterns¶

Secret rotation must be routine, tested, and observable.

Rotation model:

1. Create new Key Vault secret version.
2. Confirm Function App identity can read it.
3. Trigger safe refresh (app restart or configuration refresh workflow as needed).
4. Validate dependency connectivity and auth success metrics.
5. Revoke old secret version according to retention policy.

Operational notes:

• avoid tightly coupled simultaneous rotation for all dependencies,
• rotate high-risk secrets more frequently,
• test rollback path when rotated secret is malformed.

flowchart TD
    A[Create new secret version in Key Vault] --> B[Validate Function managed identity access]
    B --> C{Access check passed}
    C -->|No| R1[Fix RBAC or network path]
    R1 --> B
    C -->|Yes| D[Trigger planned app refresh or restart]
    D --> E[Run dependency authentication smoke tests]
    E --> F{Validation passed}
    F -->|No| G[Rollback to previous secret version]
    F -->|Yes| H[Disable old secret version]
    H --> I[Close rotation change record]

Security boundary and identity flow¶

flowchart TD
    Caller[Client or service caller] --> Ingress[Function endpoint\nHTTP trigger]
    Ingress --> Auth{Auth control}
    Auth -->|"User/API token"| AppAuth[App Service Auth or APIM JWT]
    Auth -->|Function key fallback| KeyGate[Shared key gate]
    AppAuth --> Code[Function execution]
    KeyGate --> Code
    Code --> MI[Managed Identity token request]
    MI --> KV[Key Vault]
    MI --> ST[Storage account]
    MI --> SB["Service Bus / Event Hubs"]
    subgraph NetworkBoundary[Network boundary]
        KV
        ST
        SB
    end

Practical hardening commands (long flags only)¶

Enable managed identity:

az functionapp identity assign \
    --name "$APP_NAME" \
    --resource-group "$RG"

Set HTTPS-only and TLS minimum:

az functionapp update \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --https-only true

az functionapp config set \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --min-tls-version "1.2"

Set Key Vault-backed app setting:

az functionapp config appsettings set \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --settings "DbPassword=@Microsoft.KeyVault(SecretUri=https://$KEYVAULT_NAME.vault.azure.net/secrets/DbPassword/)"

Grant storage data role to managed identity principal:

az role assignment create \
    --assignee-object-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
    --assignee-principal-type "ServicePrincipal" \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.Storage/storageAccounts/$STORAGE_NAME"

Validation Checklist¶

• [ ] Managed identity is enabled and used for supported dependencies.
• [ ] Secret-based connection strings are eliminated or formally exception-tracked.
• [ ] AzureWebJobsStorage uses approved identity-based pattern where supported.
• [ ] Key Vault references are used for sensitive app settings.
• [ ] Function keys are not the only control for sensitive HTTP endpoints.
• [ ] RBAC assignments are least-privilege and scoped narrowly.
• [ ] Access restrictions/private endpoints enforce intended ingress boundary.
• [ ] CORS allowlist contains only approved origins; no production wildcard.
• [ ] HTTPS-only and minimum TLS version policy are enforced.
• [ ] Secret rotation runbook is tested and includes validation/rollback steps.

See Also¶

• Platform Security
• Security Operations
• Configuration Operations
• Networking Best Practices

Sources¶

• Azure Functions security concepts
• Tutorial: Create a function app that connects to Azure services using identities
• Identity-based connections in Azure Functions
• App settings reference for Azure Functions
• Use Key Vault references for App Service and Functions
• Function keys in Azure Functions