Datos que trata OpenWAF Verify

Última actualización: 29 de octubre de 2026

Borrador, pendiente de revisión legal. Este texto describe lo que hace hoy OpenWAF Verify, comprobado con su código. Aún no lo ha revisado un abogado y puede cambiar.

En resumen

OpenWAF Verify comprueba que un navegador hizo el trabajo de un reto. No intenta identificar a la persona.
Las señales se evalúan en la memoria del nodo de borde y se descartan. Los contadores por red viven ahí unos 10 minutos. Lo que Verify guarda después son recuentos por sitio y por minuto, sin ninguna dirección IP, durante 30 días.
La página de diagnóstico «Comprobar mi navegador» guarda un registro por comprobación, con la red pero nunca la dirección IP completa, durante 7 días, para soporte (apartado 2.9).
Sin huellas de canvas, WebGL, audio ni fuentes, sin client hints de alta entropía, sin identificador persistente del dispositivo y sin nada que siga al visitante de un sitio a otro.
La única cookie en tu sitio es __waf_pass, que pone la página del reto. El widget no pone ninguna. La página «Comprobar mi navegador» usa una cookie de prueba corta en su propio dominio.
Tú eres el responsable del tratamiento y OpenWAF tu encargado, con el Contrato de encargo del tratamiento. El borrador de anexo del contrato para Verify describe el mismo tratamiento en forma de contrato.

1. Qué es OpenWAF Verify

Verify es el motor de retos del borde de OpenWAF. Tiene tres partes, todas servidas en tu propio host bajo /__waf/ por los nodos de borde que ya hacen de proxy de tu web. El navegador del visitante nunca contacta con otro dominio por ello.

Página del reto. Una página intermedia que muestra antes de una página una regla, la barrera contra registros masivos, AI Crawl Control, la puntuación del WAF o el modo bajo ataque. El navegador resuelve una prueba de trabajo y recibe la cookie __waf_pass. Consulta la documentación del reto del navegador.
Widget. Una caja que añades a un formulario. El navegador resuelve la misma prueba de trabajo y recibe un token de un solo uso para tu formulario. Consulta la documentación del widget Verify.
Siteverify. La llamada con la que tu servidor comprueba ese token, en tu propio host a través del borde o en el plano de control. Consulta la referencia de siteverify.

La puntuación de riesgo añade a cada reto una puntuación de 0 a 100. Funciona en modo log (solo cuenta, no aplica nada) salvo que la apagues. Consulta la puntuación de riesgo.

Cuando una comprobación falla, la página del reto y el widget enlazan a «Comprobar mi navegador», una página de diagnóstico en verify.openwaf.dev (apartado 2.9). Los visitantes solo la abren siguiendo ese enlace, o uno que les envíe soporte.

2. Qué se trata

2.1 En cada reto

Dato	Para qué	Cuánto tiempo
Dirección IP del visitante	Para ligar el reto a la red del visitante, buscar su red (ASN) en una base de datos del nodo, cruzarla con las listas de amenazas del nodo y la reputación de IP del WAF, y para los límites por IP de los endpoints de Verify.	En memoria mientras se atiende la petición. Contadores de límites: ventanas deslizantes de un minuto, unos dos minutos como mucho.
Prefijo de red: la /24 IPv4 o la /64 IPv6 de la dirección	El reto, el token y el pase solo valen desde esa red. Contadores por red de retos, fallos y repeticiones recientes.	El reto, el token y los contadores usan un hash del prefijo; la cookie `__waf_pass` lleva el propio prefijo (apartado 4). Contadores: unos 10 minutos en la memoria del nodo.
Red (ASN) de la dirección	Si está en una lista de redes de hosting y centros de datos; contadores por ASN de resoluciones fallidas.	Contadores: unos 10 minutos en la memoria del nodo.
Prueba de trabajo: las soluciones y el tiempo entre la emisión y la resolución	Para comprobar el trabajo y detectar resoluciones más rápidas de lo que puede un navegador, o que tardan siempre lo mismo.	Se comprueban y se descartan. El tiempo de resolución entra en un histograma por sitio y minuto.
Host y ruta de la petición	Para emitir el reto del sitio y la regla correctos.	Verify no los guarda.

2.2 Con la puntuación de riesgo activa

User-Agent y cabeceras de baja entropía que envía todo navegador: Accept-Language, Sec-Fetch-Mode, Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform. El borde nunca envía Accept-CH para pedir más hints.
ClientHello TLS de la conexión. El nodo lo lee una vez, al empezar el saludo TLS, y descarta los bytes en bruto. De él guarda, solo para esa conexión, unos pocos rasgos y la huella JA4 (el algoritmo publicado por FoxIO, por ejemplo t13d1516h2_8daaf6152771_e5627efa2ab1). Los rasgos (versión de TLS, primer valor de ALPN, valores GREASE, las extensiones application_settings y record_size_limit, el número de suites de cifrado) se comparan en memoria con el navegador que dice ser el User-Agent, para la señal tls_mismatch. Verify no guarda ni los rasgos ni la JA4. Si la petición llega al nodo a través de un proxy que termina TLS y en el que el nodo confía, como Cloudflare, o por HTTP sin cifrar, el nodo no ve el ClientHello del visitante y no calcula nada.
Respuestas de las comprobaciones del navegador, un sí o un no por comprobación (apartado 2.5).

La puntuación es la suma de pesos fijos de las señales que saltan. Las señales son una lista cerrada de nombres. Del servidor: asn_hosting, ip_feed, ip_reputation, net_velocity, net_failures, asn_failures, net_replay, tls_mismatch, headers_missing, client_hints_mismatch, ua_automation, webdriver, solve_too_fast, solve_timing_repeat. Del navegador: cdp_runtime, native_patched, headless_env, worker_mismatch, click_dynamics, client_tampered. cdp_input está reservada y nunca salta. pat_valid baja la puntuación y solo salta con los Private Access Tokens activados (apartado 2.7). Qué mira cada una está en la lista de señales.

Los contadores de net_*, asn_failures y las señales de tiempo se llevan en cada nodo de borde, para todos los sitios que sirve ese nodo: una red que inunda un sitio sube su puntuación en otro durante unos 10 minutos. No se comparten entre nodos.

2.3 Página del reto

La página devuelve el reto, las soluciones y la respuesta de las comprobaciones del navegador.
Cuando la página pide un clic (modo bajo ataque, o un nivel de riesgo alto en modo enforce), envía además cómo se activó la casilla (puntero o teclado) y los milisegundos desde que apareció. El borde los comprueba y los descarta.
Una solución correcta pone la cookie __waf_pass (apartado 4).

La página envía la clave del sitio, la acción y el valor cdata que pones en el widget. Viajan dentro del reto y del token en forma legible, así que no pongas datos personales en cdata.
Con la solución, el widget envía navigator.webdriver (si el navegador dice que está automatizado), si hubo alguna pulsación de puntero o tecla en la página antes de la comprobación (sí o no, nunca movimientos ni teclas) y la respuesta de las comprobaciones del navegador. En el paso interactivo envía cómo se activó la casilla y los milisegundos desde que apareció, igual que la página del reto.
El token lleva el widget, el host, la acción, cdata, las horas de emisión y caducidad, un nonce aleatorio, el modo, el nivel de riesgo (low o high), si hubo interacción y un hash del prefijo de red. Vale 300 segundos y una sola vez.

2.5 Comprobaciones del navegador

Con la puntuación de riesgo activa, la página del reto y el widget hacen unas pocas comprobaciones sobre frameworks de automatización: un cliente del protocolo DevTools conectado a la página, funciones propias del navegador sustituidas por un script, una ventana headless o emulada, un Web Worker que describe otro navegador que la página y cómo se activó la casilla de verificación. Cada comprobación se compara dentro de la página. Solo sale un bit por comprobación (saltó o no, se ejecutó o no), empaquetado en un número de 32 bits codificado para ese reto. Los valores que se comparan, como los tamaños de la ventana o el user agent del Worker, no se envían nunca.

2.6 Siteverify

Tu servidor envía el secreto del widget, el token y, si quiere, la dirección IP del visitante (remoteip) y una idempotency_key.
remoteip solo se compara, por hash, con la red a la que está ligado el token. No se guarda.
La respuesta a una llamada con idempotency_key se guarda 300 segundos en la memoria del nodo o del plano de control que respondió, para que un reintento reciba la misma respuesta.
La respuesta nunca incluye la puntuación ni las señales. Dice si el token es válido, su host, acción, cdata, hora de emisión, modo, si hubo interacción y el nivel de riesgo low o high.

2.7 Private Access Tokens, cuando estén activados

Hoy no están activados: OpenWAF no tiene configurado ningún emisor de tokens de confianza, así que el borde nunca pide un token. Cuando se activen, y solo en zonas con la puntuación de riesgo activa, el borde podrá pedir a un dispositivo compatible un Private Access Token (Privacy Pass, RFC 9576, RFC 9577 y RFC 9578) de un emisor público, ligado a ese reto y a tu host. El dispositivo obtiene el token de su emisor por su cuenta; el borde no envía nada al emisor. El nodo comprueba la firma del emisor con su clave pública, que llega en su configuración firmada. Un token válido solo puede bajar la puntuación de riesgo (señal pat_valid): nunca la sube y nunca da el reto por superado por sí solo. El token se comprueba y se descarta, no se guarda; la analítica solo cuenta cuántos retos traían uno válido.

2.8 Uso único

Para que cada reto y cada token valgan una sola vez en todos los nodos, el borde cuenta un hash de su nonce aleatorio en el nodo y en el plano de control. Estos contadores no contienen datos personales y caducan con el reto (10 minutos) o el token (300 segundos), más 30 segundos.

2.9 Página «Comprobar mi navegador»

Comprobar mi navegador es una página de diagnóstico que OpenWAF tiene en verify.openwaf.dev. El enlace de una comprobación fallida lleva el host en el que estaba el visitante y el ID corto del reto. Con la marca blanca de una organización no hay enlace. Qué significa cada comprobación está en la documentación de Comprobar mi navegador.

En el navegador, la página comprueba si funcionan JavaScript, los Web Workers, los ficheros de Verify y las cookies, cuánto tarda una prueba de trabajo corta, navigator.webdriver y si responde el host del enlace (una petición a /__waf/challenge/v1/ping en ese host, sin cookies).
El borde que sirve la página devuelve su hora, la dirección IP del visitante y dos etiquetas de ella: si es de una red de centro de datos y si está en una lista de amenazas o el borde ha visto ataques desde ella hace poco (sí o no, nunca qué lista ni una puntuación). La dirección IP solo se le enseña al visitante. No se guarda.
Una cookie de prueba, __waf_check, en verify.openwaf.dev (HttpOnly, Secure, SameSite=Lax, limitada a la ruta de la comprobación) dice si las cookies funcionan. Dura 15 minutos como mucho y se borra cuando la comprobación queda registrada.
Al terminar las comprobaciones, el borde registra la comprobación: un ID de comprobación aleatorio, la hora, el host que sirvió la comprobación, el host y el ID del reto del enlace, la red (la /24 o la /64, nunca la dirección IP completa), la familia y la versión principal del navegador (por ejemplo chromium/156, no el user agent completo), si volvió la cookie de prueba, las dos etiquetas de red y los resultados, cada uno de una lista fija de valores. El registro se guarda 7 días en el nodo de borde que sirvió la página y se escribe también en su log.
Solo el soporte de OpenWAF usa el registro, para averiguar por qué falla una comprobación cuando el visitante o el sitio nos envían su ID de comprobación. El texto que el visitante puede copiar para soporte lleva la red en vez de la dirección IP.

La página no lee nada del dispositivo aparte de lo que le enseña al visitante: ni canvas, ni WebGL, ni audio, ni fuentes.

3. Lo que Verify nunca recoge

Huellas de canvas, WebGL, audio o fuentes, ni la lista de plugins.
Client hints de alta entropía (versión completa del navegador, modelo del dispositivo, arquitectura, versión de la plataforma).
Movimientos del puntero, teclas pulsadas ni el texto escrito en tus formularios. La comprobación de cómo se activó la casilla se hace en la página y solo envía su sí o no.
Identificadores persistentes del dispositivo ni identificadores que relacionen a un visitante entre sitios. Verify no pone cookies en ningún otro dominio ni carga nada de ninguno.

4. La cookie `__waf_pass`

La pone la página del reto tras una solución correcta. El widget no pone ninguna cookie.

Atributo	Valor
Contenido	La caducidad, el prefijo de red (por ejemplo `198.51.100.0/24`), el host o la zona en que vale y la hora de emisión, firmados con una clave de tu zona. Nada más identifica al visitante.
Duración	`pass_ttl_minutes` de la zona: 12 horas por defecto, de 5 minutos a 7 días. Con el modo bajo ataque activo, la duración fijada para ese modo (también de 5 minutos a 7 días).
Atributos	`HttpOnly`, `Secure`, `SameSite=Lax`, `Path=/`.
Dominio	El host que la emitió, o toda la zona (`Domain=example.com`) con `pass_scope: zone`.

5. Finalidad

Verify trata estos datos solo para proteger tu servicio: distinguir navegadores de tráfico automatizado, frenar avalanchas, relleno de credenciales y spam en formularios, y enseñarte cómo funcionan tus retos. Los registros de «Comprobar mi navegador» solo sirven para que soporte diagnostique comprobaciones fallidas. OpenWAF no los usa para publicidad, no hace perfiles de los visitantes, no los vende ni los cede, y no los usa para fines propios, tampoco para mejorar su detección.

6. Dónde

Los retos, los tokens y los pases se emiten y se comprueban en nodos de borde de OpenWAF en la Unión Europea: Alemania (Hetzner) y Madrid, España (Vultr).
Los recuentos por sitio y por minuto se guardan en Alemania (Hetzner).
La página «Comprobar mi navegador» se sirve desde Alemania (Hetzner) a través de los mismos nodos de borde, que guardan también sus registros.
Dos caminos pasan en tránsito por Cloudflare, que figura en nuestra página de subencargados: el siteverify del plano de control en dash.openwaf.dev (el token y, si lo envías, remoteip) y el tráfico entre los nodos de borde y el plano de control (para Verify: contadores de uso único con hash y los recuentos, sin direcciones IP). Tu servidor puede evitar el primero llamando a siteverify en tu propio host.
AI Services LLC, que opera OpenWAF, está establecida en Estados Unidos. El acceso desde fuera del EEE se ampara en las cláusulas contractuales tipo, como establece el apartado 9 del Contrato de encargo del tratamiento.

7. Cuánto tiempo

Qué	Dónde	Cuánto tiempo
Dirección IP, cabeceras, ClientHello, soluciones, respuestas de las comprobaciones	Memoria del nodo	Mientras se atiende la petición
Contadores por red (hash de la /24 o la /64) y por ASN	Memoria del nodo	Unos 10 minutos (dos tramos de 5 minutos)
Contadores de límites por IP de los endpoints de Verify	Nodo	Ventanas deslizantes de un minuto, unos dos minutos como mucho
Contadores de uso único (hash de un nonce)	Nodo y plano de control	10 minutos para un reto, 300 segundos para un token, más 30 segundos
Respuestas de siteverify con `idempotency_key`	Memoria del nodo o del plano de control	300 segundos
Cookie `__waf_pass`	Navegador del visitante	12 horas por defecto (de 5 minutos a 7 días)
Recuentos por sitio y minuto, separados por lo que sirvió el reto (el tipo de regla, o el widget y su acción): retos emitidos, resueltos y fallidos por causa, histograma de tiempos de resolución, resultados de siteverify, niveles de riesgo, tramos de puntuación y nombres de señal. Sin dirección IP.	Plano de control (Alemania)	30 días
Registros de «Comprobar mi navegador»: ID de comprobación, hora, hosts, ID del reto, red (/24 o /64), familia y versión principal del navegador, resultado de la cookie de prueba, etiquetas de red y resultados. Sin la dirección IP completa.	Nodo de borde que sirvió la página	7 días, después se borran (la copia del log del nodo rota como las líneas de abajo)
Cookie de prueba `__waf_check` de «Comprobar mi navegador»	Navegador del visitante, en `verify.openwaf.dev`	Hasta que se registra la comprobación, 15 minutos como mucho
Líneas del log del nodo de algunos eventos de reto: el modo bajo ataque (host, dirección IP, método y ruta, un ID corto del reto), las comprobaciones fallidas del widget (host, dirección IP, el motivo, un ID corto del reto, el widget) y las identidades de rastreador sin verificar (nombre del rastreador, dirección IP, host). Las de rastreadores, los fallos del modo bajo ataque y los fallos del widget se escriben como mucho una vez por intervalo, salvo las casillas rechazadas del widget; las resoluciones del modo bajo ataque, cada vez.	Logs del nodo	Rotan por tamaño y se sobrescriben; no se archivan

La regla o la política que llevó al visitante al reto (una puntuación del WAF, una regla de límite, AI Crawl Control) puede registrar su propio evento de seguridad, con la dirección IP, el user agent y la huella JA4, como cualquier otro evento de seguridad. AI Crawl Control registra sus propios eventos de agentes de IA y rastreadores con los mismos campos. Esos eventos son del WAF y de AI Crawl Control, no de Verify, y se borran a los 30 días, como dice el Contrato de encargo del tratamiento. Guardan la JA4 como una cadena de texto en el campo tls_fingerprint, nunca el ClientHello, y lo dejan vacío detrás de un proxy de confianza o por HTTP sin cifrar. Cuando un cliente sigue la trampa de AI Crawl Control, el nodo marca además su dirección IP y un hash de su JA4 dentro de su /24 o /64 durante 24 horas.

8. Papeles

Tú decides dónde funciona Verify y para qué, así que eres el responsable del tratamiento. OpenWAF trata los datos por cuenta tuya como encargado, con el Contrato de encargo del tratamiento. Si eres una agencia que actúa para sus clientes, eres su encargado y OpenWAF tu subencargado. OpenWAF no actúa como responsable de estos datos.

9. Base jurídica (posición en borrador)

Este apartado es un borrador y no lo ha revisado un abogado. No es asesoramiento jurídico.

RGPD. Tu interés legítimo en la seguridad de tu servicio y de tu red (artículo 6.1.f del RGPD; el considerando 49 cita como tal interés impedir el acceso no autorizado y los ataques). El tratamiento se limita a los datos de arriba, dura poco y no tiene más efecto sobre el visitante que el propio reto.
ePrivacy. La página del reto y el widget leen información del dispositivo del visitante (las comprobaciones del navegador y navigator.webdriver), y la página del reto guarda la cookie __waf_pass. Nuestra posición en borrador es que entra en la excepción de «estrictamente necesario» del artículo 5.3 de la Directiva 2002/58/CE (en España, el artículo 22.2 de la LSSI-CE): hace falta para dar la página o el formulario que el visitante pidió, protegidos como los configuraste, y los datos solo se usan para eso. Si un abogado aconseja otra cosa, cambiaremos esta página.

10. Subencargados

Verify no añade ningún subencargado. Funciona sobre la misma infraestructura que el resto de OpenWAF Cloud: Hetzner (Alemania) para los nodos de borde, el plano de control y el almacenamiento de los recuentos, Vultr (Madrid, España) para el nodo de borde de Madrid, y Cloudflare en tránsito como se describe en el apartado 6. La lista completa está en la página de subencargados. Ningún emisor de Private Access Tokens recibe datos de OpenWAF.

11. Un párrafo para tu política de privacidad

Puedes adaptar este texto. Cambia lo que va entre corchetes.

Para proteger [esta web] frente a abusos automatizados, algunas páginas y formularios usan OpenWAF Verify, una comprobación de seguridad que presta AI Services LLC (OpenWAF) como encargado del tratamiento. Cuando se ejecuta, tu navegador resuelve una pequeña tarea de cálculo y los servidores de OpenWAF en la Unión Europea la comprueban junto con tu dirección IP, la red a la que pertenece, el user agent y el idioma de tu navegador, propiedades técnicas de su conexión cifrada y unas pocas comprobaciones de sí o no sobre herramientas de automatización. Estos datos solo se usan para seguridad y se guardan en memoria unos 10 minutos como mucho; solo se conservan recuentos sin direcciones IP, durante 30 días. La comprobación puede poner en [nuestro dominio] una cookie llamada __waf_pass, válida [12 horas], para no volver a preguntarte. La base jurídica es nuestro interés legítimo en mantener segura [esta web] (artículo 6.1.f del RGPD). Más información: https://openwaf.dev/es/legal/datos-verify/.

12. Contacto

Dudas sobre esta página o sobre Verify: support@openwaf.dev. Los visitantes que quieran ejercer sus derechos deben dirigirse a la web que les mostró el reto; si nos escriben a nosotros, enviamos la solicitud a ese cliente, como dice el apartado 7 del Contrato de encargo del tratamiento.