Secure your Azure Front Door deployment

Azure Front Door is a cloud content delivery network (CDN) and global application delivery service that provides edge routing, acceleration, web application firewall (WAF), and origin protection capabilities for internet-facing applications. Because Azure Front Door is commonly the public entry point for applications, secure configuration helps protect traffic, origins, certificates, and operational telemetry.

This article provides security recommendations to help protect your Azure Front Door deployment.

Network security

Network security for Azure Front Door focuses on protecting applications at the edge, reducing direct origin exposure, and controlling the requests that can reach your backend services.

  • Secure origins with Private Link: Use Azure Front Door Premium with Azure Private Link for supported Azure origins to keep origin traffic off the public internet and reduce exposure to direct attacks against backend services. For more information, see Secure your origin with Private Link in Azure Front Door.

  • Restrict direct origin access: Configure origins to accept traffic only from Azure Front Door by using supported controls for each origin type, such as Private Link, managed identity origin authentication for non-Private Link origins, IP filtering with the AzureFrontDoor.Backend service tag, and validation of the X-Azure-FDID header. For more information, see Secure traffic to Azure Front Door origins.

  • Enable Web Application Firewall: Associate a WAF policy with Azure Front Door to inspect requests at the edge before traffic reaches your origin. Use Azure Front Door Premium when you need managed rule sets and full WAF capabilities. For more information, see Web Application Firewall on Azure Front Door.

  • Use the latest managed Default Rule Set: Keep Premium WAF policies on the latest available Default Rule Set (DRS) 2.x version and validate rule changes before production rollout. DRS 2.2 is based on OWASP Core Rule Set (CRS) 3.3.4 and includes Microsoft Threat Intelligence protections. For more information, see Azure Web Application Firewall DRS rule groups and rules.

  • Tune WAF before enforcing blocks: Start with detection mode, review WAF logs, add exclusions only where required, and then switch production policies to prevention mode so malicious requests are blocked. For more information, see Best practices for Azure Web Application Firewall in Azure Front Door.

  • Enable bot protection: Add the Bot Manager rule set to Premium WAF policies to identify good, bad, and unknown bots and apply appropriate actions for automated traffic. For more information, see Configure bot protection for Web Application Firewall with Azure Front Door.

  • Use rate limiting to reduce abuse: Configure WAF rate limiting custom rules to block abnormal request volumes by socket IP address and to reduce retry storms or application-layer denial-of-service attempts. For more information, see WAF rate limiting for Azure Front Door.

  • Apply geo-filtering where access is region-bound: Use WAF geo-filtering custom rules when your application should only be available from specific countries or regions. Include the unknown (ZZ) location in rule design to avoid false positives. For more information, see Geo-filtering on a domain for Azure Front Door.

  • Use built-in DDoS protections at the edge: Rely on Azure Front Door's global edge network and WAF integration to absorb and filter many network and application-layer attacks before they reach your origins. For more information, see DDoS protection on Azure Front Door.

Identity and access management

Identity and access management for Azure Front Door focuses on using Microsoft Entra identities instead of secrets and limiting who can change edge routing, WAF, certificate, and origin settings.

  • Enable managed identities for service access: Use system-assigned or user-assigned managed identities so Azure Front Door can access Azure resources such as Key Vault without stored credentials. For more information, see Use managed identities in Azure Front Door.

  • Use managed identities for origin authentication (preview): For supported non-Private Link origins, configure Azure Front Door origin authentication with managed identities so Front Door can obtain Microsoft Entra tokens and authenticate to protected backend resources. This capability is in preview; validate that preview features meet your production requirements before adopting.

  • Grant least privilege to Front Door identities: Assign only the roles required for the origin or certificate scenario, such as read-only data access to a storage origin or certificate access to Key Vault. Don't assign broad Contributor permissions to managed identities.

  • Limit administrative access to Front Door resources: Assign Azure role-based access control (Azure RBAC) roles only to administrators who need to manage profiles, endpoints, domains, routes, origins, and WAF policies. Review role assignments regularly and remove stale access. For more information, see Steps to assign an Azure role.

  • Use eligible access for privileged operations: Require just-in-time activation for users who can change production Front Door profiles, WAF policies, custom domains, and origin settings. For more information, see Activate Azure resource roles in Privileged Identity Management.

Data protection

Data protection for Azure Front Door focuses on encrypting traffic, protecting certificates and keys, and avoiding unintended exposure of sensitive content through edge features.

  • Use end-to-end TLS: Configure HTTPS from clients to Azure Front Door and from Azure Front Door to origins so traffic remains encrypted across the full request path. For more information, see End-to-end TLS with Azure Front Door.

  • Configure current TLS policies: Use the newest predefined TLS policy or a custom TLS policy that meets your security requirements for minimum protocol versions and cipher suites. For more information, see Azure Front Door TLS policy.

  • Don't rely on Front Door for client certificate authentication: Front Door Standard and Premium don't currently support client or mutual authentication (mTLS). If your workload requires mTLS, implement that control at an origin or alternate ingress layer and validate the complete request path. For more information, see Azure Front Door TLS policy.

  • Manage certificates in Azure Key Vault: Store customer-managed TLS certificates in Key Vault, use a managed identity for access, enable automatic certificate renewal where applicable, and protect the vault with soft-delete and purge protection. For more information, see Configure HTTPS on an Azure Front Door custom domain and Azure Key Vault soft-delete overview.

  • Don't cache sensitive content: Configure caching rules carefully so private, authenticated, or regulated content isn't stored at the edge unintentionally. Use cache-control headers and route-level caching settings appropriate for your data classification. For more information, see Caching with Azure Front Door.

  • Protect sensitive data in WAF logs: Use WAF sensitive data protection to reduce exposure of sensitive values in WAF logs when your policy inspects requests that might contain secrets or personal data. For more information, see Sensitive data protection for Azure Web Application Firewall on Azure Front Door.

Compliance and governance

Compliance and governance for Azure Front Door help ensure consistent configuration, controlled change management, and auditable security posture across profiles and subscriptions.

  • Define Front Door configuration as code: Manage profiles, endpoints, routes, origins, WAF associations, and security settings by using Bicep, Azure Resource Manager templates, Terraform, or another infrastructure as code process. This approach reduces configuration drift. For more information, see Create an Azure Front Door using Bicep.

  • Version WAF policy changes: Store WAF custom rules, exclusions, managed rule set versions, and policy settings in source control. This practice ensures that rule tuning and rule set upgrades can be reviewed, tested, and rolled back. For more information, see Best practices for Azure Web Application Firewall in Azure Front Door.

  • Review configuration changes: Use activity logs and diagnostic data to track changes to Front Door profiles, routes, origins, custom domains, and WAF policies. Investigate unexpected changes as potential security events. For more information, see Monitor Azure Front Door.

  • Standardize origin security requirements: Apply consistent requirements for Private Link, managed identity origin authentication, X-Azure-FDID validation, and allowed host names across all application origins. For more information, see Secure traffic to Azure Front Door origins.

  • Document high-availability exceptions: If a disaster recovery design requires alternate ingress paths that can't use Azure Front Door Private Link or X-Azure-FDID validation, document compensating controls such as token-based origin authentication, custom headers, mTLS at the alternate ingress, or IP filtering. For more information, see High-availability implementation guide for using Azure Front Door and alternate ingress solutions.

Backup and recovery

Backup and recovery for Azure Front Door focus on preserving configuration, keeping alternate origins available, and validating failover paths before an outage occurs.

  • Manage Front Door configuration as infrastructure as code: Define and version Azure Front Door profiles, endpoints, routes, origin groups, custom domains, and WAF associations in Bicep or ARM templates stored in a source-controlled repository. Treat that repository as the source of truth for recovery. Use policy or template export as a bootstrap or point-in-time snapshot, not as the ongoing source of truth. For more information, see Create an Azure Front Door using Bicep and Export template from the Azure portal.

  • Keep configuration in version control: Store Front Door, WAF, certificate, and origin configuration as infrastructure as code and require review for production changes. Version control provides rollback points and supports recovery into another subscription or resource group. For more information, see Bicep best practices.

  • Configure multiple origins for failover: Use origin groups with multiple backends and set priority, weight, and latency settings to support active-active or active-passive failover patterns. For more information, see Traffic routing methods to origin.

  • Configure health probes correctly: Use HTTP or HTTPS health probes that validate a meaningful application health endpoint, and tune sample size and successful samples required so Front Door can detect unhealthy origins without excessive failover sensitivity. For more information, see Health probes.

  • Deploy globally redundant origins: Run origin services in multiple Azure regions or hosting locations and use Azure Front Door load balancing, or Traffic Manager where appropriate, to route users to healthy regions during origin or regional failures. For more information, see Traffic routing methods to origin and Azure Traffic Manager.

  • Plan alternate ingress for catastrophic recovery: For mission-critical applications, maintain a tested alternate ingress path, such as Application Gateway WAF or an alternate CDN with Traffic Manager, so you can route around rare Azure Front Door availability or control-plane incidents. For more information, see High-availability implementation guide for using Azure Front Door and alternate ingress solutions.

  • Test failover regularly: Simulate origin failures, regional outages, certificate renewal failures, and alternate ingress activation in non-production and production-safe drills. Validate failover, failback, logging, WAF behavior, and runbooks. For more information, see High-availability implementation guide for using Azure Front Door and alternate ingress solutions.

Next steps

  • Last updated on