Apply WAF and a rate limit to one path

Create one firewall rule that scores the requests to a path with a WAF rule set and caps the rate of each client on it.

Last updated

View as Markdown Agent setup

You apply a WAF rule set and a rate limit to one path of a workload, such as /api/, with one firewall rule, from Azion Console, the Azion CLI, or the API. To apply a rule set to every request, refer to Apply a rule set to every request, and to rate-limit the clients in a network list, refer to Rate-limit the addresses in a list.

A path such as an API or a login form needs protections the rest of the domain does not. WAF is billed on the requests it scores, so a rule scoped to the path scores only that traffic, and its rate limit counts only the requests to that path.

  1. The firewall compares the request URI with the path. A request to any other path does not match, and the rule runs nothing on it.
  2. On a match, Set WAF scores the request against the rule set. In Blocking mode, a request the rule set blocks receives 400.
  3. Set Rate Limit then counts the request against the rate of its client IP address. A request beyond the burst receives 429.
  4. A request that passes both continues to the application.

Prerequisites

Console

The examples protect /api/ on www.example.com with the rule set <waf-id>, on the firewall <firewall-id>. Replace them with your path, rule set, and firewall.

Create the rule for the path

The criterion is Request Uri starts with /api/, which also matches deeper paths such as /api/v1/orders. Match the URI, not the query string: an empty variable does not match, so Request Args matches .* skips every POST whose payload sits in the body. The behaviors go in a fixed order. Set WAF is one of the two behaviors that another behavior can follow, and choosing Set Rate Limit removes every behavior after it, so Set WAF comes first.

Set WAF starts in Logging, which scores, records, and serves each request, because its records show what the rule set flags on your own traffic. The rate is 10 requests per second per client IP address, with a burst of 10. Requests over the rate are queued and released at the rate, and only simultaneous requests beyond the burst receive 429. Keep the burst within ten times the rate, so the queue holds at most 10 seconds of traffic.

Console

To create the rule in Azion Console:

Open the firewall bound to your workload

Access Azion Console > Firewalls, then select the firewall.

Select the Rules Engine tab
Select + Rule
Name the rule

Enter api - waf and rate limit.

Set the criterion

In the Criteria section, select the Request Uri variable, the starts with operator, and /api/ as the argument.

Add the Set WAF behavior

In the Behaviors section, select Set WAF, then your rule set and Logging as the mode.

Add the Set Rate Limit behavior

Select Add Behavior, then Set Rate Limit. Set Rate Limit Type to Req/s and Limit By to Client IP address. Enter 10 in Average Rate Limit and 10 in Maximum Burst Size.

Select Save

The rule appears in the Rules Engine tab, below the rules created before it.

Every request to /api/ is scored by the rule set and counted against the rate before it reaches the application. This rule neither scores nor counts the requests to any other path. To refuse what the rule set flags, move the mode to Blocking once 3 days of Tuning hold no request that should have been served, as Switch a rule set to blocking describes.

A rule holds one rate limit for everything its criteria match, so a rule that matches two paths through or shares one limit across them, and a separate limit per path takes one rule per path. When the path already has a rule with Set WAF, or another rule must run before the limit, put Set Rate Limit in a rule of its own with the same criterion, in the last position. A firewall runs its rules in order, the API assigns order in creation order, and the Rules Engine list in Azion Console can be reordered.

In the Deploy remote MCP servers use case, this section takes these values:

SettingValue
Namemcp - waf and rate limit
CriterionRequest Uri starts with /mcp
Set WAFThe mcp-waf rule set in Blocking mode
Set Rate LimitReq/s, Client IP address, an Average Rate Limit of 10, and a Maximum Burst Size of 20
Behavior order in the APIset_waf first, then set_rate_limit

Every request to /mcp is scored by mcp-waf and counted against the rate before it reaches the function. A request the rule set blocks answers 400 with the default Bad Request page, and a request over the rate answers 429 with the default Too Many Requests page. Neither response carries a header that names the firewall or a retry time.

In the Protect public APIs from abuse use case, this section takes these values:

SettingValue
Nameapi - rate limit per client
CriterionRequest Uri starts with /v1/
BehaviorSet Rate Limit alone, with Req/s, Client IP address, an Average Rate Limit of 10, and a Maximum Burst Size of 10. In the API, set_rate_limit with type second, limit_by client_ip, average_rate_limit 10, and maximum_burst_size 10

Each client IP address can send 10 requests per second to /v1/, with a peak of 10 more queued. The rate applies in each data center, and no response carries a rate-limit header, so a client has no signal of how long to wait.

Confirm the rule acts on the path

A rule you add reaches traffic 6 minutes 29 seconds to 9 minutes 18 seconds after you save it, and until then requests alternate between the previous answer and the new one. Repeat each check until the answers agree.

To confirm both behaviors:

  1. Send 30 simultaneous requests to the path from one address:

    seq 30 | xargs -P 30 -I{} curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/api/

    Some of the answers print 429: the simultaneous requests beyond the burst of 10. A refused request receives Azion’s default error page, and no rate-limit header:

    Text
    01HTTP/2 429
    02content-type: text/html; charset=utf-8
    03x-azion-request-id: <request-id>
    04
    05<title>Azion - Default error page</title> ... Too Many Requests ... Status Code 429

  2. Send the same 30 requests to a path outside /api/. None of them prints 429, because the rule does not match that path.

  3. Send a request with an injection-shaped query string to the path:

    curl -i "https://www.example.com/api/?q=1%27%20OR%20%271%27%3D%271"

    In Logging, the application answers as usual, and the request’s x-azion-request-id finds its WAF record. After the move to Blocking, the same request receives:

    HTTP/2 400

The rule refuses the requests to /api/ beyond the burst with 429, and records what the rule set flags on the path. No response names the firewall or carries a retry time, so the x-azion-request-id of a refused request is what leads to its record. To read it, refer to Find the WAF score of a blocked request.

In the Deploy remote MCP servers use case, expect:

  • The rate limit refuses a loop. Sixty tools/list requests sent 30 at a time, so they arrive faster than 10 per second, answer with both 200 and 429: the rate and the burst admit some of the requests, and the firewall refuses the others.

These checks confirm the Protect public APIs from abuse use case.

Next steps

Switch a rule set to blockingMove the Set WAF behavior of this rule from Logging to Blocking.Rules Engine for FirewallEvery attribute of Set Rate Limit and Set WAF, and the errors a rule returns.Firewall best practicesSize the burst against the average rate before the rule reaches traffic.Rate-limit the addresses in a listHold the clients in a network list to a rate, whatever path they request.Protect public APIs from abuseAn API whose rate limit runs last, after WAF, a token check, and Bot Manager.Deploy remote MCP serversAn MCP server whose one rule applies WAF and a rate limit to /mcp.