# CAPTCHA challenge is enabled in Azure Front Door WAF
Azure Front Door Web Application Firewall (WAF) supports CAPTCHA challenge as a defense mechanism against sophisticated bots and automated tools across…
Source: https://maester.dev/docs/tests/ZTA.27020
## Overview
Azure Front Door Web Application Firewall (WAF) supports CAPTCHA challenge as a defense mechanism against sophisticated bots and automated tools across the global edge network. CAPTCHA challenge works by presenting users with a visual or audio puzzle that requires human cognitive ability to solve, proving that the request originates from a real human rather than an automated bot or script. When a request triggers a CAPTCHA challenge, the WAF responds with a challenge page containing the CAPTCHA puzzle that the user must solve to obtain a valid challenge cookie. If the user successfully completes the CAPTCHA, subsequent requests proceed normally until the cookie expires. Bots and automated tools that cannot solve the CAPTCHA puzzle are blocked from accessing protected resources at the edge before traffic reaches origin servers. CAPTCHA challenge is more effective than JavaScript challenge against advanced bots that use headless browsers with full JavaScript support, as it requires human-level cognition to pass. The `captchaExpirationInMinutes` setting in the policy controls how long the CAPTCHA cookie remains valid before the user must complete another challenge. CAPTCHA challenge provides the strongest level of interactive verification available in Azure Front Door WAF—it confirms human presence through an interactive puzzle rather than only verifying browser capability like JavaScript challenge. By configuring custom rules with CAPTCHA challenge action on Azure Front Door WAF, organizations can protect highly sensitive endpoints like login pages, registration forms, password reset flows, and payment pages from automated abuse while ensuring that only verified humans can access these resources across globally distributed edge locations.
## Remediation
- [Azure Web Application Firewall on Azure Front Door](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview)
- [Web Application Firewall custom rules for Azure Front Door](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-custom-rules)
- [Tutorial: Create a Web Application Firewall policy on Azure Front Door](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-create-portal)
- [Configure CAPTCHA challenge for Azure Front Door WAF](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-tuning#captcha-challenge)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | Medium |
| Effort to fix | Low |
| Impact on users | Medium |
| Pillar | Network |
| Category | Azure Network Security |
| Product | [Azure](/docs/tests/products/azure) |
| Feature | Network security |
| Area | Infrastructure hardening |
| ATT&CK | [T1110.004](/docs/tests?mitre=T1110.004) Credential Stuffing |
| Licence | Azure WAF |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.