Leer y depurar un informe de ZAP

Cada fila del resumen es una regla que saltó; sus instancias son los sitios donde saltó. Una cabecera que falta en 64 páginas es una alerta con 64 instancias, y casi siempre es una sola causa: la capa que debía ponerla en todas las respuestas no lo hace. Contar instancias como hallazgos asusta sin motivo; agruparlas por causa dice cuánto trabajo hay de verdad y dónde se hace.

El riesgo de la regla dice cuánto dolería si fuera real; la confianza dice cuán seguro está el escáner de que lo es. La confianza la puede cambiar una persona después de revisar: el escáner nunca marca algo como confirmado ni como falso positivo por su cuenta.

Abre el laboratorio y lee informe-escaner.txt y notas-proxy.txt. Operaciones dice qué cabeceras le tocan al proxy inverso y que hoy su plantilla no pone ninguna.

Las reglas pasivas buscan patrones en el texto de la respuesta. Si una página explica qué hacer cuando el navegador muestra un error, el patrón está ahí, aunque la aplicación no haya fallado. Por eso cada instancia se mira en su contexto: qué página es, qué texto saltó y si ese texto es un error real o una explicación.

Lee detalle-instancias.txt.

Un filtro de alertas cambia el riesgo de una alerta en cuanto aparece, o la marca como falso positivo. Bien usado, quita ruido ya revisado de cada corrida. Mal usado, esconde para siempre una regla en toda la aplicación, incluidas las instancias nuevas que nadie ha revisado. Un filtro sano está acotado a la dirección (y si se puede al parámetro) que se revisó, dice por qué y tiene fecha para volver a mirarlo.

Lee filtros-alertas.txt con eso en mente.

El filtro problemático se reescribe, no se borra sin más: el equipo del portal revisó algo en septiembre y esa revisión vale para lo que revisó. La pregunta es cómo escribirlo para que no tape lo que vendrá.