8.2 Azure Front Door, CDN Caching & TLS for App Service and API Management
Key Takeaways
- Origins must reject direct traffic: filter on the X-Azure-FDID header and the AzureFrontDoor.Backend service tag, or use a Private Link origin on Front Door Premium.
- Front Door Premium adds Private Link origins, Microsoft-managed rule sets, bot protection, and threat intelligence over what Standard offers.
- App Service hardening means HTTPS Only, a minimum TLS version of 1.2 or higher, and client certificate mode set to Required when mutual TLS is needed.
- API Management enforces identity at the gateway with validate-jwt for OAuth 2.0 tokens and validate-client-certificate for mutual TLS.
- Subscription keys authenticate a caller to an API Management product but are not an identity control and should sit behind JWT validation.
Azure Front Door as a Security Boundary
Azure Front Door is Microsoft's global layer 7 entry point: anycast edge points of presence terminate TLS close to the user, apply the edge WAF, cache static content, and route to the healthiest origin. Content delivery network (CDN) caching is now part of the Front Door Standard and Premium product rather than a separate service — Azure CDN from Edgio has been retired and the classic profiles are on a retirement path, so new designs should target Front Door Standard or Premium.
| Capability | Standard | Premium |
|---|---|---|
| Static and dynamic acceleration, caching, custom domains | Yes | Yes |
| WAF custom rules (rate limiting, geo-filter, match rules) | Yes | Yes |
| Microsoft-managed rule sets (DRS) and bot protection | No | Yes |
| Private Link origins | No | Yes |
| Threat intelligence–backed protections | No | Yes |
Front Door also absorbs volumetric attacks at the edge: the platform includes always-on infrastructure DDoS protection, and Azure DDoS Network Protection can cover the origin's public IPs.
The Origin Bypass Problem
Putting a WAF at the edge accomplishes nothing if an attacker can resolve the origin's own hostname and hit it directly. Every Front Door design must close that path, in increasing order of strength:
- Header filter. Front Door injects
X-Azure-FDIDcontaining your profile's unique identifier. Configure the origin to reject requests without your exact FDID value. On App Service this is an access restriction rule; on Application Gateway or an NVA it is a header match rule. - Service tag filter. Restrict inbound traffic to the
AzureFrontDoor.Backendservice tag so only Front Door's edge address space can connect. Note that this tag covers all Front Door tenants, which is exactly why it must be combined with the FDID header check rather than used alone. - Private Link origin (Premium). Front Door connects to the origin over a Private Link connection that you approve, and the origin needs no public endpoint at all. This is the strongest answer whenever the scenario says the origin must not be publicly reachable.
Additional edge controls worth knowing: rate limiting custom rules to blunt credential stuffing, geo-filtering to block countries you do not serve, rules engine actions to strip or add security headers, and managed certificates with automatic renewal for custom domains (or bring-your-own from Key Vault).
TLS for Azure App Service
App Service hardening is a short, high-yield checklist:
| Setting | Secure value | Why |
|---|---|---|
| HTTPS Only | On | Redirects all HTTP to HTTPS; without it, plaintext requests are served |
| Minimum inbound TLS version | 1.2 (1.3 where supported) | Blocks TLS 1.0/1.1 negotiation outright |
| Minimum outbound TLS version | 1.2 | Governs the app's own calls |
| Client certificate mode | Required for mutual TLS; Optional/Allow for gradual rollout | Enables client certificate authentication; the certificate arrives at the app in the X-ARR-ClientCert header |
| FTP state | Disabled, or FTPS only | Plain FTP deployment credentials are a standing credential leak |
| SCM/Kudu access restrictions | Locked to admin ranges or private endpoint | The deployment site is a full remote console |
Certificates come from three sources: App Service managed certificates (free, auto-renewed, for custom domains with limits), App Service certificates, or Key Vault certificates referenced by the app. TLS bindings use SNI SSL by default (no dedicated IP required); IP-based SSL exists for legacy clients that cannot do SNI.
Securing Azure API Management
API Management (APIM) is a policy-driven gateway, so most controls are policies applied at global, product, API, or operation scope.
| Requirement | Policy or setting |
|---|---|
| Validate an OAuth 2.0 / OpenID Connect access token | validate-jwt — check issuer, audience, signing keys, required claims |
| Require a client certificate (mutual TLS) | validate-client-certificate, plus certificate upload or Key Vault reference |
| Restrict callers by network | ip-filter policy, or VNet injection / private endpoint |
| Throttle abuse | rate-limit-by-key and quota-by-key |
| Hide backend credentials | Named values backed by Key Vault, or a managed identity authenticating to the backend |
| Remove information disclosure | set-header to strip server and diagnostic headers; disable the developer portal if unused |
| Ban weak protocols | Disable TLS 1.0/1.1 and 3DES in the gateway's protocol and cipher settings |
Two ideas that the exam likes to separate:
- Subscription keys are not authentication. A subscription key identifies a subscription to a product, is passed in
Ocp-Apim-Subscription-Key, and leaks as easily as any static string. Real identity comes fromvalidate-jwtagainst Microsoft Entra ID or from client certificates. A hardened API uses both: the key for product metering, the token for identity. - Network placement. Classic Developer and Premium tiers support virtual network injection in External mode (public VIP, VNet-reachable backends) or Internal mode (gateway reachable only inside the VNet). Newer v2 tiers support private endpoints for inbound and VNet integration for outbound. When a scenario demands "no public gateway endpoint", Internal-mode injection or a private-endpoint-only configuration is the answer, and a self-hosted gateway is the answer for APIs that must stay on-premises while still being managed centrally.
A web application sits behind Azure Front Door Premium with WAF in Prevention mode, yet penetration testers bypass the WAF entirely by sending requests straight to the App Service default hostname. What is the strongest remediation?
An API exposed through Azure API Management must accept only calls carrying a valid Microsoft Entra ID access token with a specific audience claim. Which policy implements this at the gateway?
Which combination correctly hardens an Azure App Service that must be reachable only over modern TLS and must authenticate callers with client certificates?