# Rate Limiting is Enabled in Azure Front Door WAF
Azure Front Door Web Application Firewall (WAF) supports rate limiting through custom rules that restrict the number of requests clients can make within a…
Source: https://maester.dev/docs/tests/ZTA.27018
## Overview
Azure Front Door Web Application Firewall (WAF) supports rate limiting through custom rules that restrict the number of requests clients can make within a specified time window across the global edge network. Rate limiting is a critical defense mechanism that protects applications from abuse by throttling clients that exceed defined request thresholds before traffic reaches origin servers.
Without rate limiting configured, threat actors can execute brute force attacks, credential stuffing attacks, API abuse, and application-layer denial of service attacks that flood endpoints with requests to exhaust server capacity.
Rate limiting rules use the `RateLimitRule` rule type and allow administrators to define thresholds based on request count per minute, with the ability to group requests by client IP address. When a client exceeds the configured threshold, the WAF can block subsequent requests, log the violation, issue a CAPTCHA challenge, or redirect to a custom page.
This check identifies Azure Front Door WAF policies that are attached to an Azure Front Door and verifies that at least one rate limiting rule is configured and enabled.
## 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)
- [Rate limiting for Azure Front Door WAF](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit)
- [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)
## 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 | High |
| Effort to fix | Medium |
| Impact on users | Low |
| Pillar | Network |
| Category | Azure Network Security |
| Product | [Azure](/docs/tests/products/azure) |
| Feature | Network security |
| Area | Infrastructure hardening |
| ATT&CK | [T1110](/docs/tests?mitre=T1110) Brute Force, [T1499.003](/docs/tests?mitre=T1499.003) Application Exhaustion Flood |
| 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`.