Modo bajo ataqueNuevo

El modo bajo ataque pone el reto de navegador delante de toda la zona. Mientras está activado, toda navegación de navegador sin un pase válido recibe la página del reto, diga lo que diga la barrera, y cualquier otra petición sin pase recibe un 403 breve. Los clientes que no pueden ejecutar JavaScript dejan de llegar a tu origen; los visitantes reales esperan un momento, pulsan «Soy humano» una vez y luego navegan con normalidad.

Viene desactivado, se configura para toda la zona (opcionalmente solo para algunos de sus nombres) y puede desactivarse solo a la hora que elijas.

#Cuándo usarlo

Actívalo mientras dure un ataque que tus reglas habituales no consiguen frenar:

• una avalancha en la capa de aplicación (L7): muchas direcciones pidiendo tus páginas, demasiado repartidas para que el límite de peticiones o las reglas de IP y ASN las paren;
• una oleada de scraping desde proxies rotatorios o direcciones residenciales.

Fija una hora de fin al activarlo, para que no se quede activado cuando el ataque haya pasado.

#Qué ven los visitantes

Una navegación de navegador (un GET o HEAD cuyo Accept incluye text/html, sin Sec-Fetch-Mode o con navigate) sin un pase válido recibe la página del reto:

1. Responde 503 con Retry-After: 30, Cache-Control: no-store, X-Robots-Tag: noindex y OpenWAF-Mitigated: challenge. Un HEAD recibe solo las cabeceras.
2. Dice «Comprobando tu navegador antes de acceder a www.example.com» (en inglés, «Checking your browser before accessing www.example.com»), con la marca de la zona, su color de acento y el idioma del visitante.
3. El navegador resuelve la prueba de trabajo mientras la página indica que está comprobando. Por defecto es un bit más difícil que el reto normal del nombre, lo que duplica el trabajo: normalmente menos de un par de segundos, algo más en móviles lentos.
4. Con el paso interactivo (activado por defecto), la página pide entonces «Verifica que eres humano» y muestra un botón «Soy humano» («I am human» en inglés). El visitante hace clic, lo toca o pulsa Intro o Espacio sobre él.
5. La página muestra «Verificando…» y, cuando el borde lo acepta, «Listo. Cargando la página…»: el borde pone la cookie __waf_pass y la página se recarga. Mientras el pase sea válido, el visitante navega con normalidad. Si la comprobación falla, la página ofrece un botón «Reintentar».

A diferencia de la barrera, el modo bajo ataque también muestra la página en los nombres api.*. Los pases obtenidos antes de activarlo siguen valiendo hasta que caducan.

#Paso interactivo

Con una conexión rápida la prueba de trabajo termina antes de que el visitante se dé cuenta, así que una página que pasara sola parecería que no protege nada, y un script capaz de calcular SHA-256 pasaría igual. Por eso, durante el modo bajo ataque, la página pide por defecto un clic o una pulsación de tecla en un botón (interactive: true). Es fricción para los scripts, no una prueba de que haya una persona:

• El botón aparece cuando la prueba de trabajo está resuelta, recibe el foco del teclado y sus estados se anuncian a los lectores de pantalla. Usa la marca y el color de acento de la zona y sigue la preferencia de modo claro u oscuro, como el estado interactivo del widget Verify.
• Solo cuenta un evento de entrada de confianza del navegador sobre el botón (un clic, un toque, o Intro o Espacio): un clic sintetizado por un script de la página, como element.click(), no es de confianza y falla. El borde también rechaza un clic que llega demasiado pronto tras aparecer el botón o tras emitirse el reto, lo que frena los reenvíos instantáneos: /__waf/verify responde 403 con interaction-required y la página ofrece «Reintentar». Esos intentos cuentan como retos fallidos.
• Los navegadores que declaran estar automatizados (navigator.webdriver) reciben el mismo botón que todo el mundo: no hay huella digital adicional.
• Los pases, su duración y su ámbito no cambian; solo cambia cómo se obtienen.

Efecto en la automatización. Los scrapers y las herramientas de avalancha que solo descargan tus páginas, o que las cargan en un navegador sin interfaz y resuelven la prueba de trabajo sin entrada real, ya no obtienen pase. La automatización que inyecta entrada a nivel del navegador o del sistema operativo (por ejemplo Playwright o Puppeteer manejando el protocolo DevTools) genera eventos de confianza y puede pasar, igual que una persona a la que se paga por pulsar. El paso encarece cada pase nuevo, red por red; no demuestra intención humana. Las peticiones que nunca ven la página (API, webhooks, rutas exceptuadas) no se ven afectadas en ningún caso.

Pon interactive a false para volver a la prueba de trabajo sola, de modo que la página pase sola, por ejemplo mientras pruebas el modo en un nombre de pruebas o si tus visitantes usan quioscos donde nadie puede pulsar. Consulta Activarlo y desactivarlo.

#API, apps móviles y webhooks

Cualquier otra petición sin pase recibe 403, nunca la página HTML: llamadas a la API, envíos de formularios, fetch y XHR, apps móviles, webhooks, llamadas entre servidores. El cuerpo es JSON cuando Accept incluye json o la petición es un fetch (Sec-Fetch-Mode cors, same-origin o no-cors):

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store
OpenWAF-Mitigated: challenge
X-Robots-Tag: noindex

{"error":"challenge_required","message":"www.example.com is under attack protection. Open it in a browser to continue."}

Si no, es una línea de texto plano, y un HEAD no lleva cuerpo. Tus clientes pueden reconocerlo por la cabecera OpenWAF-Mitigated: challenge.

• Tu propia web. Las llamadas que hacen páginas que ya pasaron el reto llevan la cookie y pasan. Si www.example.com llama a api.example.com, pon pass_scope: zone para que un pase cubra los dos nombres, y haz las llamadas con credenciales.
• Apps móviles, socios y clientes entre servidores no pueden tener pase. Deja fuera sus nombres con hosts, exceptúa sus rutas o permite sus direcciones con una regla allow de IP o de ASN.
• Webhooks de pasarelas de pago y otros servicios: exceptúa sus rutas.

GET /__waf/status responde "required": true en un nombre cubierto, así que una aplicación de una sola página puede recargar una vez para obtener el pase, igual que con la barrera.

#Qué pasa sin reto

Estas peticiones se saltan el modo bajo ataque (el resto del borde, como el WAF y los límites de peticiones, se les sigue aplicando):

#Exceptuar webhooks

Los webhooks, las notificaciones de pago y los chequeos de salud no pueden resolver un reto. Añade sus prefijos de ruta a exempt_paths (hasta 50; una lista nueva sustituye la lista entera) al activar el modo o después:

{"challenge": {"under_attack": {"exempt_paths": ["/webhooks/stripe", "/api/payments/callback", "/healthz"]}}}

Las rutas exceptuadas siguen pasando por el WAF, los límites de peticiones y tus reglas. Si un proveedor publica las direcciones desde las que envía, también sirve una regla allow de IP para ellas.

#Solo algunos nombres

hosts limita el modo a algunos nombres de la zona (hasta 50, el ápex o nombres bajo él); una lista vacía cubre todos los nombres con proxy. Por ejemplo, protege www.example.com y shop.example.com y deja api.example.com, que usa tu app móvil, como está:

{"challenge": {"under_attack": {"enabled": true, "hosts": ["www.example.com", "shop.example.com"]}}}

El modo es un ajuste de la zona: también cubre los nombres que tienen sus propios ajustes challenge, y no se puede fijar por nombre con hosts.<nombre>.challenge.

#Dificultad y duración del pase

• difficulty: 0 (por defecto) usa la dificultad del reto del nombre más un bit, hasta 24, así que los atacantes pagan el doble del trabajo habitual. Pon 10–24 para un valor fijo; cada bit más duplica el trabajo, también para tus visitantes.
• pass_ttl_minutes: 0 (por defecto) mantiene la duración del pase del nombre. Pon 5–10080 para dar pases más cortos, por ejemplo 60, de modo que un reto resuelto no se pueda reutilizar mucho tiempo. Se aplica a los pases obtenidos mientras el modo está activado.

#Fin automático

until es la hora (RFC 3339, UTC) a la que el modo se desactiva solo: más de un minuto por delante y como mucho 30 días. null lo mantiene activado hasta que lo desactives.

Cuando pasa until, en unos 30 segundos el plano de control desactiva el modo como un cambio normal: crea una versión nueva de la zona con el motivo «Under attack mode expired (until 2026-10-28T18:00:00Z)», que ves en el historial de la zona y en el registro de auditoría, y los nodos de borde la aplican como cualquier otra versión. Desactivar el modo a mano borra until.

#Activarlo y desactivarlo

Cada cambio se simula primero, necesita un motivo, crea una versión nueva y se puede revertir.

openwaf-cloud ctl zones under-attack example.com on --for 6h --exempt /webhooks/stripe --reason "Avalancha HTTP"
openwaf-cloud ctl zones under-attack example.com status
openwaf-cloud ctl zones under-attack example.com off --reason "Fin del ataque"

curl -s -X PATCH "https://dash.openwaf.dev/v1/orgs/$ORG/zones/$ZONE/edge?dry_run=1" \
  -H "Authorization: Bearer $OPENWAF_TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Change-Reason: Avalancha HTTP" \
  -d '{"challenge": {"under_attack": {"enabled": true, "until": "2026-10-28T18:00:00Z", "exempt_paths": ["/webhooks/stripe"]}}}'

#Campos

challenge.under_attack en los ajustes de borde de la zona:

Los campos se combinan uno a uno como el resto de ajustes; hosts y exempt_paths sustituyen la lista entera, un campo a null vuelve a su valor por defecto y "under_attack": null desactiva el modo y restablece todos los campos. hosts.<nombre>.challenge.under_attack se rechaza con 422: usa challenge.under_attack.hosts.

#Seguir el ataque

Dominio → Seguridad → Verificación muestra si el modo está activado, hasta cuándo y si pide clic, y los retos que emitió, que se resolvieron y que fallaron bajo el disparador under_attack, junto al resto de la analítica de retos. Las resoluciones con el clic «Soy humano» se cuentan además como interactivas. Una petición que dice falsamente ser un rastreador se cuenta en crawler. El mismo informe está en openwaf-cloud ctl challenge report example.com, GET /v1/orgs/{org}/zones/{zone}/challenge/analytics y la herramienta MCP challenge_report.

Una tasa de resolución alta indica que son sobre todo visitantes reales; muchos retos emitidos que nunca se resuelven, o muchos fallos en el paso interactivo, son el ataque detenido en el borde.