Azure Front Door for ASP.NET Core: A Practical Production Guide

Design for Standard or Premium, not Classic

Azure Front Door Classic is on a retirement path. New architecture should use Standard or Premium and verify required WAF, Private Link, origin and rule-set capabilities in the chosen tier. Treat migration as a behaviour change: host headers, caching and probes can alter traffic before application code runs.

The edge contract

Origin host headers must match the destination

Front Door routes by one public host while the origin may expect an App Service hostname or validated custom domain. Configure the origin host header deliberately and ensure TLS certificate validation matches. Changing it also changes what the application sees unless forwarded host is processed.

For absolute links and identity callbacks, prefer a configured canonical public origin when possible. If using forwarded host, validate known hosts and trust only Front Door's path.

Prevent origin bypass

A WAF protects only requests that traverse it. Restrict the origin using Private Link where supported, network controls or validated Front Door identity/header patterns with defence in depth. Do not rely on an obscure App Service hostname.

Remove or overwrite client-supplied forwarding headers at the edge. ASP.NET Core should trust only known proxy hops and process headers before HTTPS redirection, authentication and link generation.

Health probes need a narrow definition

A probe should show whether an instance can safely receive traffic, not whether every remote dependency is perfect. Deep probes can remove all origins during a shared dependency outage, turning degradation into total unavailability.

Use a lightweight unauthenticated endpoint with no side effects and a stable response. Separate liveness, readiness and dependency diagnostics. Account for probe volume across edge locations and avoid expensive database calls per probe.

Caching is representation security

Front Door edge locations cache independently, so some origin traffic remains even with a high hit ratio. Honour origin cache-control and explicitly exclude authenticated, cookie-setting and personalised responses unless the cache key proves isolation.

Query-string behaviour, compression and rule-set transformations affect cache identity. A missing tenant, language or currency dimension can serve the wrong representation globally. Never cache transient 500 responses or identity-specific 404s accidentally.

Routing and failover need application compatibility

Priority routing can fail over regions; weighted routing can canary releases. Both assume origins share compatible data, sessions, keys and contracts. Sending one user between regions with different state is not resilience.

Test failure from the public hostname, including DNS, TLS, WAF and cache. A healthy origin URL does not prove the edge route works. Observe Front Door request IDs alongside application trace context.

TLS has two legs

Manage certificates for client-to-edge domains and secure edge-to-origin transport independently. Renewal, supported protocols and hostname validation apply at both legs. Redirect HTTP at the edge, while letting ASP.NET Core understand the original HTTPS scheme to avoid loops.

Production checklist

• Use Standard/Premium capabilities appropriate to the workload.
• Set and test origin host headers and TLS names.
• Block direct origin access.
• Trust and process forwarded headers before dependent middleware.
• Keep probes cheap and distinguish readiness from diagnostics.
• Cache only representations with complete safe variation.
• Prove regional data and key compatibility before failover.
• Test WAF, routing, caching and origin failure through the public domain.

Forwarded headers define the application's public reality

Behind Front Door, ASP.NET Core sees the proxy connection unless forwarded headers are accepted from trusted proxies. Scheme and host influence redirects, absolute URLs, cookie security and authentication callbacks. Incorrect trust can create loops or let clients spoof public origin.

Configure known proxy or network trust and process forwarded headers early. Do not blindly trust any internet client that supplies X-Forwarded-For or X-Forwarded-Proto. Preserve the chain needed for diagnosis without treating the leftmost address as authenticated identity.

Test generated links and sign-in callbacks through the real edge hostname. Direct-origin tests often miss the exact proxy behaviour production introduces.

WAF policy is application-specific risk control

Managed rules provide a valuable baseline, not proof that the application is safe. Run new or updated rules in detection mode, inspect legitimate traffic and add narrow exclusions for confirmed false positives. Broad exclusions by path or rule group can silently remove protection.

Rate limits should follow abuse and cost boundaries: sign-in attempts, expensive search, uploads and public API clients may need different policies. An edge rate limit reduces load but cannot enforce user or tenant quotas known only to the application.

Log rule, action, route and correlation without storing sensitive request bodies. Give security and application teams a process for reviewing blocks; otherwise operational pressure turns temporary bypasses into permanent policy.

Origin protection must survive deployment changes

Restricting the origin by a static edge address list can be brittle as platform ranges change. Use supported origin validation, private connectivity where appropriate and an application-level check that requests travelled through the intended Front Door profile.

Do not rely only on a header clients can invent unless the origin network prevents direct access or the value is a strong secret managed safely. Test slot and regional origins too; a forgotten default hostname can bypass WAF, caching and TLS policy.

Health probes require access without opening the whole origin. Keep the probe endpoint narrow and non-sensitive while enforcing edge access on normal routes.

Caching changes correctness and security

Cache only responses designed for sharing. Authentication cookies, tenant hostnames, language and query variation can change representation. If the cache key ignores one of them, one user's content may be served to another.

Respect explicit cache headers and make invalidation part of publishing. A purge request is asynchronous operational work, not an instantaneous transaction. Versioned asset URLs are safer than relying on emergency purges for every deployment.

Compression and content negotiation also affect variants. Test Vary behaviour and avoid caching error or maintenance responses longer than intended.

Multi-region failover needs data compatibility

Routing traffic to a healthy secondary application does not make the service healthy if its database is stale, its keys differ or external callbacks still target the failed region. Define which dependencies are regional, global or replicated.

Active-passive designs need regular traffic or exercises to expose configuration drift. Active-active requires conflict and session design. Front Door health chooses an origin based on probes; it cannot decide whether business data is safe to write there.

Set probe interval and failover sensitivity against false-positive risk. Aggressive failover can flap between regions during transient faults and worsen an incident.

Deploy routes and edge configuration progressively

Route changes can affect all customers faster than an application deployment. Treat profiles, domains, WAF and rules as version-controlled infrastructure with review and staged validation. Confirm rule priority because a broad route can shadow a specific one.

Use a test hostname or limited route where possible, then monitor origin selection, cache outcomes, WAF blocks and application journeys. A successful configuration deployment only proves Azure accepted the shape.

Have a rollback path for edge rules and certificate changes. DNS caching and certificate issuance mean some changes cannot be reversed instantly.

Observe both legs of the request

Measure client-to-edge and edge-to-origin behaviour separately. Front Door latency can look healthy while the origin is slow, or application telemetry can miss requests blocked at WAF. Correlate edge logs with application traces using a safe request identifier.

Alert on origin health by route and region, rising 4xx/5xx classes, WAF anomalies, cache hit changes and certificate lifecycle. Sampling must not hide low-volume critical endpoints.

The operational question is not merely whether Front Door is reachable. It is whether the correct customer reached the correct origin through the intended security and caching policy.

Related C3 Software guides

• Forwarded Headers in ASP.NET Core Behind a Reverse Proxy
• Zero-Downtime Deployment Strategies for ASP.NET Core
• Designing Reliable Webhooks in ASP.NET Core