JA4 in WAF Rules — Cloudflare and Google Cloud Armor

JA4 in WAF rules means using the TLS ClientHello fingerprint as a match key, not treating it as a complete bot verdict. Cloudflare exposes JA4 inside Bot Management, while Google Cloud Armor lets a custom rule compare origin.tls_ja4_fingerprint against a known value such as t13d1516h2_8daaf6152771_b186095e22b6. The wider JA4+ fingerprint suite explains where JA4S, JA4H, JA4X, JA4L, JA4SSH, and JA4T fit around that TLS signal.

Last verified: 2026-06-25 against Cloudflare Bot Management documentation, Google Cloud Armor custom rules documentation, and the FoxIO JA4 technical details.

Quick Reference

The search-intent trap is simple: a JA4 value looks exact enough to block, but the fingerprint only describes the TLS handshake. A good WAF rule asks whether that handshake is consistent with the request, reputation, account state, and bot-detection stack.

What JA4 gives a WAF rule

JA4 TLS fingerprinting summarizes a TLS or QUIC client hello into a stable, shareable string. The first segment keeps human-readable metadata: transport (t, q, or d), TLS version, SNI presence, cipher count, extension count, and ALPN. The second and third segments are truncated SHA-256 hashes of sorted cipher and extension material.

That sorted design is the difference from JA3. JA3 hashes the ClientHello mostly as observed, so extension-order randomization can explode one browser family into many fingerprints. JA4 sorts the cipher and extension lists before hashing, which makes the signal easier to group across modern browsers that deliberately randomize order.

A WAF rule can use JA4 for three jobs:

• Known-bad blocking: deny traffic from a JA4 already tied to abuse in local logs.
• Allow-list precision: let a trusted integration through only when the TLS fingerprint also matches the expected client stack.
• Risk scoring: add weight when JA4 conflicts with the claimed browser, HTTP/2 fingerprint, ASN, IP reputation, or session behavior.

The third pattern is usually safest. A real browser, headless browser, mobile app, and bot framework can share parts of a network path. JA4 narrows the candidate set; it does not prove intent.

Cloudflare JA4 rules need null-safe handling

Cloudflare documents JA3 and JA4 as SSL/TLS-based identifiers available to Enterprise customers with Bot Management. The same page notes that JA4 improves on JA3 by sorting ClientHello extensions, reducing unique fingerprints for modern browsers and making grouping easier.

Cloudflare also documents absence conditions. JA3 or JA4 can be null or empty for non-encrypted HTTP traffic, some Worker-routed flows, requests where Bot Management is skipped, and TLS session resumption cases where the initial handshake has already completed. Cloudflare’s sample Workers object shows ja4Signals as a structured set of ratios, ranks, and quantiles, but the documentation warns that the JA4 fingerprint and the ja4Signals array can both be missing.

That changes rule design. A rule or Worker that assumes every request has cf.botManagement.ja4 and populated signals will fail open, fail closed, or throw on exactly the edge cases that need careful handling. Null-safe logic should separate three states:

1. JA4 present and matched a local policy value.
2. JA4 absent for a documented transport or routing reason.
3. JA4 absent where the route normally should have one.

Only the third state is suspicious by itself. The first state is a positive match. The second state is an observability limitation that needs another signal.

Google Cloud Armor matches explicit JA4 values

Google Cloud Armor exposes JA4 in custom rules as origin.tls_ja4_fingerprint. The documented single-value example is:

origin.tls_ja4_fingerprint == 't13d1516h2_8daaf6152771_b186095e22b6'

The documented list pattern repeats the comparison with || for each fingerprint. That shape is intentionally explicit: Cloud Armor rules match known JA4 values, not broad fuzzy families. It works well when the source of truth is a threat-intel list, an incident response query, or a known partner client whose TLS stack is stable.

A useful Cloud Armor deployment flow is:

1. Log candidate fingerprints without blocking.
2. Confirm the JA4 value appears with the same abuse pattern across enough requests.
3. Add a custom rule that denies or rate-limits only the confirmed value.
4. Keep a rollback path because browser and library releases can change TLS behavior.

The same t13d1516h2_8daaf6152771_b186095e22b6 value appears in FoxIO’s JA4 technical details as a representative TLS 1.3, SNI-present, HTTP/2-capable fingerprint. The value is useful in docs because it is recognizable; it should not be copied into a production deny rule unless local telemetry says that exact client is abusive.

JA4 vs JA4T and HTTP/2 in WAF decisions

JA4 sits at the TLS layer. JA4T TCP fingerprinting observes the TCP SYN before TLS. HTTP/2 fingerprinting observes the SETTINGS frame, WINDOW_UPDATE behavior, PRIORITY behavior, and pseudo-header order after TLS.

Layer mismatch is the practical signal. A request can claim Chrome in User-Agent, replay a Chrome-like JA4, but still expose a non-browser TCP stack or HTTP/2 pseudo-header order. The inverse also matters: an enterprise mobile app may have a stable non-browser JA4 while still being legitimate for one API route.

Use JA4 in WAF rules as a join key:

• JA4 groups TLS clients.
• JA4T groups TCP stacks and network paths.
• HTTP/2 fingerprinting groups protocol implementations.
• Header order and Sec-Fetch headers check browser consistency.
• Behavior decides whether the grouped client is abusive.

A rule that combines those layers is harder to evade than a single hash check and less likely to block a legitimate shared fingerprint.

Safe rule patterns

Start with monitoring rules. Export the JA4 value alongside path, method, status, ASN, country, account state, bot score, and rate-limit decision. Pivot by fingerprint only after the logs show whether one JA4 maps to one actor or a broad client population.

Prefer narrow actions first:

if known_bad_ja4 and login_path then challenge or rate-limit
if known_bad_ja4 and credential_stuffing_score_high then block
if trusted_partner_path and ja4_not_expected then alert

Avoid global rules like “block all traffic with this unfamiliar JA4.” Unfamiliar means the telemetry set is incomplete. A new browser release, TLS library update, mobile OS change, or CDN path can create fingerprints that look strange for a few days.

JA4 is strongest when it turns a noisy request stream into named clusters. The WAF should still make the final decision from context: endpoint sensitivity, request rate, account history, bot score, and whether the lower and higher protocol layers tell the same story.

Sources

• Cloudflare — JA3/JA4 fingerprint — Bot Management docs for JA4 availability, extension sorting, ja4Signals, and documented missing-field cases.
• Google Cloud Armor — custom rules language attributes — origin.tls_ja4_fingerprint examples for single JA4 and multi-JA4 matching.
• FoxIO JA4 technical details — canonical JA4 format, sorted cipher/extension hashes, ALPN handling, and representative example fingerprints.
• JA4 vs JA3: Why TLS Fingerprinting Migrated — local companion entry explaining the JA4 format and why extension sorting matters.
• How Websites Detect Bots in 2026 — local companion entry for cross-layer bot detection context.