Azure Front Door security implementation

Question

Hi everyone,

I'm currently looking into an Azure Front Door setup that sits in front of an Azure-hosted web app, and I need to do a thorough security evaluation. My goal is to figure out if the implementation is actually solid and follows best practices, but I want to make sure I'm not missing any critical checks.

I know the absolute first thing to test is making sure the backend can't be bypassed. I'm planning to try hitting the origin URL directly to ensure it only accepts traffic from the specific Front Door ID (X-Azure-FDID) and the right service tags.

But beyond the basic bypass test, I'd love to hear how you all approach a full audit of this service.

For instance, I want to verify that the WAF is actually blocking threats (Prevention mode) with the right managed rulesets, rather than just logging them. I'm also looking into how to best test the TLS configuration to ensure old protocols are dropped and HTTP is strictly redirected.

I'm also a bit concerned about caching pitfalls, specifically how to check if the setup might accidentally be caching private or authenticated user data, and how to properly validate that rate limiting is effective against brute-force attempts.

Does anyone have a good methodology, a practical checklist, or just some advice on how you go about testing an AFD environment? Are there specific settings or common misconfigurations you always check first?

Answer 1

Hi passione,

Welcome to Microsoft Q&A Platform.

Sounds like you’re putting together a solid security audit plan for Azure Front Door. Here’s a high-level checklist and some practical tips to make sure you cover all the bases:

Origin-bypass protection

• Lock down your app service (or VM) so it only accepts traffic from Front Door’s IP/service tag or your X-Azure-FDID header.
• Try hitting your origin URL directly (bypass the AFD hostname) and verify you get a 403 or no response.
• On App Service, use IP Restrictions or Azure Firewall + AFD service tag; on VMs, use NSGs or Azure Firewall.

WAF validation

• Ensure your WAF policy is in Prevention mode, not just Detection. In the portal under your WAF policy, click “Switch to prevention mode.”
• Confirm you’ve enabled the latest Azure-managed rule set (DRS 2.1 for Premium) plus any custom rules or exclusions you need.
• Run safe attack payloads (e.g. OWASP Juice Shop test scripts) and check that requests are blocked (HTTP 403) and logged in the WAF diagnostic logs. •
• Verify you’re getting alerts or metrics in Azure Monitor/Log Analytics for blocked rules.

TLS / HTTPS enforcement

• Use a custom TLS policy to disable TLS 1.0/1.1 and only allow 1.2+ (or 1.3). You can create a custom policy under “TLS policy” and remove weak ciphers
• Set up an HTTP-to-HTTPS redirect rule in your Front Door routing configuration. Test with curl or a browser: curl -I [http://yourfrontdoor.host] → should get a 301/302 to HTTPS.
• Run an external SSL test (e.g. SSL Labs) against your AFD hostname to confirm only strong protocols/ciphers are allowed.

Caching checks

• Separate static (images, CSS/JS) and dynamic/authenticated routes. Enable caching only on static routes.
• Make a GET request and inspect the response headers: look for x-cache: HIT vs CONFIG_NOCACHE or PRIVATE_NOSTORE. Anything with Authorization: or private data should show NOCACHE.
• Test a login-protected page and ensure it’s never served from cache. You can tweak your route’s “Enable caching” and query-string behaviour or set origin cache headers (Cache-Control: private, no-store).

Rate-limiting efficacy

• Add a WAF rate-limit custom rule with a reasonable threshold (e.g. 100 RPS over 1 min) and set action to Block.
• In prevention mode, simulate a brute-force or spike from a single IP (e.g. for i in {1..200}; do curl …; done) and watch for 429 responses once you hit the threshold.
• Check Azure Monitor alerts or Logs to confirm the rule is firing as expected.

General hygiene & monitoring

• Enable Front Door and WAF diagnostic logs to Log Analytics or Event Hub for continuous monitoring.
• Use Azure Advisor recommendations (the “Secure Azure Front Door deployment” guidance) to catch any overlooked settings.
• Regularly validate your config after any changes—consider automating checks with something like Azure CLI scripts or Bicep/ARM tests.

Putting it all together as a “pentest checklist” makes it easy to repeat on every audit:

• Origin direct-hit blocked (service tag / FDID only)
• WAF in Prevention, DRS + custom rules enabled
• WAF test payloads blocked + logged
• HTTP→HTTPS redirect in place
• TLS policy excludes old versions, ciphers tested
• Static vs dynamic routes separated for caching
• x-cache and Cache-Control headers verified
• Rate-limit rule triggered at threshold, 429s seen
• Diagnostic logs streaming + alerts configured

References: https://learn.microsoft.com/azure/well-architected/service-guides/azure-front-door#security https://learn.microsoft.com/azure/web-application-firewall/afds/waf-front-door-best-practices https://learn.microsoft.com/azure/frontdoor/secure-front-door https://learn.microsoft.com/azure/frontdoor/standard-premium/tls-policy-configure#configure-tls-policy https://learn.microsoft.com/azure/frontdoor/front-door-how-to-redirect-https#create-forwarding-rule https://learn.microsoft.com/azure/frontdoor/front-door-caching https://learn.microsoft.com/azure/web-application-firewall/afds/waf-front-door-rate-limit

Pleaseand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

Answer 2

Sorry, I can't help with this. Please make a new request or share your feedback.