Locking Down App Gateway Behind Front Door
contoso.com is served by two WAF_v2 Application Gateways - one in East US, one in West Europe - each with a public listener and its own public IP. Azure Front Door Premium with a WAF policy in Prevention mode sits in front; the origin group contains both App Gateway public IPs. After a security review, an NSG was added to the App Gateway subnets allowing inbound 443 only from the AzureFrontDoor.Backend service tag. Since then: about 4% of requests return 403 from the App Gateway WAF, the matched rule is a rate-limit rule keyed on client IP; application logs show a Front Door edge IP as the client for every request; and the penetration test still reaches the origin directly by IP. Product also needs /legacy/* served only by the East US deployment.
1. Explain the 403s and where rate limiting belongs in this stack.
Read the worked answer
The 403s are an artefact of moving rate limiting behind a proxy.
Front Door terminates the client TCP connection and opens a new connection to the App Gateway. Every request therefore arrives at the App Gateway from a small set of Front Door edge IPs, so a rate-limit rule keyed on the App Gateway's view of the source IP buckets thousands of unrelated users together and trips at low volume. The ~4% figure is not random traffic - it is the busiest shared edge.
Correct placement:
- Enforce rate limiting at Front Door, which sees the real client IP and is the first hop. Use Front Door WAF rate-limit rules with a sensible window.
- Keep the App Gateway WAF policy for attack signatures (or Detection mode) and remove/adjust the IP-keyed rate rule there. Running Prevention at both layers doubles false positives and makes triage ambiguous.
- For real client IP, Front Door adds X-Azure-ClientIP and X-Forwarded-For; configure the application or App Gateway custom rules to read those headers, and never trust a client-supplied X-Forwarded-For without the Front Door header check.
Verification: compare the Front Door WAF log's clientIP against the App Gateway WAF log's clientIP for the same tracking reference.
2. The service tag alone does not satisfy the penetration test. Explain why, and give a design that makes the App Gateway unreachable except through Contoso's own Front Door profile.
Read the worked answer
Why the NSG is insufficient: AzureFrontDoor.Backend is a shared service tag. It allows every Front Door profile on the planet, so an attacker with any Front Door profile can front the origin. It restricts the network path, not the identity of the caller.
Options, in increasing strength:
- NSG service tag + X-Azure-FDID header validation. Front Door sends X-Azure-FDID with the profile's front door ID. Allow the tag at the NSG and reject any request at the App Gateway whose header does not equal the expected GUID (custom WAF rule or a rewrite/redirect rule). Effective, but the origin IP remains internet-reachable and discoverable.
- Private origin via Private Link (recommended). Front Door Premium supports Private Link origins. Expose the App Gateway through a Private Link service (or use an internal App Gateway with a Private Link service in front of it), then disable the public listener / remove the public IP path entirely. The origin has no public exposure, so the penetration-test finding disappears.
- IP allowlist on the origin - brittle; Front Door edge IPs change and this is explicitly unsupported as a security boundary.
If Private Link is not feasible this quarter, implement option 1 plus a deny-by-default NSG and record the residual risk; do not treat the service tag as an authentication control.
3. Design the routing so /legacy/* is served only by East US, without breaking regional failover for everything else.
Read the worked answer
Use Front Door path-based routing with two origin groups, not App Gateway path rules alone.
- Origin group
og-global: both App Gateways, health probes on /health, latency-based or weighted. - Origin group
og-legacy: East US App Gateway only (single origin so no cross-region failover by design). - Route:
/*-> og-global,/legacy/*-> og-legacy, with the /legacy route having higher route specificity (longest match wins).
Consequences to state:
/legacy/*loses regional resilience - failover for it must be handled inside East US (App Gateway multi-site listener to a secondary site, or a standby region promoted by a config change). Get this accepted explicitly.- Keep cache behaviour separate: do not cache /legacy responses at the Front Door edge if the legacy app is per-user, or you will serve one user's response to another.
- App Gateway must still receive the /legacy path unchanged (no path rewrite stripping the prefix) or backend routing will 404.
- Health probes should target a path that exists in both deployments so og-global and og-legacy do not flap on the same signal.