El WAF de Cloudflare ya no solo pregunta si una petición parece un ataque: desde el 21 de octubre de 2026 también mira qué devolvió el origen y puede bloquear esa respuesta antes de que llegue al atacante. Las full transaction detections y las reglas sobre la respuesta están disponibles en todos los planes, incluido el gratuito, y las primeras reglas gestionadas cubren php2shell.
Qué cambia
Hasta ahora, las reglas gestionadas, las personalizadas y el rate limiting del WAF trabajaban sobre la petición. Cloudflare añade dos piezas:
- Detecciones de transacción completa: correlacionan cada petición con su respuesta para encontrar indicios de que un exploit ha funcionado.
- Reglas de respuesta: si una regla coincide, Cloudflare sustituye la respuesta del origen por su página de bloqueo (HTTP 403) o por una respuesta personalizada.
El ejemplo de Cloudflare lo explica bien. Un GET /download?file=../../config/database.ini es un path traversal reconocible, pero la petición sola no dice si la aplicación entregó el fichero. Si el origen responde 200 OK con algo que parece un .ini con usuario y contraseña, la combinación es una prueba mucho más fuerte que cualquiera de las dos señales por separado.
Por qué importa
La inspección de peticiones obliga a elegir entre firmas amplias, que generan falsos positivos y rompen tráfico legítimo, y firmas estrictas, que dejan pasar lo ambiguo. Mirar el resultado permite ser más agresivo solo cuando hay evidencia de impacto. Cloudflare lo justifica también por los agentes que buscan vulnerabilidades: insisten, adaptan el payload según lo que devuelve la aplicación y encadenan fallos, así que la respuesta es justo lo que les sirve para seguir.
Para un equipo de SRE el valor práctico es otro: una regla que bloquea solo cuando el origen ya ha fallado es una red de seguridad para la ventana entre que se publica un CVE y se despliega el parche, como pasó con php2shell.
Qué incluye cada plan
| Todos los planes (incluido Free) | Planes de pago | |
|---|---|---|
| Ruleset gestionado Cloudflare Managed Response Firewall Default | Sí, centrado en vulnerabilidades muy sonadas | Sí, con un catálogo más amplio |
| Reglas personalizadas de respuesta | Hasta 3, con acciones Log y Block | Hasta 3, con los campos de su plan |
Campos cf.waf.signature.response.* | No | Sí (en despliegue progresivo) |
| Reglas sobre el cuerpo de la respuesta | No disponible todavía | No disponible todavía |
Los campos nuevos son cf.waf.signature.response.confidence, cf.waf.signature.response.categories y cf.waf.signature.response.ref (hasta diez IDs de firma), análogos a los de Attack Signature Detection en la petición. Si tu cuenta aún no los ve, Cloudflare pide contactar con el equipo de cuenta.
Cómo activarlo
Las reglas están en el panel, al final de Security > Security Rules. El ruleset gestionado se aplica a todas las peticiones por defecto; puedes limitar su alcance a una ruta o excluir partes de la aplicación si da falsos positivos.
Una regla personalizada útil es proteger un panel de administración que solo debería verse tras un gateway de autenticación. Esta expresión, adaptada del ejemplo de Cloudflare, bloquea solo cuando una petición sin la cabecera interna recibe del origen una página HTML con código 200:
http.request.uri.path starts_with "/admin"
and not http.request.headers["x-internal-user"][0] eq "true"
and http.response.code eq 200
and http.response.headers["content-type"][0] contains "text/html"No bloquea redirecciones al login ni errores de autenticación: solo el caso en que el origen ha servido el panel. Los eventos aparecen en Security Events, dentro de los servicios Managed Rules o Custom Rules, y se pueden filtrar por el ID de la regla.
La cautela que importa
Bloquear la respuesta no deshace lo que ya pasó en el origen. Si el exploit era una escritura, una ejecución remota o un borrado, la regla evita que el atacante vea el resultado, pero el daño está hecho. Es una capa para contener fugas de datos y confirmar explotaciones, no un sustituto del parche. Y como las reglas sobre el cuerpo todavía no existen, la detección de datos sensibles en el contenido depende de las firmas gestionadas de Cloudflare.