Cabeceras de seguridad HTTP: qué revisar y cómo pedir la corrección

Una cabecera de seguridad es una instrucción que tu servidor le da al navegador sobre cómo tratar tus páginas. El navegador obedece; sin la instrucción, aplica su comportamiento por defecto, que es más permisivo en unos casos y razonable en otros.

Esa última parte se dice poco y cambia las prioridades: no todas las cabeceras ausentes son un problema del mismo tamaño, porque los navegadores actuales ya traen valores por defecto sensatos para algunas de ellas.

Las que cambian algo de verdad

Content-Security-Policy

La que más protege y la más fácil de configurar mal. Le dice al navegador de dónde puede cargar scripts, estilos, imágenes y marcos. Bien puesta, convierte una inyección de código en nada.

Dos detalles que separan una política real de una decorativa:

• 'unsafe-inline' en script-src desactiva buena parte de la protección, porque vuelve a permitir el código escrito directamente en la página, que es justo lo que inyecta un atacante.
• Una política sin default-src ni una directiva concreta para un tipo de recurso no restringe ese tipo en absoluto. Es el caso más común de política que parece hacer algo y no hace nada.

Por eso el informe distingue cuatro situaciones distintas dentro de CSP -comodín, unsafe-inline, unsafe-eval y ausencia de reserva- en lugar de decir "CSP débil" para todas. Si te dicen que tu política permite código en línea, deberías poder encontrar unsafe-inline en ella; si no está, el informe se equivocó.

Strict-Transport-Security

Le dice al navegador que insista en HTTPS durante un tiempo. Sin ella, la primera visita del día puede empezar en HTTP antes de que actúe la redirección, y ese primer salto es interceptable.

Cuidado con esta. max-age largo más includeSubDomains es una decisión difícil de revertir: los navegadores que ya la recibieron la respetarán hasta que caduque, aunque quites la cabecera. Si algún subdominio todavía no tiene certificado, lo dejarás inaccesible. Se empieza con un valor corto.

X-Content-Type-Options: nosniff

Impide que el navegador adivine el tipo de un archivo ignorando lo que dice el servidor. Importa sobre todo si tu sitio sirve archivos que suben terceros. Una línea, sin efectos secundarios.

Cabeceras de marco

frame-ancestors dentro de CSP dice quién puede meter tu página en un iframe. Evita que alguien superponga su interfaz sobre la tuya para que tus usuarios pulsen donde no creen. X-Frame-Options es la versión antigua de lo mismo: mantenla si tienes visitantes con navegadores viejos, pero la que gobierna hoy es frame-ancestors.

Las que importan menos de lo que suele decirse

Referrer-Policy. Se repite que sin ella la dirección completa de tu página viaja a terceros. Eso era cierto hace años. Los navegadores actuales aplican por defecto strict-origin-when-cross-origin, que ya recorta la ruta al salir de tu sitio. Ponerla sigue siendo buena idea porque hace explícito el comportamiento y no depende del navegador, pero no es una fuga abierta.

Permissions-Policy. Restringe cámara, micrófono, geolocalización y similares. Si tu web no usa ninguna, la cabecera no cambia nada hoy; sirve para que no cambie nada mañana si se inyecta algo.

Un ejemplo

Una respuesta de una web pequeña, tal como se ve desde fuera. Es un ejemplo sintético, no un cliente:

Lo que hay que atacar aquí son las dos primeras filas, en ese orden. Las dos últimas son mejoras, no incidencias.

Texto que puedes enviar a quien administra el servidor

Hola. En [dominio] faltan dos cabeceras de seguridad y una tercera está permisiva. ¿Puedes revisarlo? 1. Strict-Transport-Security. Empecemos con max-age=86400 sin includeSubDomains para comprobar que nada se rompe, y lo subimos a un año cuando esté claro. Antes de añadir includeSubDomains, confirma que todos los subdominios tienen certificado. 2. X-Content-Type-Options: nosniff. No debería tener efectos secundarios. 3. La Content-Security-Policy actual lleva 'unsafe-inline' en script-src. Sé que quitarlo puede requerir mover scripts en línea a archivos o usar nonces, así que dime qué trabajo supone antes de tocarlo. Si alguna no procede en nuestro montaje, prefiero saber por qué a que se aplique igual.

Límites de esta comprobación

Se lee lo que devuelve tu servidor en una petición desde fuera. Eso significa que:

• Solo se ven las cabeceras de las páginas que se piden, no las de toda la web.
• Una cabecera correcta en la portada puede faltar en una sección servida por otro sistema.
• No se comprueba si la política de CSP realmente bloquea algo en tu página, solo qué dice.

Fuentes

• OWASP Secure Headers Project
• RFC 6797, HTTP Strict Transport Security
• MDN: Content-Security-Policy
• MDN: Referrer-Policy, donde está documentado el valor por defecto actual.

Relacionado

• Comprobador de cabeceras de seguridad
• Cómo interpretar un informe
• Metodología