Cómo leer un informe de análisis de seguridad web

Tu primer análisis de seguridad puede parecer un volcado de diagnóstico: una puntuación destacada, un muro de hallazgos con colores y muchas siglas. La puntuación te dice *dónde estás*; los hallazgos te dicen *qué hacer a continuación*. Esta guía explica cómo leer un informe como lo haría un ingeniero de seguridad, desde el número principal hasta la única corrección que más importa esta semana.

Empieza por la puntuación, pero no te quedes ahí

IsSafeSite combina tres dimensiones en un solo número: Seguridad (60%), SEO (20%) y Protección de tráfico (20%). Un sitio puede tener buena nota general y ocultar aún un problema crítico, así que trata la puntuación como una línea de tendencia que observas con el tiempo, no como un aprobado/suspenso. Lo importante del análisis son los hallazgos que hay debajo.

Ordena por gravedad y luego por esfuerzo

Cada hallazgo lleva una gravedad. Trabájalos en este orden para que tu tiempo vaya donde el riesgo es mayor:

1. 1Crítico — explotable ahora o expone datos directamente. Corrígelo hoy.
2. 2Alto — una vía de ataque realista o un control ausente que debilita todo lo demás.
3. 3Medio — carencias de endurecimiento que importan combinadas con otro problema.
4. 4Bajo / Info — recomendaciones de buenas prácticas; agrúpalas en una limpieza.

Dentro de una misma gravedad, haz primero las correcciones baratas. Una cabecera Strict-Transport-Security ausente es un cambio de una línea con gran impacto; rediseñar el manejo de sesiones no lo es. Eliminar primero lo de bajo esfuerzo y alta gravedad es la forma más rápida de mover el número y acortar la lista.

Lee un hallazgo de principio a fin

Cada hallazgo está escrito para entenderse por sí solo. Uno bueno responde a cuatro preguntas:

• Qué se observó — la cabecera, ruta, campo del certificado o respuesta exactos que lo activaron.
• Por qué importa — el riesgo concreto, no una advertencia genérica.
• Cómo corregirlo — la directiva, el bloque de configuración o el cambio de código específicos.
• Cómo confirmarlo — cómo debería verse un nuevo análisis limpio.

Resiste la tentación de aplicar en masa correcciones de un resultado de búsqueda. Un valor de cabecera copiado de un sitio ajeno puede romper tu aplicación (una Content-Security-Policy demasiado estricta es el ejemplo clásico). Lee el «por qué» antes de aplicar el «cómo».

Separa los falsos positivos de las carencias reales

El análisis automatizado es coincidencia de patrones a escala, así que es normal algún falso positivo: una cabecera puesta en el CDN que el escáner no pudo ver, o una ruta «expuesta» que es pública a propósito. El análisis te da gravedad, confianza y evidencia precisamente para que puedas decidir. Compruébalo con tu propia configuración antes de descartar nada y, cuando lo descartes, anota por qué.

Convierte el informe en un plan corto

Cierra el informe con un plan, no con una lista de 40 tareas. Un ritmo semanal viable es este:

1. 1Corrige esta semana todo lo Crítico y cualquier Alto de una línea.
2. 2Programa el resto de Altos y Medios con responsables y fechas.
3. 3Vuelve a analizar tras cada tanda para ver moverse la puntuación y detectar regresiones.
4. 4Mantén una nota de excepciones para lo que aceptes conscientemente.

Los hallazgos de cabeceras y TLS que más encontrarás tienen su propio análisis a fondo: consulta Los 10 errores más comunes en cabeceras de seguridad y Configuraciones de SSL/TLS que ponen en riesgo tu sitio. Cuando quieras automatizar el reanálisis, la página de funciones y la documentación de la API muestran cómo integrarlo en CI.