Cómo interpretar un informe de seguridad de tu web
Qué significa cada parte del informe, qué diferencia hay entre lo observado y lo deducido, y qué hacer con el resultado sin entrar en pánico ni ignorarlo.
Por SiteGuardiaPublicado 4 min de lectura
Un informe de SiteGuardia no dice si tu web es segura. Dice cómo está configurada la parte que se ve desde fuera, en el momento en que se miró. Esa distinción es la que decide si el informe te sirve o te confunde, así que empieza por ahí.
Lo primero: qué es cada número
El informe tiene un índice general y cinco categorías. El índice general es un promedio ponderado de las categorías que se pudieron analizar, no una nota del negocio ni una probabilidad de que te ataquen.
Dos reglas del cálculo importan más que el número:
- Lo desconocido no resta. Si una categoría no se pudo comprobar, se excluye del promedio en lugar de puntuar cero. Un módulo que falló no es un suspenso.
- Un hallazgo confirmado grave pone techo. Un crítico confirmado limita el índice general a 59 y un alto confirmado a 79, por bueno que sea el resto. Una sola puerta abierta no se compensa con cinco cerradas.
Las ponderaciones exactas, las penalizaciones y los topes están publicados en la metodología. Si un número no te cuadra, ahí está la aritmética.
Lo segundo, y lo más importante: observación, inferencia y desconocido
Cada hallazgo lleva una etiqueta de cómo se llegó a él. No es un detalle de presentación: cambia lo que puedes concluir.
| Etiqueta | Qué significa | Qué puedes concluir |
|---|---|---|
| Observación confirmada | Se vio directamente en la respuesta | El hecho es cierto |
| Inferencia | Se deduce de lo observado | Es probable, conviene comprobarlo dentro |
| Basado en versión | Se dedujo de una versión anunciada | Es una hipótesis, no un fallo |
| No se pudo comprobar | El módulo no terminó o el objetivo no respondió | No sabemos nada de eso |
Un ejemplo del propio catálogo: cuando falta la cabecera Strict-Transport-Security, eso es una observación confirmada, porque la cabecera está o no está en la respuesta. En cambio, que una cookie sin Secure sea un riesgo de sesión es una inferencia: desde fuera se ve el atributo, no se ve si esa cookie transporta una sesión.
Una herramienta que presenta las tres cosas con la misma confianza es una herramienta que te hará perder tiempo en lo que no toca. Si un informe no distingue lo que vio de lo que supone, desconfía del informe antes que de tu web.
Lo tercero: qué no puede ver un análisis externo
Esto es una lista de límites, no una advertencia legal. Un análisis desde fuera, sin credenciales y sin tocar nada, no ve:
- Si tu gestor de contenidos tiene una vulnerabilidad sin parchear en el panel de administración.
- Si alguien tiene una contraseña que no debería tener.
- Si tu formulario de contacto es inyectable.
- Si hay una copia de seguridad accesible en una ruta que nadie enlaza.
- Si el servidor ya está comprometido.
Un resultado de 95 con esa lista sin revisar sigue siendo un resultado de 95 en lo que se midió. Por eso el informe no dice "tu web es segura" en ninguna parte.
Qué hacer, en orden
1. Ordena por severidad y filtra por confirmados. Empieza por lo que se vio, no por lo que se dedujo. 2. Lee el apartado de consecuencias de cada hallazgo, no solo el título. La gravedad depende de qué haya detrás: falta de X-Content-Type-Options en una web estática no es lo mismo que en una que sirve archivos que suben los usuarios. 3. Separa lo que puedes tocar tú de lo que no. Casi todo lo de cabeceras y TLS lo cambia quien administra el servidor o el CDN. Lo de correo lo cambia quien gestiona el DNS. 4. Envía una petición concreta. Abajo tienes el texto. 5. Vuelve a analizar después del cambio y compara. El informe caduca a las 48 horas, así que guarda el PDF si lo necesitas más adelante.
Texto que puedes enviar a quien administra tu web
Copia esto, cambia lo que esté entre corchetes y añade el PDF:
Hola. He pasado un análisis externo de configuración de seguridad sobre [dominio] y me han salido varios puntos en la parte de servidor. Te adjunto el informe. Me interesan sobre todo los marcados como confirmados. ¿Puedes revisar si se pueden aplicar y decirme cuáles no procede cambiar en nuestro caso y por qué? No busco que se corrija todo a ciegas; hay cosas que dependen de cómo esté montado el sitio y tú lo sabes mejor que el informe. Si algún cambio tiene riesgo de romper algo, prefiero saberlo antes.
Esa última frase importa. Activar HSTS con una duración larga en un sitio que todavía necesita HTTP para algo es la forma más habitual de convertir una recomendación en una incidencia.
Fuentes
- OWASP Secure Headers Project, referencia de las cabeceras que aparecen en el informe.
- RFC 6797, HTTP Strict Transport Security, la especificación de HSTS.
- MDN: Content Security Policy, para entender qué hace cada directiva.
Relacionado
- Comprobación general de seguridad web, que es la que produce este informe.
- Metodología, con el cálculo completo y sus límites.
- Informe de ejemplo, si quieres ver uno antes de analizar tu web.
Compruébalo en tu web
Esta guía explica la señal. La comprobación la lee en tu dominio y te dice qué encontró.