Modelo negativo y modelo positivo

El modelo negativo mantiene una lista de lo que se sabe malo, las firmas, y bloquea lo que coincide con ellas. Es lo que traen casi todos los conjuntos de reglas gestionadas: se instala rápido y cubre mucho sin conocer la aplicación. Su límite es que solo detiene lo que alguien ya describió, y que una firma demasiado amplia coge peticiones legítimas.

El modelo positivo parte de lo contrario: define lo que cada endpoint espera (parámetros, tipos, largos, valores) y rechaza todo lo demás. Es mucho más estricto y no depende de que un ataque sea conocido; su coste es que hay que describir la aplicación y mantener esa descripción al día cuando la aplicación cambia.

Consulta contrato_api para ver qué espera cada parámetro y muestras para ver qué haría cada modelo con cada petición descrita. Hay peticiones que no se parecen a ningún ataque conocido y aun así no pertenecen a la API: un valor que no está en la lista permitida, un texto donde va un número. El modelo negativo las deja pasar porque no coinciden con ninguna firma; el positivo las rechaza porque no cuadran con el contrato.

Para medir el valor del contrato, cuenta las muestras que el modelo negativo deja pasar y el positivo bloquea. Son el terreno que solo cubre el segundo.

El modelo positivo se queda corto con los campos de texto libre: si el contrato dice «texto libre, hasta 60 caracteres», casi cualquier contenido cumple. En esos campos el que trabaja es el modelo negativo, que mira el contenido. Revisa en muestras cuál es la que el modelo negativo detiene y el positivo deja pasar en la búsqueda de clientes.

En la práctica se combinan. Donde la aplicación tiene estructura (números, listas, largos), un contrato estricto da una protección muy buena y barata de mantener. Donde hay texto libre, firmas sobre el contenido. Y en ambos casos la aplicación debe validar y tratar los datos de forma segura por su cuenta: el WAF es una red de seguridad, no el único control.