Azure Front Door Premium WAF Preview Adds JA4 and ASN Rate Limiting for Distributed Traffic

What changed​

Grouping by country/region, AS number, JA4 fingerprint or None is in preview. Per-socket-IP rate limiting, the default, stays generally available. Rules that already exist are not touched. Rules that don't specify a grouping count requests per socket IP address, so existing rate limit rules aren't affected.

The motivation is distributed traffic. A per-IP limit works well against clients sending many requests from a few addresses, but is less effective against botnets that spread traffic across thousands of IPs so each stays under the threshold. Grouping counts requests by an attribute those clients share, so many IPs can feed one threshold.

The grouping options​

Microsoft's guidance on when to use each:

• JA4: Use it against attacks that rotate IPs but reuse the same client software. Microsoft says that in HTTP floods, most attack traffic often comes from a handful of fingerprints. Microsoft's docs also say a JA4-grouped rule caps every fingerprint automatically, including ones you haven't seen yet.
• ASN: Use it to cap traffic from networks your users don't normally come from, such as hosting and cloud providers, without maintaining IP range lists.
• Country/region: Use it to cap what any one country/region can send to each edge location, for example during a flood concentrated in one country.
• None: Pair it with narrow match conditions, such as a sign-in page, to cap the request rate to that resource.

The caveat: counters are per edge location​

This is the detail most likely to catch administrators out. Front Door keeps counts separately at each edge location and doesn't aggregate them globally. A grouped rule therefore doesn't create one worldwide counter.

Microsoft's own example: a country/region rule set to 1,000 requests per minute. If that country's traffic arrives at three edge locations, each allows up to 1,000, so about 3,000 per minute can get through in total. The docs say to size thresholds from traffic at a single edge location, not from application-wide totals. A threshold sized from total traffic might never be reached at any one edge.

A second, smaller effect applies inside an edge location. Different Front Door servers may not have updated counters yet, for example when a client opens a new TCP connection for each request. For low thresholds, roughly under 200 requests per minute, some requests above the limit may get through.

Configuration​

• Portal: Choose the Group rate limit traffic by setting on the rate limit rule.
• ARM, Bicep, REST: Set the custom rule's groupBy property. Microsoft's example is groupBy: [ { variableName: 'Ja4' } ]. Grouping requires a Premium WAF policy.
• Azure PowerShell: Use New-AzFrontDoorWafCustomRuleGroupByVariableObject.
• Duration and matching: The window is one or five minutes, and every rule needs at least one match condition.
• One variable per rule: To count the same traffic two ways, create separate rules.

Microsoft's example JA4 rule is named RateLimitByJa4. It has a five-minute window, a threshold of 500, groupBy set to Ja4, a match condition that matches every request, and the action Block. A second example groups by None. It counts all requests to a /signin path together, and with a 2,000-per-minute threshold it issues a JavaScript challenge instead of blocking.

Sizing the threshold​

Microsoft says to set a grouped threshold above the highest rate any group reaches at one edge location in normal traffic. Measure it over at least a week. The docs include a Log Analytics query against the FrontDoorAccessLog category. It summarises requests by five-minute bin, pop_s (the edge location) and clientJA4FingerPrint_s. It then reports P99 and peak per fingerprint. To size a country grouping, swap in clientCountry_s, and match the bin size to the rule's window.

Risks to weigh​

• Collateral damage: With a country/region, AS number or JA4 grouping, legitimate users who share that country, network or client software are limited along with the attack traffic. With None, all matching traffic is limited.
• Shared fingerprints: Popular browsers present the same JA4 fingerprint across huge numbers of users. If attackers use the same fingerprint, a JA4 rule limits both groups.
• Proxies and CDNs: If traffic reaches Front Door through another proxy or CDN, the socket IP, its derived country and ASN, and the JA4 fingerprint can describe that intermediary rather than the end user.
• Keep the per-IP rule: Use grouped rules alongside it, not instead. A client can change its TLS fingerprint, whereas IP addresses are the costliest attribute for an attacker to change.
• Roll out gently: Start new rules with the Log action, then consider a JavaScript challenge or CAPTCHA before Block. Deploy in Log first, confirm the fingerprint appears only in attack traffic, then switch to Block or a rate limit rule.

Analysis​

This is a useful and sensibly scoped addition. JA4 and ASN grouping give defenders a lever for botnets that dodge per-IP limits, and the docs are candid about the sharp edges. The per-edge counting also means these rules work as a brake on each edge location, not a hard global cap. For a hard ceiling you would need to reason about the number of edges a group reaches.

Because this is a preview, treat it as a test-environment feature. Run it in Log mode alongside your existing per-IP rules, gather a week of data, and only then consider enforcement on production traffic. The Azure Updates entry itself gave little detail, so the specifics above come from Microsoft's technical documentation. They may change before general availability.