Skip to main content
WAF custom rules let you extend the managed/default rule set with targeted, environment-specific protections. Where the managed rule set provides baseline defenses for common web threats, custom rules enable fast, surgical responses to patterns unique to your application — for example blocking an IP range, filtering a country, or applying special header checks.
A slide showing the "Web Application Firewall Custom Rules" interface with an Azure-style screenshot for creating and configuring a custom WAF rule (including the "Add custom rule" form and fields like name, status, conditions and action). Below the screenshot are gray buttons listing topics: Custom Rule Creation, Custom Rule Logic, Rule Actions, Priority and Processing, and Flexible Response.

​
What are custom rules?

Custom rules are administrator-defined match conditions evaluated before the managed/default rule set. Use them to Allow, Block, or Log specific traffic patterns immediately at the edge (Front Door), preventing unwanted requests from reaching your backend. Key characteristics:
  • Evaluated before the managed/default rule set.
  • Priority is numeric; a lower number executes earlier (priority = 1 runs before priority = 2).
  • Useful for immediate, environment-specific controls (IP blocks, geofencing, method restrictions, header checks).
Custom rules provide fast, targeted responses to threats (for example, blocking a specific IP range or country) without waiting for updates to the managed rule set.

​
Common match variables, operators, and actions

Match VariableTypical Use Case
RemoteAddr (IP)Block/allow specific IPs or ranges
GeoLocation / CountryGeofencing: allow/block by country
RequestMethodRestrict HTTP methods (e.g., block DELETE)
QueryStringBlock suspicious query patterns or parameters
RequestHeadersEnforce required headers or block malicious headers
CookiesBlock based on cookie values
RequestBodySizeBlock unusually large request bodies
ActionWhen to use
AllowExplicitly allow known-good traffic that might otherwise match managed rules
BlockImmediately stop malicious or unwanted traffic
LogMonitor suspicious traffic first to validate before blocking

​
Where to apply custom rules

  • Create or edit a WAF policy in the Azure portal.
  • Add custom rules to a policy that also contains the managed rule set.
  • Associate the WAF policy with your Front Door profile to apply rules globally at the edge.
A slide titled "Web Application Firewall Default Rule Set rule groups and rules" showing a UI dialog to "Associate a Front door profile" with fields for front door profile and domain and Add/Cancel buttons. A left-side vertical menu lists steps (Policy Creation, Associate with Front Door — highlighted, Configure Rules, Monitor & Respond).

​
Policy management and monitoring

Within a WAF policy you can:
  • Tune the managed/default rule set (enable/disable rule groups or specific rules).
  • Create multiple custom rules and control their numeric priority.
  • Send WAF logs to Azure Monitor for analytics and alerting.
Logging destinations:
DestinationUse case
Log Analytics WorkspaceQuery logs with Kusto, build dashboards and alerts
Storage AccountLong-term archival of logs
Event HubStream logs to SIEM or third-party analysts
Useful links:

​
Example scenario: Block all requests from the United States

Goal: Prevent any traffic originating from the United States from reaching your app. Steps (Azure portal summary):
  1. Open the Front Door WAF policy.
  2. Navigate to Custom Rules > Add custom rule.
  3. Name the rule (e.g., deny-US). Set Status = Enabled, Rule type = Match, Priority = 1.
  4. Add a condition:
    • Match variable: GeoLocation (country)
    • Operator: Equals
    • Value: United States
  5. Set Action = Block (or Log if you want to observe first).
  6. Save. Because the rule has a low priority number it will be evaluated before managed rules.
Testing:
  • Use a VPN endpoint located in the country you want to test (e.g., United States) and try requests to your application. Requests from that country should be blocked if configured correctly.
  • Monitor WAF logs in Log Analytics to validate hits and check for false positives before enforcing block actions at scale.

​
Example: XSS test payloads used during WAF validation

When validating WAF behavior for injection/XSS detection, common test payloads include: 
<script>alert('XSS')</script>
Try: <img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
<iframe src="javascript:alert('XSS')"></iframe>
javascript:alert('XSS')
If a matching custom block rule is active, such payloads will be blocked by the WAF and not forwarded to your backend.

​
Logging and refining rules

  • Start with Action = Log to observe matched traffic and tune rules to avoid false positives.
  • Use Kusto queries in Log Analytics to analyze blocked requests, IPs, URIs, or header patterns.
  • Iterate: refine matches, adjust priority, and switch from Log to Block when confident.

​
Security caveat — direct backend endpoints can bypass WAF

WAF rules applied to Front Door protect traffic that flows through Front Door. If your backend has an exposed platform hostname (for example, webapp.azurewebsites.net for an Azure App Service), clients can bypass Front Door/WAF by calling that direct URL.
If your backend is accessible via a public platform URL (for example, webapp.azurewebsites.net), attackers can bypass Front Door/WAF by calling that address directly. To prevent this, consider restricting direct access using Private Endpoints, access restrictions (IP restrictions or service tags), or ensuring the backend only accepts traffic routed through Front Door.
Example of a direct-access URL that bypasses Front Door (when present): 
https://webapp-waf-secondary-wrygno.azurewebsites.net/?name=&comment=<script>alert('XSS')</script>
Mitigation options:
  • Use a Private Endpoint so the app has a private IP and is not reachable publicly.
  • Apply access restrictions (IP restrictions, service tags) to allow only Front Door or trusted networks.
  • Configure the backend to validate Host headers (accept only your Front Door hostname) or use mutual authentication where supported.
  • Consider Azure service features (Service Endpoints, Private Link) to lock down connectivity.
  • Explore Azure Private Endpoint and Private Link to prevent direct public access to backends.
  • Review Azure Front Door and Application Gateway documentation for WAF integration patterns.
  • Learn about rate-limiting strategies and bot protection to complement custom rules.
Useful references:

Watch Video