En una auditoría de hacking ético, yo empiezo por lo que el navegador puede evaluar sin ambigüedades: cabeceras HTTP, políticas de carga y señales que reducen XSS, clickjacking y fugas de información. La herramienta Mozilla Observatory sirve precisamente para eso: revisar una web, puntuar su postura básica y señalar qué está mal configurado. Lo útil no es solo la nota, sino el mapa de correcciones que deja detrás.
Lo esencial en pocas líneas
- La versión actual vive en MDN y se centra en seguridad web visible desde el navegador.
- Evalúa controles como CSP, HSTS, cookies, CORS, SRI, Referrer-Policy y protección frente a clickjacking.
- La puntuación parte de 100, aplica penalizaciones y después bonificaciones si el sitio supera 90 puntos.
- Una A+ no significa que el sitio sea seguro; no cubre SQLi, software obsoleto ni fallos de lógica.
- En 2026 funciona bien como primera pasada, baseline y apoyo para priorizar remediaciones.
Por qué sigue siendo útil en una revisión ética
Hoy la versión operativa de esta herramienta vive en MDN, y eso la ha vuelto más clara para quien audita sitios con criterio técnico. Yo la uso como una fotografía rápida de la higiene de seguridad antes de entrar en pruebas más profundas. Si la superficie visible ya enseña grietas, normalmente hay trabajo de priorización antes de abrir otras vías de ataque.
En la práctica, me ayuda a medir madurez. Un sitio con buenas cabeceras no queda blindado, pero sí suele indicar que el equipo entiende los riesgos básicos y que existe una base decente sobre la que seguir trabajando. Esa primera lectura importa porque me dice si debo concentrarme en endurecer transporte y navegador, o si merece más atención la autenticación, la lógica de negocio y la exposición de datos.
MDN deja claro que una nota alta no autoriza a bajar la guardia, porque hay muchos vectores que la herramienta no ve. Yo prefiero leerla como un radar, no como un certificado. Y esa diferencia separa una comprobación superficial de una revisión útil de verdad.
Con ese marco, ya tiene sentido mirar qué revisa exactamente y qué huecos deja fuera.
Qué revisa de verdad y qué deja fuera
Lo que más valoro es que el informe no se queda en una puntuación abstracta: traduce la configuración de la web en controles concretos que impactan en ataques reales. En su versión actual, el observatorio se apoya en unas diez comprobaciones principales y prioriza defensas que afectan a carga de recursos, transporte, cookies y exposición entre orígenes.| Control | Qué mira | Por qué me importa |
|---|---|---|
| CSP | Desde dónde puede cargar recursos la página | Reduce el impacto de XSS y de terceros no deseados |
| HSTS y redirección a HTTPS | Si obliga a usar HTTPS desde el primer contacto | Evita degradaciones y ataques MiTM en el arranque |
| Cookies seguras | La configuración de las cookies de sesión | Limita robo de sesión y abuso por XSS o CSRF |
| CORS | Qué orígenes pueden leer recursos | Evita exposición innecesaria entre dominios |
| Referrer-Policy | Cuánta información sale en el encabezado Referer | Protege rutas y parámetros sensibles |
| SRI | Verificación de recursos externos | Detecta manipulación de CDN o dependencias |
| X-Content-Type-Options | Que el navegador no adivine tipos de archivo | Mitiga vectores de XSS basados en MIME sniffing |
| frame-ancestors / X-Frame-Options | Si otros sitios pueden incrustar la web en un iframe | Bloquea clickjacking |
| CORP | Acceso entre orígenes a ciertos recursos | Ayuda frente a ataques laterales y fugas de datos |
También ha dejado fuera pruebas antiguas que ya no encajan con las prácticas actuales, como `X-XSS-Protection` o los viejos controles de Flash y Silverlight. Eso no es un detalle menor: si una herramienta sigue midiendo cosas obsoletas, me obliga a desconfiar del resto del informe.
Lo que no revisa es igual de importante: versiones obsoletas, inyecciones SQL, plugins vulnerables, almacenamiento deficiente de contraseñas o fallos de lógica no entran en el radar. Si veo una A+, sigo tratando el sitio como potencialmente comprometible por vías que el observatorio no puede medir.
Con ese mapa ya se entiende por qué la nota importa menos que el detalle de cada control.
Cómo leer la nota sin obsesionarte con la letra
La puntuación parte de 100 y se aplica en dos rondas: primero se descuentan penalizaciones y, si el resultado queda en 90 o más, se añaden bonificaciones. El máximo actual es 145, así que una A+ no es un techo simbólico, sino una señal de que la web ha ido más allá de la base esperada.
| Rango | Letra | Lectura práctica |
|---|---|---|
| 100 o más | A+ | Base muy sólida, pero no equivale a cierre total |
| 90-99 | A | Bastante sólido, con ajustes finos todavía posibles |
| 85-89 | A- | Buen nivel, aunque falta completar alguna defensa |
| 70-84 | B+/B | Hay una base razonable, pero todavía faltan piezas importantes |
| 50-69 | C+/C | La web necesita hardening serio |
| 0-49 | D/F | Prioridad alta, porque faltan controles básicos |
El error más común es convertir la nota en objetivo final. Yo prefiero leerla como una lista ordenada de fricciones: si falla HSTS, primero corrijo transporte; si falla CSP, luego reviso carga de scripts; si fallan cookies, me centro en la sesión. Así la puntuación deja de ser marketing y se convierte en una cola de trabajo.
Con esa lectura clara, el siguiente paso es convertir el informe en cambios concretos.
Cómo pasar del informe a correcciones reales
Cuando el objetivo es remediar, no basta con mirar la letra. Yo sigo un ciclo corto: escanear, priorizar, corregir y volver a medir. Ese ritmo evita la trampa de tocar diez cosas a la vez sin saber cuál arregló de verdad el riesgo.
- Escaneo la web de producción o un staging que refleje producción. El historial de análisis es público, así que conviene usar dominios autorizados y saber que cualquier revisión quedará registrada.
- Leo los fallos por impacto y no por orden visual. HSTS, redirección segura, CSP y cookies suelen tener más peso práctico que controles cosméticos.
- Corrijo primero lo que afecta al navegador en todas las páginas. Un HSTS bien planteado o un `X-Content-Type-Options` correcto suelen dar más retorno que cambios muy específicos.
- Pruebo el sitio después de cada lote de cambios. La herramienta limita nuevos escaneos a una vez cada 60 segundos y, si enlazo un informe antiguo, puede relanzar un análisis si el dato tiene más de 24 horas.
- Documento la mejora. En una auditoría ética, lo importante no es solo cerrar el hueco, sino dejar trazabilidad de qué se cambió y por qué.
Si el sitio utiliza recursos externos, yo añado una comprobación manual de CDN, scripts de terceros y rutas embebidas. Esa es la zona donde SRI y CSP aportan valor real, porque muchas incidencias no nacen en el código propio sino en dependencias que se asumían confiables.
Cuando el informe ya se ha convertido en cambios, toca evitar los errores que más falsean el resultado.
Errores que convierten el observatorio en una falsa tranquilidad
La lista de fallos típicos es corta, pero se repite tanto que merece una sección propia. En casi todas las auditorías veo la misma combinación de malentendidos:
- Perseguir la A+ como si fuera una certificación. Una web puede sacar nota alta y seguir expuesta por SQLi, un login débil o una mala gestión de permisos.
- Aplicar cabeceras sin probar el funcionamiento real. Una CSP demasiado rígida puede romper módulos legítimos si no se despliega con cuidado.
- Usar la herramienta en APIs como si fueran sitios completos. Para endpoints de datos, la lectura es útil pero no perfecta; no describe toda la postura de seguridad de la API.
- Creer que todo se arregla con headers. Son una capa importante, no un sustituto de parches, revisión de dependencias y control de acceso.
- Ignorar el contexto del negocio. Un portal informativo y un panel de administración no tienen la misma tolerancia al riesgo.
Mi criterio es simple: si una recomendación mejora el navegador pero deja intacta la aplicación, todavía falta trabajo. Cuando una herramienta te ahorra tiempo, hay que exigirle precisamente eso, tiempo ganado para lo que solo se descubre con criterio humano.
Ese criterio se vuelve más sólido cuando la herramienta ocupa el lugar correcto dentro de una cadena de pruebas más amplia.
Dónde encaja frente a otras pruebas que sí necesito hacer
Si lo uso bien, este observatorio no compite con el resto de la caja de herramientas: la ordena. Me ayuda a separar lo que el navegador puede denunciar enseguida de lo que requiere ataque dinámico, revisión de código o análisis de infraestructura. Y si necesito detalle de TLS o certificados, recurro a otra capa: esta herramienta no sustituye ese tipo de análisis.
| Enfoque | Qué aporta | Cuándo lo prefiero |
|---|---|---|
| Observatorio HTTP | Baseline rápida de cabeceras y políticas | Al inicio de una auditoría o tras un despliegue |
| DAST como OWASP ZAP | Pruebas dinámicas más amplias | Cuando quiero buscar fallos de comportamiento, entradas y flujos |
| Revisión manual | Encuentra problemas de lógica y negocio | En autenticación, permisos, compras o formularios complejos |
| Revisión de dependencias y servidor | Detecta software obsoleto y exposición de infraestructura | Cuando la superficie técnica no depende solo del navegador |
Hay una frase que repito mucho en auditorías: si el observatorio te da la foto, las otras herramientas te dan la película. La foto sirve para decidir por dónde empezar; la película es la que confirma si la defensa resiste de verdad.
La lectura que yo haría antes de dar una web por endurecida
Para cerrar una revisión con criterio, yo me quedo con cuatro preguntas muy concretas: ¿la web fuerza HTTPS sin rodeos?, ¿la política de carga limita el daño de un XSS?, ¿las cookies y los orígenes están acotados?, ¿los recursos externos están controlados? Si la respuesta es sí, el sitio ha ganado una base seria. Si alguna respuesta es dudosa, todavía hay superficie atacable aunque la nota parezca bonita.
- Primero arreglo transporte y cabeceras estructurales.
- Después reviso dependencias, recursos de terceros y comportamiento del navegador.
- Luego paso a autenticación, permisos, lógica de negocio y datos sensibles.
- Si la web expone APIs, las trato como un caso aparte, no como un clon del frontend.
Eso es lo que hace valiosa esta herramienta en hacking ético: no sustituye el trabajo profundo, pero sí evita empezar a ciegas. Bien usada, convierte una auditoría difusa en una secuencia de decisiones técnicas que realmente mejoran la seguridad del sitio.
