Falsos positivos y exclusiones acotadas

Una exclusión se describe siempre con cuatro datos: qué regla deja de aplicarse, sobre qué campo, en qué ruta y hasta cuándo. Quitar los cuatro límites a la vez es apagar una familia entera de reglas en toda la aplicación, que es lo que se escribe a las tres de la mañana y lo que nadie revisa después.

Hay además dos momentos distintos en los que se puede aplicar. Las que se resuelven al arrancar el motor se escriben como directivas y valen para todo el servidor: son baratas de ejecutar y torpes para acotar. Las que se evalúan en cada petición se escriben como una regla más y pueden mirar a qué ruta va la petición antes de decidir: cuestan un poco y son las que permiten dejar el resto del portal protegido.

La regla práctica: la exclusión más pequeña que resuelve la alerta. Un campo, una ruta, y una fecha en la que alguien vuelve a mirar si sigue haciendo falta.

Abre el laboratorio y lee exclusiones-vigentes.txt. Hay ocho exclusiones y tres de ellas se aplican a toda la aplicación. Una de esas tres no quita una regla: quita un rango de mil identificadores de golpe, el que cubre las reglas que buscan código de navegador en los valores. En las notas del equipo está la noche en que se escribió y la promesa de recortarla.

Ahora mide el daño del catálogo entero. Recorre la columna de alcance y cuenta las exclusiones que no están acotadas a una ruta concreta. Esas son las que dejan sin esa regla cualquier pantalla del portal, incluidas las que no tenían ningún problema.

No todas las alertas son ruido, y no todas las excepciones sobran. Lee alertas-revisadas.txt con rutas-y-campos.txt al lado: entre los siete falsos positivos hay uno que se repite tres veces, siempre en la misma pantalla interna de catálogo, y el inventario explica por qué: ese campo guarda texto con marcado legítimo —negritas, listas, enlaces— escrito por personal de la empresa. Ahí la excepción está justificada; lo que hay que revisar es su tamaño, no su existencia.