DPA annex: OpenWAF Verify processing (draft)

Last updated: October 28, 2026

This is an English translation provided for convenience. In case of any discrepancy, the Spanish version prevails.

Draft, pending legal review. This text describes what OpenWAF Verify does today, checked against its code. It has not yet been reviewed by a lawyer and may change.

About this draft

This annex describes, in the terms of article 28(3) GDPR, the processing OpenWAF carries out for the Customer when the Customer uses OpenWAF Verify. It is a draft pending legal review and is not yet part of the Data Processing Agreement (“DPA”) the Customer accepts at sign-up.
Until it is incorporated, the DPA as published governs, and Verify is covered by its general description of the service. Terms in capitals have the meaning given in the DPA.
The facts behind each item, with more detail, are on the page Data processed by OpenWAF Verify.

1. Scope

OpenWAF Verify (“Verify”) is the challenge feature of OpenWAF Cloud: the challenge page that the edge shows before a page when a rule, the register-flood gate, AI Crawl Control, the WAF score or under attack mode asks for it; the widget the Customer embeds in its forms; and the siteverify endpoints the Customer’s servers call to check a widget token. This annex applies while the Customer has any of them enabled on its zones.

2. Description of the processing

Subject matter: Checking that requests to the Customer’s websites and forms come from a browser that did the work of a challenge, and scoring the risk that they are automated.
Nature: Issuing and checking proof-of-work challenges, widget tokens and passes on the edge nodes; evaluating risk signals in the memory of the edge node; counting recent challenges per network and per network operator (ASN) in the memory of the edge node; counting single-use challenges and tokens by a hash of their nonce; answering siteverify; setting the __waf_pass cookie on the Customer’s domain; aggregating counts per site and per minute for the Customer’s analytics.
Purpose: Security of the Customer’s service only: telling browsers from automated traffic, slowing down floods, credential stuffing and form spam, and reporting how the Customer’s challenges perform. OpenWAF does not process these data for its own purposes, including improving its detection, and does not sell or share them.
Duration: While the Customer uses Verify, and afterwards until the data are deleted as set out in section 5.
Frequency: Continuous, on every challenge, widget check and siteverify call.

3. Categories of data subjects

Visitors of the Customer’s websites who receive a challenge or use a form with the widget, and people or programs whose requests are challenged.

4. Categories of personal data

IP address and its network prefix (IPv4 /24, IPv6 /64), and the network operator (ASN) looked up from it on the edge node.
Request headers: User-Agent, Accept-Language, Sec-Fetch-Mode and the low-entropy client hints Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform; host and path.
Traits of the TLS ClientHello (TLS version, first ALPN value, GREASE, two extensions, number of cipher suites) and its JA4 fingerprint, evaluated in the memory of the edge node for that connection; the raw ClientHello is dropped once parsed. Verify stores neither. Not available when a trusted proxy terminates TLS before the edge node or over plain HTTP.
Proof-of-work solutions and their timing.
Answers of the browser checks (one yes or no per check), navigator.webdriver, whether there was a press on the page before the widget check (yes or no), and, in an interactive step, the kind of activation (pointer or keyboard) and the milliseconds since the box appeared.
The content of the __waf_pass cookie (expiry, network prefix, host or zone, issue time) and of widget tokens (widget, host, action, the Customer’s cdata, times, nonce, mode, risk level, interaction and a hash of the network prefix).
In siteverify, the IP address the Customer sends as remoteip, if any.
When Private Access Tokens are enabled (they are not as of the date of this draft), whether the device presented a valid token. The token is verified and dropped, not stored.

Special categories of data: none. Verify does not collect canvas, WebGL, audio or font fingerprints, plugins, high-entropy client hints, pointer movements, key presses, form contents, or persistent or cross-site identifiers.

5. Retention and deletion

Data	Retention
IP address, headers, ClientHello, solutions, browser-check answers, `remoteip`	In the memory of the edge node or control plane while the request is handled
Per-network (by hash of the prefix) and per-ASN counters	About 10 minutes, in the memory of each edge node
Per-IP rate-limit counters of the Verify endpoints	At most about two minutes
Single-use counters (hash of a nonce)	Until the challenge (10 minutes) or token (300 seconds) expires, plus 30 seconds
Siteverify answers kept for an `idempotency_key`	300 seconds
`__waf_pass` cookie	In the visitor’s browser, for the pass lifetime the Customer sets (5 minutes to 7 days; 12 hours by default)
Counts per site and per minute, without IP addresses	30 days
Log lines on the edge node for some challenge events (under attack mode, unverified crawler claims), most of them limited in rate	Rotated by size and overwritten, not archived

Section 10 of the DPA applies on termination.

6. Technical and organisational measures

The measures of Annex II of the DPA apply. In addition, for Verify:

First party. The scripts, the challenge page and the siteverify endpoint are served on the Customer’s own host by the edge nodes; the visitor’s browser contacts no other domain for Verify.
Minimisation. A closed list of signals, published on the data page; browser checks leave the page as one bit each; no fingerprinting techniques listed in section 4.
Short-lived memory. Signals are evaluated and dropped on the edge node; counters are keyed by a hash of the network prefix, bounded in size and kept about 10 minutes; nothing is shared between nodes except the single-use counters.
No IP address in analytics. Telemetry carries counts per site, label and minute only.
Integrity. Challenges, tokens and passes are signed with HMAC-SHA256 keys of the Customer’s zone; challenges and tokens are single use across every edge node and the control plane; a token is valid for 300 seconds, carries the host and action it was issued for and is bound to the visitor’s network; the widget secret is stored only as a hash.
Location. Edge nodes in Germany and Spain; analytics stored in Germany.

7. Sub-processors

Verify adds no sub-processor. The sub-processors of Annex III of the DPA, listed on the Sub-processors page, are used as described there and on the data page. Issuers of Private Access Tokens receive no data from OpenWAF and are not sub-processors.

8. Transfers

Section 9 of the DPA applies.

9. Customer’s responsibilities

To have a legal basis for using Verify and to inform the visitors of its websites, for example with the paragraph offered on the data page.
Not to put personal data in the widget’s action or cdata, which travel in readable form.
To keep the widget secret on its servers and call siteverify only from them.

10. Status of this draft

This annex has not yet been reviewed by a lawyer. After review it will be incorporated into the DPA as part of a new dated version. Questions: support@openwaf.dev.