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.

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 LR
    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