How We Built a System That Scans 100,000 Websites for Cookie Consent Violations

La verificación automatizada del cumplimiento del consentimiento suena sencilla hasta que intentas construirla. El enfoque ingenuo -- obtener una página, buscar cookies, buscar un banner -- falla en captar la mayor parte de lo que importa. Las violaciones de consentimiento son conductuales, no estructurales. Se manifiestan en el timing de la ejecución de scripts, la secuencia de solicitudes de red, la respuesta de elementos de interfaz a la interacción del usuario y la persistencia del estado a través de cargas de página. No puedes evaluar nada de esto sin ejecutar un navegador real, interactuar con la página como lo haría un humano y registrar lo que realmente sucede a nivel de red.

Este artículo describe cómo construimos el motor de escaneo detrás de GDPR Monitor, los desafíos de ingeniería que consumieron la mayor parte de nuestro tiempo, las decisiones arquitectónicas que tomamos y por qué, y las limitaciones sobre las que somos honestos. Si trabaja en cumplimiento web, automatización de navegador o medición web a gran escala, debería encontrar algo útil aquí.

Visión general del pipeline

Cada escaneo pasa por seis etapas. Entender el pipeline es contexto necesario para los desafíos específicos que siguen.

Etapa 1: Lanzamiento del navegador y aislamiento. Una instancia Chromium limpia arranca con cero estado -- sin cookies, sin localStorage, sin caché, sin service workers. Esta es la garantía de sala limpia que hace significativa la medición pre-consentimiento. Configuramos un viewport estándar, encabezados User-Agent y Accept-Language realistas que coincidan con el país objetivo, y flags estándar del navegador. Cada escaneo obtiene su propio proceso de navegador; no hay fuga de estado entre escaneos. Etapa 2: Navegación y captura pre-consentimiento. El escáner navega a la URL objetivo, espera a que la página alcance un estado estable (red inactiva, DOM estabilizado) y captura todo lo que ha sucedido: cookies establecidas, solicitudes de red realizadas (con URL completa, timing y metadatos de respuesta), dominios de terceros contactados y una captura de pantalla completa. Esta captura responde la pregunta fundamental: ¿qué hizo este sitio web antes de que el usuario tuviera cualquier oportunidad de consentir? Etapa 3: Detección CMP e identificación de banner. El escáner intenta identificar la plataforma de gestión de consentimiento y localizar el banner de consentimiento, el botón de aceptar y el botón de rechazar. Esto usa un sistema de detección multicapa descrito en detalle abajo. Etapa 4: Interacción de consentimiento. El escáner interactúa con el banner -- hace clic en aceptar para el flujo estándar, hace clic en rechazar para la prueba del flujo de rechazo. Espera a que la página se estabilice después de la interacción, considerando animaciones, reevaluación de scripts y disparo retrasado de etiquetas. Etapa 5: Captura post-consentimiento y análisis diferencial. Una segunda captura completa captura el estado después de la interacción de consentimiento. Comparar las capturas pre y post-consentimiento revela qué cambió: nuevas cookies, nuevas solicitudes de rastreo, estado de consentimiento en APIs de CMP. Etapa 6: Análisis, clasificación y generación de informes. Los datos brutos alimentan módulos de análisis: clasificación de cookies contra nuestra base de datos, coincidencia de rastreadores contra patrones conocidos, evaluación de duración de vida de cookies, auditoría de accesibilidad del banner, validación de Google Consent Mode, detección de señales de huella digital y puntuación de riesgo. La salida es un informe estructurado con hallazgos, artefactos de evidencia y una puntuación de riesgo compuesta.

Cada etapa produce evidencia con marca de tiempo que se almacena de forma durable. Cualquier hallazgo puede rastrearse hasta solicitudes de red específicas, entradas de cookies o capturas de pantalla.

Desafío 1: Detección CMP -- 45 plataformas, variaciones infinitas

La gestión del consentimiento no está estandarizada. No hay atributo HTML universal, no hay API JavaScript obligatoria, no hay estructura DOM consistente que diga "esto es un banner de consentimiento". Hay 45 CMP distintos en nuestra biblioteca de detección, cada uno con su propia estructura DOM, firmas de scripts, globales JavaScript y patrones de interacción. Más allá de estos, el 34,7% de los banners que detectamos en nuestro estudio de 97.304 sitios fueron genéricos o no identificados.

Nuestra detección usa un enfoque multicapa basado en confianza:

Capa 1: Detección de firma de script

El escáner verifica la presencia de scripts CMP conocidos por patrón de URL y variables globales JavaScript. Cookiebot se carga desde `consent.cookiebot.com` y expone `window.Cookiebot`. OneTrust se carga desde `cdn.cookielaw.org` y expone `window.OneTrust`. Cada CMP tiene patrones de carga característicos detectables antes de examinar el DOM.

Capa 2: Coincidencia de selectores verificados

Para cada CMP conocido, mantenemos un conjunto curado de selectores CSS que identifican confiablemente el contenedor del banner, el botón de aceptar y el botón de rechazar, validados a través de múltiples versiones y configuraciones.

Capa 3: Coincidencia de selectores compatibles

Un conjunto más amplio de selectores que funcionan a través de muchas versiones de un CMP pero son menos precisos, intercambiando precisión por cobertura.

Capa 4: Heurísticas genéricas

Para el 34,7% de banners no asociados con un CMP conocido, recurrimos a detección heurística buscando elementos de posición fija, palabras clave de consentimiento en múltiples idiomas, botones con etiquetas de acción de consentimiento comunes y patrones estructurales típicos de diálogos de consentimiento.

Capa 5: Sondeo de API CMP

Algunos CMP exponen APIs JavaScript -- notablemente la API IAB TCF vía `__tcfapi`. Sondeamos estas APIs para verificar la detección y leer el estado de consentimiento programático.

El modelo de confianza

En lugar de tratar la detección como binaria, asignamos puntuaciones de confianza basadas en qué capas coincidieron y con qué fuerza. Esto alimenta nuestra clasificación de riesgo -- menor confianza de detección significa que los hallazgos son más probables de ser clasificados como no concluyentes.

Desafío 2: El flujo de rechazo -- Por qué "hacer clic y verificar" es sorprendentemente difícil

Encontrar el botón de rechazo. No todos los botones de rechazo están etiquetados como "Rechazar". Pueden decir "Declinar todo", "Solo cookies necesarias", "Gestionar configuración" o equivalentes en docenas de idiomas. Nuestro escáner mantiene un conjunto multilingüe de patrones de acción de rechazo. Esperar el momento correcto. Después de hacer clic en rechazar, usamos una espera multi-señal: inactividad de red, estabilidad DOM y un piso de retraso mínimo, calibrados empíricamente a través de cientos de configuraciones CMP. La prueba de recarga y reaparición del consentimiento. El paso de recarga reveló la reaparición del consentimiento como fenómeno. Añadimos detección explícita de reaparición: después del flujo de rechazo, el escáner recarga la página, espera estabilidad y compara el inventario de cookies con la captura post-rechazo. Esto capturó 1.642 sitios con 4.932 cookies reapareciendo. El sondeo `waitForScriptIdentifiedCMP`. Algunos CMP se cargan asincrónicamente. Implementamos un mecanismo de sondeo que espera a que la API JavaScript del CMP esté disponible antes de continuar, reduciendo significativamente los falsos negativos.

Desafío 3: Saturación del pipeline a escala

Escanear 97.304 sitios web no es trabajo para una sola máquina. Cada escaneo lanza un proceso Chromium, navega a un sitio web, intercepta cientos de solicitudes de red, toma capturas y ejecuta módulos de análisis. Un escaneo individual toma 30-90 segundos.

La arquitectura de semáforos

Usamos un modelo de concurrencia basado en semáforos para limitar los procesos Chromium simultáneos por worker (15 slots en producción), previniendo el agotamiento de memoria y proporcionando contrapresión contra la cola Redis.

La exención de solicitud de documento

Las solicitudes de tipo documento a la URL objetivo pre-validada saltan el pipeline completo de intercepción, una optimización significativa de rendimiento ya que la solicitud del documento bloquea todo lo demás.

Precalentamiento DNS

Implementamos precalentamiento DNS usando un caché de resolvedor DNS local Unbound, reduciendo la sobrecarga DNS por dominio a menos de un milisegundo.

Seguridad SSRF a escala

Cada solicitud interceptada se verifica contra reglas de seguridad, bloqueando solicitudes a rangos IP privados. Añadimos categorización explícita de errores para distinguir bloqueos SSRF genuinos de saturación de semáforos.

Desafío 4: Detección de evasión de bots

Identificamos 137 sitios web que parecen ocultar deliberadamente su banner de consentimiento de escáneres automatizados, más comúnmente usando la opción `isAcceptAllForBots` de RCB (Real Cookie Banner). Señalamos estos sitios por separado en nuestros resultados.

Desafío 5: Mala identificación de CMP

Un sitio puede cargar múltiples scripts que parecen CMP. Nuestro enfoque basado en confianza aborda esto clasificando candidatos CMP: verificando qué tiene un banner visible en el DOM, qué expone una API CMP activa, y prefiriendo el CMP cuyos selectores verificados coincidan con elementos DOM visibles.

Limitaciones

Banners dependientes de GeoIP. Nuestros escaneos se originan desde ubicaciones de red específicas en Europa. Shadow DOM cerrado. Algunos CMP renderizan dentro de shadow DOM cerrado, inaccesible a consultas DOM estándar. Nombres de clase dinámicos. Algunos CMP usan nombres de clase generados dinámicamente. Aplicaciones de página única. Las SPA que gestionan consentimiento en estado del lado del cliente son más difíciles de evaluar. Cobertura lingüística. Nuestra detección de botones de rechazo no cubre cada idioma de la UE igualmente. Casos límite de timing. Scripts que se ejecutan mucho después de la carga de página pueden ser perdidos.

Estas limitaciones contribuyen a nuestra tasa del 14,9% no concluyente.

La infraestructura

• Motor de escaneo: Aplicación Go usando chromedp como cliente CDP para automatización Chromium.
• Runtime del navegador: Chromium headless lanzado por escaneo vía CDP.
• Cola: Cola de trabajo respaldada por Redis distribuyendo URLs a workers.
• Base de datos: PostgreSQL para resultados de escaneo durables y datos estructurados.
• Caché DNS: Resolvedor local Unbound proporcionando resoluciones DNS en caché.
• Almacenamiento de evidencia: Capturas de pantalla, archivos HAR e informes PDF almacenados como artefactos durables.

Para el estudio de 97.304 sitios, procesamos 114.748 URLs candidatas durante aproximadamente 2,5 días usando 3 instancias de servidor. El rendimiento pico fue aproximadamente 25-30 escaneos completados por minuto por servidor. El cuello de botella principal fue la red, no CPU o memoria.

Desafíos abiertos y trabajo futuro

Localización de banners de consentimiento. Expandir la cobertura de idiomas requiere no solo añadir traducciones sino validar que los selectores y patrones de interacción funcionen correctamente con versiones CMP localizadas. Monitoreo longitudinal. Detectar cambios en el comportamiento de consentimiento a lo largo del tiempo requiere escaneos repetidos con análisis diferencial. Benchmarking de cumplimiento CMP. Deslindar la calidad del CMP de la calidad de configuración del operador del sitio es metodológicamente complejo. Verificación de estado de consentimiento en tiempo real. Integrar la verificación de consentimiento en pipelines CI/CD requiere un modo de escaneo más rápido y ligero.

La API

El mismo motor de escaneo descrito en este artículo está disponible a través de la API pública de GDPR Monitor. Puede enviar solicitudes de escaneo programáticamente, consultar resultados y recuperar hallazgos estructurados y artefactos de evidencia.

---

Pruébelo usted mismo. La documentación de la API está disponible en gdprmonitor.eu/developers/api. Envíe una URL única o integre monitoreo automatizado de privacidad en su flujo de trabajo.