Ilustración conceptual del recorrido de solicitud y respuesta que describe el artículo: una solicitud, un panel de seguridad, el origen, un paso de inspección y dos resultados posibles, entregada o bloqueada. No es la arquitectura real de Cloudflare.
Cloudflare ha introducido funciones de firewall de aplicaciones web que examinan las solicitudes HTTP junto con las respuestas del origen. El enfoque ayuda a distinguir las solicitudes sospechosas de los indicios de que una explotación pudo haber tenido éxito, y permite bloquear determinadas respuestas antes de que lleguen al solicitante.
Un firewall de aplicaciones web puede identificar un intento de acceder a un archivo sensible antes de que la solicitud llegue a una aplicación. Pero cuando esa solicitud se deja pasar, cobra importancia otra pregunta: ¿cómo respondió la aplicación?
El anuncio de Cloudflare ilustra el problema con un endpoint hipotético de descarga de archivos que recibe esta solicitud:
GET /download?file=../../config/database.ini
La secuencia de recorrido de rutas (path traversal) sugiere un intento de salir del directorio de descarga permitido. Un firewall de aplicaciones web (WAF) basado en solicitudes podría identificar el patrón y bloquearlo antes de que el origen lo procese.
Sin embargo, si la solicitud llega a la aplicación, su contenido por sí solo no permite establecer el resultado. El servidor podría rechazar la ruta, devolver un error o exponer un archivo de configuración.
El 21 de octubre de 2026, Cloudflare presentó la detección de transacción completa (full-transaction detection), que amplía su WAF para evaluar las solicitudes HTTP entrantes junto con las respuestas correspondientes del origen.
La empresa también presentó reglas de respuesta que pueden impedir que determinadas respuestas del origen lleguen al solicitante.
En principio, el cambio técnico es sencillo: los defensores obtienen otra oportunidad de evaluar un intercambio HTTP después de que la aplicación haya procesado la solicitud, en lugar de depender por completo de los indicadores visibles de antemano.
Seguir la solicitud a través del WAF de Cloudflare
Un WAF en fase de solicitud actúa antes de que la aplicación de origen gestione una solicitud entrante.
Cloudflare puede examinar propiedades como la ruta de la URL, los parámetros de consulta, los encabezados y otros datos disponibles de la solicitud. Según las reglas configuradas, puede permitir la solicitud, bloquearla o aplicar otra acción compatible.
En el ejemplo de descarga de archivos, un bloqueo temprano impediría que el origen procesara el intento de recorrido de rutas.
Pero no todas las aplicaciones interpretan igual las entradas sospechosas. Una carga útil (payload) concreta puede ser inofensiva en un entorno y explotable en otro por diferencias de enrutamiento, validación de entradas, permisos del sistema de archivos o comportamiento de la aplicación.
La detección de transacción completa introduce un segundo punto de observación.
Cuando una solicitud continúa hasta el origen, Cloudflare puede correlacionar la solicitud original con la respuesta HTTP que produce la aplicación. Las firmas de detección gestionadas pueden tener en cuenta señales de la respuesta junto con la entrada sospechosa para identificar indicios compatibles con una explotación.
Supongamos que el endpoint de descarga devuelve HTTP 200 y un contenido reconocible como un archivo de configuración protegido. Esa combinación puede respaldar una conclusión más sólida sobre la exposición de información que la cadena de recorrido de rutas por sí sola.
El código de estado por sí mismo no demostraría la exposición. La evidencia relevante sería la relación entre la operación solicitada y lo que la respuesta contenía realmente.
Si coincide una regla de bloqueo en fase de respuesta, Cloudflare puede sustituir la respuesta del origen por una página de bloqueo del WAF (servida con HTTP 403 en el ejemplo de Cloudflare) o por una alternativa configurada, en lugar de reenviar la respuesta original.
El modelo de procesamiento resultante tiene dos puntos de control: uno antes de que el origen ejecute la solicitud y otro después de que el origen responda, pero antes de que se entregue la respuesta.
Diagrama conceptual de TechiesJournal del modelo de procesamiento descrito en el artículo; no es un diagrama oficial de Cloudflare.
Versión en texto de la figura 1
- Un cliente envía una solicitud HTTP.
- Antes del origen: el WAF en fase de solicitud es el punto de control 1. Si bloquea, la solicitud se rechaza antes del origen.
- Si continúa, el origen procesa la solicitud y produce una respuesta HTTP.
- Después de que el origen responde y antes de la entrega: se correlacionan las señales de la solicitud y de la respuesta.
- La regla de respuesta es el punto de control 2. Si permite o registra, se entrega la respuesta del origen. Si bloquea, la respuesta se sustituye por un bloqueo del WAF.
Qué cambia la evidencia de la respuesta
Una solicitud sospechosa puede revelar un intento de ataque sin demostrar que la aplicación fuera vulnerable.
La información de la respuesta puede ayudar a establecer si la aplicación se comportó de forma compatible con una explotación exitosa.
Una carga útil de recorrido de rutas seguida de una respuesta de acceso denegado no es lo mismo que una seguida de datos de configuración privados reconocibles. Del mismo modo, una entrada sospechosa que solo produce un error genérico aporta una evidencia distinta de la de una respuesta que contiene información que normalmente no está al alcance del solicitante.
Las primeras detecciones de transacción completa de Cloudflare se centran en determinadas vulnerabilidades de alto perfil. La empresa afirma que tiene intención de ampliar la cobertura a otras formas de exposición y exfiltración de datos.
Este contexto adicional puede mejorar la investigación del tráfico sospechoso, sobre todo cuando grandes volúmenes de sondeos dificultan priorizar las alertas basadas solo en solicitudes.
No es un método universal para determinar si un ataque tuvo éxito. Algunos ataques exitosos no producen ninguna respuesta HTTP distintiva, mientras que respuestas legítimas de la aplicación pueden parecerse en ocasiones a una salida sospechosa.
Su valor depende de las firmas de detección, del comportamiento concreto de la aplicación y de la relación entre los indicadores del lado de la solicitud y los del lado de la respuesta.
Metadatos de detección y reglas de respuesta
Cloudflare separa la detección de la aplicación de la acción correspondiente.
Una detección identifica un patrón coincidente y pone el resultado a disposición como metadatos de la transacción. Una regla determina si ese resultado debe registrarse o usarse para bloquear la respuesta.
Para las firmas de transacción completa, Cloudflare introdujo tres campos de metadatos del lado de la respuesta:
| Campo | Significado |
|---|---|
cf.waf.signature.response.confidence | Valores de confianza de las firmas coincidentes |
cf.waf.signature.response.categories | Categorías asociadas a las firmas coincidentes |
cf.waf.signature.response.ref | ID de referencia de las firmas coincidentes, hasta 10 |
Estos campos permiten a los equipos de seguridad combinar los resultados de detección del lado de la respuesta con el contexto de la solicitud al crear políticas a medida.
Por ejemplo, un equipo podría aplicar una restricción adicional a una ruta administrativa sensible sin afectar a las rutas de la aplicación que no tienen relación con ella.
Una regla de respuesta también puede funcionar sin esos campos de firma, evaluando directamente propiedades de la solicitud y de la respuesta.
El ejemplo publicado por Cloudflare combina un prefijo de URL /admin, un encabezado de solicitud que representa la autenticación interna, una respuesta HTTP 200 y un tipo de contenido HTML.
La regla pretende bloquear una respuesta exitosa de una página de administración cuando falta el marcador de autenticación esperado, sin tratar cada visita a /admin como una exposición.
Esa distinción es útil porque las reglas de respuesta pueden tener en cuenta el comportamiento HTTP real del origen y no solo la URL de la solicitud.
Cuando una regla de respuesta configurada bloquea una transacción, la respuesta del origen se sustituye antes de entregarse al solicitante.
Sin embargo, bloquear una respuesta no deshace las acciones que la aplicación ya ha realizado, como señala el anuncio de Cloudflare.
Si la solicitud provocó un cambio en la base de datos, ejecutó un comando o desencadenó otra operación en el servidor, la regla de respuesta no puede revertir ese efecto secundario.
Por tanto, el bloqueo en fase de respuesta es un mecanismo de contención para determinadas divulgaciones en respuestas, no un sustituto de la protección en fase de solicitud, de la autorización en la aplicación ni de la corrección de vulnerabilidades.
¿Qué tienen disponible los clientes de Cloudflare?
Según el anuncio de Cloudflare del 21 de octubre, la detección de transacción completa está disponible de forma general para las zonas cuyo tráfico pasa por el proxy de Cloudflare.
Las protecciones de respuesta gestionadas y las reglas de respuesta personalizadas se lanzaron en todos los planes, incluido Free.
Cloudflare ofrece un conjunto de reglas de respuesta gestionado, Cloudflare Managed Response Firewall Default, que según Cloudflare se ejecuta por defecto en cada solicitud y que, según su publicación sobre PHP, se desplegó automáticamente para los clientes de todos los planes, incluido Free. Por tanto, los clientes quedan cubiertos sin tener que construir políticas individuales basadas en firmas. Una regla gestionada que coincida puede bloquear la respuesta y devolver una página de bloqueo estándar del WAF. El alcance puede ajustarse para limitar dónde se aplican esas protecciones.
Todos los planes pueden crear además hasta tres reglas de respuesta personalizadas, que admiten las acciones de registro (Log) y bloqueo (Block). Estas reglas pueden combinar las propiedades de solicitud y de respuesta disponibles en el plan del cliente.
Hay dos restricciones importantes.
Primero, las reglas de respuesta personalizadas todavía no pueden escribirse sobre el cuerpo de la respuesta. Las firmas gestionadas de detección de transacción completa de Cloudflare pueden examinar señales de la respuesta, pero los clientes aún no pueden escribir sus propias condiciones sobre el cuerpo de la respuesta.
Segundo, los nuevos campos cf.waf.signature.response.* para crear políticas a medida a partir de las detecciones gestionadas están pensados para clientes de pago. Cloudflare indicó que esos campos todavía se estaban desplegando en las cuentas de los clientes cuando se anunció la función.
Por tanto, la disponibilidad del motor de reglas de respuesta no debe confundirse con el acceso a todos los campos de detección.
Los administradores pueden encontrar los controles de la fase de respuesta en Security → Security Rules del panel de Cloudflare. Cloudflare también muestra la información de detección pertinente en Security Analytics y registra las acciones de las reglas coincidentes en Security Events.
En una aplicación en producción, la primera tarea es revisar qué firmas coinciden, identificar las rutas afectadas y decidir si la acción de respuesta configurada es adecuada. Una política de bloqueo amplia puede ser innecesaria cuando la exposición relevante se limita a un endpoint concreto.
Por qué importó la respuesta a PHP2Shell
Cloudflare introdujo la nueva función mientras desarrollaba protecciones para las vulnerabilidades de PHP de octubre de 2026, conocidas comúnmente como PHP2Shell.
La empresa describió cómo los atacantes modificaban las cargas útiles de las solicitudes al intentar eludir las protecciones anteriores basadas en solicitudes. Examinar las respuestas del origen aportó evidencia adicional sobre qué intentos podrían haber tenido éxito.
Esa experiencia contribuyó a las primeras firmas de transacción completa.
TechiesJournal ya ha cubierto las vulnerabilidades y los requisitos de parcheo en su informe de seguridad sobre PHP2Shell (en inglés). Lo relevante aquí es el modelo de procesamiento del WAF que surgió de esos esfuerzos defensivos.
En lugar de depender exclusivamente de patrones sospechosos en las solicitudes, el sistema puede usar ahora determinadas señales de la respuesta de la aplicación para respaldar la detección y la aplicación de acciones.
Esto es especialmente relevante para posibles divulgaciones de información, en las que la propia respuesta puede contener indicios de lo que salió de la aplicación.
No elimina la necesidad de parchear el software vulnerable. Una regla de respuesta a veces puede impedir que se entregue información, pero no puede garantizar que todo exploit produzca una respuesta detectable ni detener daños ya consumados en el origen.
Dónde cambia esto las operaciones de seguridad
Para los equipos de seguridad de aplicaciones, la distinción práctica está entre impedir la ejecución, contener una respuesta e investigar el resultado.
Los controles en fase de solicitud pueden detener una operación sospechosa antes de que la aplicación la procese.
Los controles en fase de respuesta pueden impedir que una respuesta del origen que coincida llegue al cliente una vez realizado el procesamiento.
La correlación entre solicitud y respuesta puede aportar evidencia adicional para la investigación de incidentes y ayudar a quienes responden a distinguir los intentos de ataque de la actividad asociada a un impacto observable.
Estas capacidades se complementan, pero no cumplen la misma función de seguridad.
La detección de transacción completa de Cloudflare añade visibilidad sobre una parte del intercambio HTTP que la inspección solo de solicitudes no puede explicar. Sus reglas de respuesta crean un punto de control correspondiente antes de que determinado contenido del origen salga del borde (edge).
El cambio significativo es que un WAF puede usar ahora indicios de cómo respondió una aplicación, y no solo de lo que intentó el solicitante, para tomar determinadas decisiones de detección y contención. El límite que queda es igual de importante: una vez que el origen ha realizado una acción, bloquear su respuesta no puede deshacerla.
Para profundizar
- Cloudflare: Introducing full transaction detection for Cloudflare WAF, Daniele Molteni, Elie Roudninski y Nick Downie, 21 de octubre de 2026. Divulgación técnica y de producto primaria sobre la detección de transacción completa, las reglas de respuesta, los metadatos de firmas, la disponibilidad y los límites de la aplicación de las reglas.
- Cloudflare: Cloudflare deploys protections against php2shell vulnerability, Daniele Molteni, Dan Jones y Kuber Nandwani, 21 de octubre de 2026, actualizado el 23 de octubre de 2026. Contexto operativo de la respuesta a la vulnerabilidad de PHP que contribuyó al trabajo de Cloudflare en la detección sobre solicitud y respuesta.
- Cloudflare Developer Documentation: Attack Signature Detection. Documentación de referencia sobre la separación que hace Cloudflare entre la detección de ataques y la mitigación. Los nuevos campos de metadatos específicos de la respuesta se describen en el anuncio del 21 de octubre.
- Relacionado en este sitio: Vulnerabilidades críticas de PHP: a quién afectan, qué podría pasar y cómo parchear con seguridad (en inglés), sobre las vulnerabilidades y los requisitos de parcheo, a diferencia de la arquitectura del WAF que se examina aquí.
Revisión de fuentes: 26 de octubre de 2026. El comportamiento del producto, la disponibilidad por plan y la información sobre el despliegue proceden de la divulgación oficial de Cloudflare. Este artículo no afirma haber validado de forma independiente la eficacia del sistema de detección.