Verify risk scoringNew

Risk scoring looks at each challenge the edge issues, on the browser challenge page, in under attack mode and in the Verify widget, and gives it a score from 0 to 100. The score comes from signals the request already carries: the network it comes from, whether the browser it claims to be adds up, and how the proof of work was solved. No extra fingerprinting and no third parties: see Data processed.

The score picks a level: the proof of work alone, a harder one, a one-click «Verify you are human» step, or a block. In the default log mode the levels are only counted, so you can see in the analytics what they would do before applying them.

Risk scoring raises the cost of automation; it does not prove that a visitor is human. Read the limits before you rely on it.

#Levels

The score is the sum of the weights of the signals that fired, kept between 0 and 100. Each zone has three thresholds; the level is the highest one the score reaches.

When each level applies:

• Browser challenge page. The score is computed when the page is issued, and harder, interactive and block apply there. When the solution arrives at /__waf/verify it is scored again with the solve-time signals; a block level then answers 403 with {"ok":false,"error":"blocked"} instead of the pass. A solve that only reaches interactive is not turned into a click at that point: it marks the network, and its next challenge starts with a higher score.
• Verify widget. At /start (the box getting its challenge), harder adds work and block refuses it. When the solution is checked, interactive escalates a managed widget to the click (unless the visitor already interacted with the page) and block refuses it.

A threshold of 0 turns that level off. The non-zero thresholds must increase in the order harder < interactive < block, and at least one must be on.

#Signals

Each signal has a fixed weight. Issue signals are evaluated when the challenge is issued; solve signals when its solution is checked, together with the issue signals of the same challenge.

The timing signals skip challenges that ask for a click, since the visitor's own pace then sets the time. Network and ASN counters are kept on each edge node for about 10 minutes and are not shared between nodes.

The browser checks run in the challenge page and in the widget, each one a yes/no answer that never leaves the page in any other form. Their answer is encoded differently for every challenge, so a recorded answer doesn't fit another one, and the functions they inspect change from one challenge to the next. Their total is capped at the interactive threshold unless a server-side signal also fired: on their own they can ask for a click, never block. The name cdp_input is reserved and never fires.

#TLS stacks

The edge computes the JA4 (external link) fingerprint of each TLS connection it terminates, from the ClientHello. JA4 changes with every browser release, so tls_mismatch doesn't compare exact JA4 strings. It checks that the ClientHello offers TLS 1.3 with h2 as the first ALPN value, and that it has the stable traits of the browser the User-Agent names:

Older browsers keep a coarser check: TLS 1.3 and h2 (Chromium 70+, Firefox 70+, Safari 14+), and GREASE for Chromium 70–99.

For example, Chrome 156 sends t13d1518h2_8daaf6152771_e2d80978ab2e, curl sends t13d4907h2_… and Python requests sends t13d1712h1_…. This catches an automated Chromium whose User-Agent claims Safari or Firefox, and a script that copies a browser's User-Agent. A Firefox-based automation tool with a Firefox User-Agent has Firefox's TLS, so it doesn't fire.

#Private Access Tokens

A Private Access Token (RFC 9577 (external link)) lets a device show that it passed its maker's checks (for Apple devices, a genuine device with a signed-in account) without saying who it is. When risk scoring is on and OpenWAF trusts at least one token issuer, the challenge page and the widget ask the edge for a token challenge bound to that challenge and to the site's host. A supporting device answers with a token, which the edge checks offline with the issuer's public key. A valid token adds pat_valid when the challenge is solved.

The token carries no identity and can't be linked to the visitor's other visits; the edge checks it and drops it, and the analytics only count pat_valid as a signal. Devices without tokens lose nothing: their score is the same as without this feature.

Status: not enabled. No issuer is configured, because issuing tokens that Apple devices accept for OpenWAF needs an agreement with such an issuer. Until then the edge never asks for a token and pat_valid never fires.

#Mode and thresholds

Risk scoring is the zone's challenge.risk object. It applies to every name of the zone; a name can't override it (hosts.<name>.challenge.risk is rejected).

Fields merge one by one: thresholds you leave out keep their value, and "risk": null goes back to the defaults. GET …/edge always shows the effective object. Every change is versioned, needs a reason and can be reverted.

openwaf-cloud ctl zones set example.com challenge.risk.mode=enforce challenge.risk.thresholds.block=95 \
  --reason "Enforce risk scoring"
openwaf-cloud ctl zones set example.com challenge.risk:=null --reason "Risk scoring back to defaults"

curl -s -X PATCH https://dash.openwaf.dev/v1/orgs/$ORG/zones/$ZONE/edge \
  -H "Authorization: Bearer $OPENWAF_TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Change-Reason: Enforce risk scoring" \
  -d '{"challenge": {"risk": {"mode": "enforce", "thresholds": {"block": 95}}}}'

#From log to enforce

1. Leave it in log mode (the default) for a few days of normal traffic, and through an attack if you can.
2. Read the report (below): how many challenges would land in each level, the score distribution and the signals that fire most. Look at the share in interactive and block: those visitors would get a click or a 403.
3. Adjust the thresholds if a signal your real visitors trigger (for example asn_hosting for a B2B audience on corporate VPNs or cloud desktops) pushes too many of them up. Raising a threshold, or setting harder or interactive to 0, is safer than turning scoring off.
4. Switch to enforce and keep watching the report: in enforce mode escalated and blocked count what was applied.

#Analytics

Domain → Security → Verification shows, in the Risk section of the activity, the mode and thresholds, the challenges scored, the split by level, the score distribution, how many were asked for a click after solving and how many were blocked, and the signals that fired most. In log mode it says «Log only: nothing is applied» and the counts are what enforce would have done.

The same data is in the risk object of GET /v1/orgs/{org}/zones/{zone}/challenge/analytics?days=7, of openwaf-cloud ctl challenge report example.com --days 7 (lines Riesgo, Niveles, a score histogram and Señales) and of the MCP tool challenge_report:

"risk": {
  "mode": "log",
  "thresholds": {"harder": 30, "interactive": 60, "block": 90},
  "evaluated": 1230,
  "levels": {"pass": 1100, "harder": 90, "interactive": 32, "block": 8},
  "scores": [900, 120, 80, 50, 30, 20, 15, 7, 0, 5, 3],
  "top_signals": [{"signal": "asn_hosting", "count": 140}, {"signal": "headers_missing", "count": 60}],
  "escalated": 4,
  "blocked": 8
}

Each row of the per-trigger table (gate, rate_rule, under_attack, each widget…) carries its own risk_levels. The analytics keep aggregates for 30 days.

#What is never scored

Risk scoring only scores challenges the edge was going to issue anyway; it never challenges a request by itself. Requests that skip the challenge skip scoring too:

• addresses and networks with an IP or ASN allow rule;
• verified crawlers (Bot verification);
• the exempt_paths of under attack mode, and the edge's own /__waf/ paths;
• requests that aren't browser navigations: they get the usual non-navigation answer, not a challenge;
• visitors that already hold a valid pass.

Under attack mode is scored like any other challenge. Its own click (interactive, on by default) doesn't depend on the score; in enforce mode a high score can still make the work harder or block.

#Data processed

What the risk engine reads, all of it already in the request or the solve:

• The client address, to look up its ASN, the threat feeds and the reputation, in the edge node's memory.
• The JA4 fingerprint of the TLS ClientHello of the connection (see TLS stacks). The edge reads the ClientHello once to compute it and drops the raw bytes.
• Low-entropy headers every browser sends: User-Agent, Accept-Language, Sec-Fetch-Mode, Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform.
• A Private Access Token, only if the device offers one and the feature is enabled (it isn't yet). It is checked and dropped.
• navigator.webdriver, already sent by the Verify widget.
• The browser checks' answer: one yes/no per check, encoded for the challenge. The page compares, without sending them: whether the JavaScript runtime is being serialized for a debugger, whether a few built-in functions are still the browser's own, the window and screen sizes, the Web Worker's user agent, platform, languages and processor cores against the page's, and, for the verification box, where in the box the press landed and how long the key was held.
• The proof of work's timing: when the challenge was issued, when the solution arrived and the work it implies.

What it keeps: per-network counters (keyed by a hash of the IPv4 /24 or IPv6 /64) and per-ASN counters, for about 10 minutes in the edge node's memory. The analytics receive only levels, score buckets and signal names, per site and per minute, with no IP address; they are kept for 30 days. The security events of a request store its JA4 string in tls_fingerprint (empty when another proxy terminated TLS, or on plain HTTP), never the raw ClientHello.

What it never collects: canvas, WebGL, audio or font fingerprints, plugins, or high-entropy client hints. The edge never sends Accept-CH to ask for more hints.

Everything Verify processes, for how long and where, the roles under the DPA and a paragraph for your privacy policy: Data processed by OpenWAF Verify (external link) (draft pending legal review).

#Limits

• Cost, not proof. Risk scoring makes automation slower and more expensive. Automation that drives a real browser through the operating system or the DevTools protocol, from residential or mobile addresses, sends the same headers and TLS as a person and can still pass. The browser checks catch the default behaviour of common frameworks; a framework tuned to imitate a person's input, or input injected by the operating system, passes them.
• Browser checks are hints. A visitor with DevTools open, or using voice control or switch access that presses the exact centre of the box, can fire one; that is why they never block on their own.
• TLS check. tls_mismatch uses the JA4 fingerprint and stable traits of each browser's TLS stack, not a list of exact fingerprints, so a tool that reproduces a browser's TLS exactly passes it. It is skipped when another TLS-terminating proxy sits in front of the edge, since the handshake is then the proxy's.
• Hosting or not. The ASN list only tells hosting and datacenter networks from the rest; there is no mobile or residential classification.
• Per-node memory. Network and ASN counters live on each edge node for about 10 minutes, so traffic spread over several nodes builds them up more slowly.
• No click after the page's solve. On the challenge page, interactive applies when the page is issued; a solve-time score can only block or mark the network for its next challenge.
• Siteverify unchanged. Siteverify still answers metadata.risk as low, or high when interaction was required; it doesn't carry the score or the signals.
• Log mode applies nothing. In log mode the levels only appear in the analytics.