Por qué una página de desafío intersticial es inevitable

¿Qué es un desafío intersticial?

Un desafío intersticial es una puerta de verificación servida antes del contenido real. La página inyecta un pequeño fragmento de código — un puzle computacional, una sonda de Web API, una prueba de quirk de navegador — y el cliente tiene que ejecutarlo correctamente para continuar. Si no ejecuta el código, no recibe el contenido.

El modelo invierte la pregunta de verificación. La detección pasiva pregunta *¿qué eres?* e inspecciona las señales que el cliente eligió enviar. Un desafío intersticial pregunta *¿qué puedes hacer?* y mide lo que el cliente realmente ejecuta. Lo primero se puede falsificar con una biblioteca lo bastante buena. Lo segundo requiere correr el código, y correr el código es lo que los scrapers más intentan evitar a escala.

Si no has leído nuestro primer sobre TLS fingerprinting, empieza allí: [TLS Fingerprinting explicado](/es/learn/tls-fingerprinting-explained).

Por qué los desafíos intersticiales importan ahora

El TLS fingerprinting identifica bots inspeccionando los primeros bytes de una conexión. Durante años funcionó. En 2023, Chrome rompió el método de fingerprinting dominante, y las herramientas de spoofing ocuparon ese espacio. La detección pasiva ya no detiene a los scrapers modernos.

JA3 funcionaba hasheando cipher suites y extensiones TLS. Entonces Chrome comenzó a aleatorizar el orden de sus extensiones TLS. Un cliente Chrome con 16 extensiones en orden aleatorio produce 16 factorial variaciones, aproximadamente 20,9 billones de hashes JA3 distintos. Stamus Networks concluyó que JA3 se ha vuelto inútil para identificar clientes y user agents (Stamus Networks, 2024).

JA4 resolvió el problema del ordenamiento. Pero herramientas como curl-impersonate, uTLS y Noble TLS reproducen handshakes reales de navegadores desde scripts. El fingerprint ya no es algo que el cliente revela. Es algo que elige.

DataDome documentó en 2024 que falsificar señales se ha vuelto más fácil, incluso señales de bajo nivel que antes eran difíciles de replicar de forma consistente (DataDome, 2024). Solo el 15,82 % de los bots que imitaban Chrome fueron detectados. El 83 % de los bots simples basados en curl pasaron inadvertidos (DataDome, 2024). Las granjas de resolución de CAPTCHAs cobran ahora $0,80 por cada 1.000 resoluciones, frente a $3 en 2018 (DataDome, 2024). El 95 % de los ataques avanzados de bots pasan desapercibidos (DataDome, 2024). Un sistema que solo confía en las señales que envía el cliente está confiando en el atacante.

Tipos de desafíos intersticiales

Cuatro familias de desafío cubren lo que los sistemas de producción despliegan de verdad.

**Sondas de ejecución JavaScript.** Un payload corre en la página y mide comportamientos que solo producen navegadores reales. Cloudflare Turnstile es el ejemplo canónico: ejecuta pruebas no interactivas en segundo plano que recogen señales sobre el visitante o el entorno del navegador (Cloudflare, 2024). El visitante no ve nada, o como mucho un breve indicador de carga. Cloudflare reporta que esto redujo el tiempo promedio de desafío de 32 segundos en la era del CAPTCHA visual a aproximadamente un segundo (Cloudflare, 2024).

**CAPTCHA (interactivo).** Puzles visuales o auditivos tradicionales que exigen una respuesta humana. Todavía se despliegan en acciones de alto riesgo (alta de cuenta, pago), pero degradados como capa de detección masiva porque las granjas de resolución los canalizan a los costes y tiempos ya mencionados.

**Proof-of-work.** El cliente tiene que calcular un puzle criptográfico antes de recibir contenido. El proyecto Anubis, usado por Arch Wiki, GNOME, WineHQ, FFmpeg y UNESCO, presenta un desafío SHA-256: encontrar un nonce tal que el hash de (desafío + nonce) tenga N ceros a la izquierda. Un navegador real lo resuelve en milisegundos. Un visitante humano apenas lo nota. Una botnet que golpea miles de páginas por minuto paga ese coste de CPU en cada petición, y el coste acumulado se vuelve relevante.

**Sondas conductuales y de Web API.** Timing del ratón, precisión del puntero y comprobaciones de APIs que solo implementan los navegadores reales (cuotas de almacenamiento, estados de permiso, quirks del motor de renderizado). La página vigila si el motor de renderizado se comporta como el que afirma el fingerprint.

Cómo funcionan los desafíos intersticiales

Un desafío intersticial invierte el modelo de verificación. En lugar de preguntar *¿qué eres?*, pregunta *¿qué puedes hacer?*

El mecanismo funciona porque no confía en ninguna señal que el cliente haya enviado. Genera una señal nueva en el sitio, en un entorno que el cliente no puede fingir sin ejecutar realmente el código.

Cloudflare Turnstile adapta el resultado del desafío al visitante o navegador individual. Primero corre una serie de pequeños desafíos JavaScript no interactivos para recoger señales sobre el visitante o entorno (Cloudflare, 2024). El proof-of-work va un paso más allá al forzar al cliente a quemar CPU antes de ser servido. Las sondas conductuales se superponen — si el motor de renderizado devuelve los valores de quirk de un Chrome real, si las Web API responden con las latencias que produce un navegador real.

La economía del crawling de IA hace que los desafíos sean particularmente efectivos. La ratio crawl-a-referral de Anthropic llegó a 500.000:1 — crawleó medio millón de páginas por cada referencia que devolvió como tráfico (Cloudflare, 2025). El tráfico de crawl de entrenamiento de IA subió un 65 % en seis meses, y el crawling de agentes de IA aumentó más de quince veces en 2025 (Cloudflare, 2025). A esos volúmenes, cualquier coste por página se compone. Un desafío que le cuesta un segundo a un navegador real le cuesta lo mismo a una instancia headless de Chrome, pero la instancia headless necesita además asignación de CPU, memoria, un motor completo de renderizado y coordinación de red. Los scrapers HTTP simples (curl, Python requests, Go net/http) no pueden ejecutar JavaScript en absoluto. Llegan a la página de desafío y no obtienen nada. El salto a navegadores headless añade coste, latencia y una nueva superficie de detección.

Cómo identificar qué contenido necesita un desafío

No todas las páginas necesitan un intersticial. Los desafíos tienen un pequeño coste UX, y los lugares correctos para desplegarlos son las rutas donde el scraping es más caro o más dañino.

Empieza con contenido de alto valor: artículos de paywall, páginas de precios propias, APIs de búsqueda, feeds RSS y cualquier endpoint que devuelva datos estructurados a escala. Añade desafíos a los flujos de autenticación, donde en la primera semana de marzo de 2025 el 94 % de las peticiones de autenticación en internet venían de bots (Cloudflare, 2025). Déjalos fuera de páginas de marketing de bajo valor donde el coste de scraping sea menor que el coste de fricción.

El scoring adaptativo de riesgo saca la decisión de la página y la pone en la sesión. Los visitantes de bajo riesgo (IP limpia, fingerprint normal, sesión recurrente) se saltan los desafíos. Los de alto riesgo (proxy residencial, fingerprint inconsistente, sesión first-touch) los ven. El coste UX cae sobre el tráfico que se lo ha ganado.

Alternativas open-source como Anubis demuestran el mismo punto. Corre sobre Arch Wiki, GNOME, WineHQ, FFmpeg y la infraestructura de la UNESCO. Millones de visitantes no notan que el desafío está ahí. La dificultad escala: lo bastante baja para que los navegadores humanos la pasen sin retardo perceptible, lo bastante alta para que las botnets sientan el coste a escala.

Cómo responder a intentos de bypass del desafío

Ninguna defensa es permanente. Los desafíos no son excepción, y la respuesta es capar, no la bala de plata.

Los frameworks anti-CDP como nodriver (más de 590 estrellas en GitHub a mediados de 2024) y las bibliotecas de ghost cursor están construidos específicamente para pasar sondas JavaScript mientras evitan las señales de Chrome DevTools Protocol que un detector normalmente cazaría. La respuesta es vigilar indicadores de bypass — un desafío resuelto en un tiempo anómalamente consistente, una tasa de paso anormalmente alta desde un único ASN, trayectorias de cursor que llegan al botón de submit por curvas geométricamente limpias — y refrescar el payload del desafío. El contenido del desafío debe rotar. Las pruebas cliente deben tomar de un pool en vez de repetirse. La dificultad adaptativa debe subir cuando una sesión parece haber visto ya la prueba.

robots.txt es la señal de lo que falló. Solo el 37 % de los 10.000 dominios principales tienen un archivo robots.txt (Cloudflare, 2025). El 30 % de los scrapes de bots de IA en Q4 2025 no respetaron los permisos explícitos del robots.txt (Tollbit, 2025). El 42 % de los scrapes de ChatGPT-User accedieron a contenido de sitios que los bloquearon explícitamente (Tollbit, 2025). Una página de desafío no es una petición. Es una puerta técnica.

Conclusiones clave

- La detección pasiva se pierde el 95 % de los ataques avanzados de bots (DataDome, 2024). El TLS fingerprinting es falsificable con curl-impersonate y uTLS. robots.txt lo ignora el 30 % de los scrapes de bots de IA (Tollbit Q4 2025). La única señal que un bot no puede falsificar es una que genera bajo demanda, en un entorno que tú controlas. - Cuatro familias de desafío cubren los despliegues de producción: sondas de ejecución JavaScript, CAPTCHA, proof-of-work y sondas conductuales/Web API. Cloudflare Turnstile corre en aproximadamente un segundo, frente a los 32 segundos de la era CAPTCHA. - Apunta los desafíos a rutas de alto valor (paywalls, precios, APIs de búsqueda, autenticación). El scoring adaptativo de riesgo mantiene sin fricción a los visitantes de bajo riesgo y concentra el coste UX en el tráfico que se lo ha ganado. - Los desafíos son la capa de aplicación, no un reemplazo del fingerprinting o el análisis conductual. Centinel integra verificación basada en desafíos con más de 1.600 fingerprints de crawler y detección conductual por capas.