Anexo al contrato de encargo: tratamiento de OpenWAF Verify (borrador)

Última actualización: 28 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.

Sobre este borrador

Este anexo describe, en los términos del artículo 28.3 del RGPD, el tratamiento que OpenWAF hace por cuenta del Cliente cuando el Cliente usa OpenWAF Verify. Es un borrador pendiente de revisión legal y aún no forma parte del Contrato de encargo del tratamiento (el «Contrato») que el Cliente acepta al darse de alta.
Mientras no se incorpore, rige el Contrato publicado, y Verify queda cubierto por su descripción general del servicio. Los términos con mayúscula tienen el significado que les da el Contrato.
Los hechos que hay detrás de cada punto, con más detalle, están en la página Datos que trata OpenWAF Verify.

1. Alcance

OpenWAF Verify («Verify») es la función de retos de OpenWAF Cloud: la página del reto que el borde muestra antes de una página cuando la pide una regla, la barrera contra registros masivos, AI Crawl Control, la puntuación del WAF o el modo bajo ataque; el widget que el Cliente inserta en sus formularios; y los endpoints de siteverify a los que llaman los servidores del Cliente para comprobar un token del widget. Este anexo se aplica mientras el Cliente tenga activada alguna de ellas en sus zonas.

2. Descripción del tratamiento

Objeto: Comprobar que las peticiones a las webs y formularios del Cliente vienen de un navegador que hizo el trabajo de un reto, y puntuar el riesgo de que estén automatizadas.
Naturaleza: Emitir y comprobar retos de prueba de trabajo, tokens del widget y pases en los nodos de borde; evaluar señales de riesgo en la memoria del nodo de borde; contar los retos recientes por red y por operador de red (ASN) en la memoria del nodo de borde; contar los retos y tokens de un solo uso por un hash de su nonce; responder a siteverify; poner la cookie __waf_pass en el dominio del Cliente; agregar recuentos por sitio y por minuto para la analítica del Cliente.
Finalidad: Solo la seguridad del servicio del Cliente: distinguir navegadores de tráfico automatizado, frenar avalanchas, relleno de credenciales y spam en formularios, e informar de cómo funcionan los retos del Cliente. OpenWAF no trata estos datos para fines propios, tampoco para mejorar su detección, y no los vende ni los cede.
Duración: Mientras el Cliente use Verify y, después, hasta que los datos se supriman como establece el apartado 5.
Frecuencia: Continua, en cada reto, comprobación del widget y llamada a siteverify.

3. Categorías de interesados

Visitantes de las webs del Cliente que reciben un reto o usan un formulario con el widget, y las personas o programas cuyas peticiones reciben un reto.

4. Categorías de datos personales

Dirección IP y su prefijo de red (/24 IPv4, /64 IPv6), y el operador de red (ASN) que se busca con ella en el nodo de borde.
Cabeceras de la petición: User-Agent, Accept-Language, Sec-Fetch-Mode y los client hints de baja entropía Sec-CH-UA, Sec-CH-UA-Mobile y Sec-CH-UA-Platform; host y ruta.
Rasgos del ClientHello TLS (versión de TLS, primer valor de ALPN, GREASE, dos extensiones, número de suites de cifrado) y su huella JA4, evaluados en la memoria del nodo de borde para esa conexión; el ClientHello en bruto se descarta en cuanto se analiza. Verify no guarda ninguno de los dos. No están disponibles cuando un proxy de confianza termina TLS antes del nodo de borde ni por HTTP sin cifrar.
Soluciones de la prueba de trabajo y sus tiempos.
Respuestas de las comprobaciones del navegador (un sí o un no por comprobación), navigator.webdriver, si hubo una pulsación en la página antes de la comprobación del widget (sí o no) y, en un paso interactivo, el tipo de activación (puntero o teclado) y los milisegundos desde que apareció la casilla.
El contenido de la cookie __waf_pass (caducidad, prefijo de red, host o zona, hora de emisión) y de los tokens del widget (widget, host, acción, el cdata del Cliente, horas, nonce, modo, nivel de riesgo, interacción y un hash del prefijo de red).
En siteverify, la dirección IP que el Cliente envía como remoteip, si la envía.
Con los Private Access Tokens activados (no lo están a la fecha de este borrador), si el dispositivo presentó un token válido. El token se comprueba y se descarta, no se guarda.

Categorías especiales de datos: ninguna. Verify no recoge huellas de canvas, WebGL, audio ni fuentes, plugins, client hints de alta entropía, movimientos del puntero, teclas pulsadas, contenido de formularios ni identificadores persistentes o entre sitios.

5. Conservación y supresión

Datos	Conservación
Dirección IP, cabeceras, ClientHello, soluciones, respuestas de las comprobaciones, `remoteip`	En la memoria del nodo de borde o del plano de control mientras se atiende la petición
Contadores por red (por hash del prefijo) y por ASN	Unos 10 minutos, en la memoria de cada nodo de borde
Contadores de límites por IP de los endpoints de Verify	Unos dos minutos como mucho
Contadores de uso único (hash de un nonce)	Hasta que caduca el reto (10 minutos) o el token (300 segundos), más 30 segundos
Respuestas de siteverify guardadas para una `idempotency_key`	300 segundos
Cookie `__waf_pass`	En el navegador del visitante, la duración del pase que fija el Cliente (de 5 minutos a 7 días; 12 horas por defecto)
Recuentos por sitio y por minuto, sin direcciones IP	30 días
Líneas del log del nodo de borde de algunos eventos de reto (modo bajo ataque, identidades de rastreador sin verificar), la mayoría limitadas en frecuencia	Rotan por tamaño y se sobrescriben; no se archivan

Al terminar el servicio se aplica el apartado 10 del Contrato.

6. Medidas técnicas y organizativas

Se aplican las medidas del Anexo II del Contrato. Además, para Verify:

Primera parte. Los scripts, la página del reto y el endpoint de siteverify los sirven los nodos de borde en el propio host del Cliente; el navegador del visitante no contacta con ningún otro dominio por Verify.
Minimización. Una lista cerrada de señales, publicada en la página de datos; las comprobaciones del navegador salen de la página como un bit cada una; ninguna de las técnicas de huella del apartado 4.
Memoria breve. Las señales se evalúan y se descartan en el nodo de borde; los contadores usan como clave un hash del prefijo de red, tienen un tamaño máximo y duran unos 10 minutos; entre nodos solo se comparten los contadores de uso único.
Sin direcciones IP en la analítica. La telemetría lleva solo recuentos por sitio, etiqueta y minuto.
Integridad. Los retos, los tokens y los pases se firman con claves HMAC-SHA256 de la zona del Cliente; los retos y los tokens son de un solo uso en todos los nodos de borde y en el plano de control; un token vale 300 segundos, lleva el host y la acción para los que se emitió y está ligado a la red del visitante; el secreto del widget solo se guarda como hash.
Ubicación. Nodos de borde en Alemania y España; analítica guardada en Alemania.

7. Subencargados

Verify no añade ningún subencargado. Los subencargados del Anexo III del Contrato, que figuran en la página de Subencargados, intervienen como se describe allí y en la página de datos. Los emisores de Private Access Tokens no reciben datos de OpenWAF y no son subencargados.

8. Transferencias

Se aplica el apartado 9 del Contrato.

9. Obligaciones del Cliente

Tener una base jurídica para usar Verify e informar a los visitantes de sus webs, por ejemplo con el párrafo que ofrece la página de datos.
No poner datos personales en action ni en cdata del widget, que viajan en forma legible.
Guardar el secreto del widget en sus servidores y llamar a siteverify solo desde ellos.

10. Estado de este borrador

Este anexo aún no lo ha revisado un abogado. Tras la revisión se incorporará al Contrato en una nueva versión con fecha. Dudas: support@openwaf.dev.