Azure Front Door works as a global entry point and Content Delivery Network (CDN) that delivers web content quickly and securely to users around the world. When you integrate it with Azure Static Web Apps, you have two deployment options. The first option, enterprise-grade edge, provides zero configuration changes, no downtime during setup, and automatic SSL certificate management along with custom domain handling. The second option, manual Azure Front Door setup, gives you full control over routing rules, caching behavior, and security policies, though it requires more configuration work. Choosing between them depends on whether you need quick deployment with minimal management or detailed control over how traffic flows.
When you manually create an Azure Front Door profile, you define several interconnected settings that work together. You select an origin type, which could be a Static Web App or another backend service, and this determines where Front Door forwards requests it cannot serve from its cache. You configure caching and compression settings to speed up content delivery by storing copies of files closer to users and reducing file sizes during transfer. You also set query string caching behavior, which controls how Front Door treats URLs that include parameters like "?id=123", and you attach a Web Application Firewall (WAF) policy that contains managed or custom rules to block malicious traffic before it reaches your origin. These components form a pipeline: the WAF filters requests first, caching serves what it can, and the origin receives only traffic that passes both checks.
Certain traffic must never be cached because it contains sensitive authentication data. Azure Front Door lets you disable caching for these routes using the Rule Set feature. You create a rule that matches any request path beginning with /.auth, which covers built-in authentication endpoints, and then you add an action that overrides the route configuration to disable caching. This rule must be associated with your endpoint to take effect. The reason this matters is that caching authentication endpoints would cause users to receive stale or shared credentials, which would create serious security vulnerabilities. By forcing these requests to reach the origin every time, you ensure each user gets their own authenticated session.
Your backend origin should only accept traffic that comes through your Front Door instance, not direct requests from the public internet. You enforce this trust boundary in two ways. First, in your staticwebapp.config.json file, you set allowedIpRanges to include only "AzureFrontDoor.Backend", which tells Azure to accept connections only from Front Door's IP addresses. Second, you configure the forwardingGateway setting to require a custom header called X-Azure-FDID containing your specific Front Door ID, and you list your allowed forwarded hosts as your azurefd.net domain and any custom domains you have configured. Together, these settings create a gate that rejects any request unless it originates from your Front Door and carries the correct identification header, preventing attackers from bypassing the CDN and WAF entirely. This setup also works alongside Azure DDoS Protection to provide defense in depth against volumetric attacks at the network edge.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills

Prepare and test your skills

The enterprise-grade edge option requires zero configuration changes, involves no downtime during setup, and provides automatic SSL certificate and custom domain management. In contrast, a manual Azure Front Door setup requires more configuration work but grants full control over routing rules, caching behavior, and security policies.
You disable caching for sensitive endpoints by using the Azure Front Door Rule Set feature to create a rule that matches request paths beginning with /.auth. You then add an action that overrides the route configuration to disable caching and associate the rule with your endpoint. This prevents security vulnerabilities like serving stale or shared credentials by ensuring authentication requests always reach the origin.
You lock down the origin by updating its staticwebapp.config.json file to set allowedIpRanges to AzureFrontDoor.Backend so it only accepts connections from Front Door IP addresses. Additionally, you configure the forwardingGateway setting to require the X-Azure-FDID header with your specific Front Door ID and list your allowed forwarded host domains. These combined settings ensure direct public internet requests are rejected and cannot bypass the Web Application Firewall (WAF) or CDN.