Datahorses

Cabeceras de seguridad HTTP que toda web de empresa debería enviar

Por · · 4 min de lectura

Las cabeceras de seguridad HTTP son instrucciones que su servidor web envía con cada página. Le dicen al navegador cómo tratar su sitio: usar siempre HTTPS, no permitir que otros sitios metan sus páginas en un marco, no adivinar tipos de archivo y cargar scripts solo desde orígenes de confianza. No penalizan el rendimiento y se configuran una sola vez en el servidor o en la CDN.

La respuesta corta para la mayoría de webs de empresa: envíe Strict-Transport-Security, Content-Security-Policy (como mínimo con frame-ancestors), X-Content-Type-Options, Referrer-Policy y Permissions-Policy, configure las cookies con los atributos correctos y elimine las cabeceras que revelan versiones de software. Los valores recomendados que verá a continuación siguen la OWASP HTTP Headers Cheat Sheet y MDN.

La ausencia de cabeceras rara vez es una emergencia por sí sola. Es una señal del cuidado con el que está configurado un sitio, y además cierra el paso a categorías enteras de ataques en el lado del navegador.

Cómo comprobar sus cabeceras

Pida al servidor las cabeceras de su página de inicio:

curl -sI https://yourcompany.com/

Compruebe todos los nombres de host, no solo el principal: tienda, acceso de clientes, portal y cualquier servidor de pruebas olvidado que siga respondiendo. Las cabeceras definidas en la aplicación suelen desaparecer en páginas de error, redirecciones y archivos estáticos, así que pruebe varias URL distintas.

Las cabeceras que vale la pena enviar

Strict-Transport-Security (HSTS)

Indica al navegador que use únicamente HTTPS para su dominio durante un tiempo determinado, de modo que nadie pueda rebajar discretamente la conexión de un visitante a HTTP.

Strict-Transport-Security: max-age=63072000; includeSubDomains

max-age se expresa en segundos. Añada includeSubDomains solo cuando todos los subdominios funcionen por HTTPS. Para entrar en las listas de precarga de los navegadores, hstspreload.org exige un max-age de al menos 31536000 (1 año), includeSubDomains y preload. La precarga es difícil de revertir, así que déjela para el final.

Content-Security-Policy (CSP)

Enumera los orígenes desde los que la página puede cargar scripts, estilos, imágenes y marcos. Una buena política es la defensa más sólida del lado del navegador contra el cross-site scripting, pero debe ajustarse a su sitio. Empiece en modo de solo informe con Content-Security-Policy-Report-Only, observe qué se bloquearía y después aplíquela.

Incluso antes de tener una política completa, hay una directiva sencilla y útil:

Content-Security-Policy: frame-ancestors 'self'

frame-ancestors controla qué sitios pueden incrustar sus páginas, lo que bloquea el clickjacking. Debe enviarse como cabecera; no funciona en una etiqueta <meta>.

X-Frame-Options

Es la forma antigua de bloquear el enmarcado. OWASP recomienda frame-ancestors siempre que sea posible y X-Frame-Options: DENY (o SAMEORIGIN) como respaldo para navegadores antiguos.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Impide que el navegador adivine el tipo de un archivo, de modo que un archivo subido no pueda ejecutarse como script. Asegúrese de que las cabeceras Content-Type sean correctas en todo el sitio.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Limita qué parte de sus URL se transmite a otros sitios cuando los visitantes hacen clic en enlaces. Es importante cuando las URL contienen números de pedido, tokens o términos de búsqueda.

Permissions-Policy

Permissions-Policy: geolocation=(), camera=(), microphone=()

Desactiva funciones del navegador que su sitio no utiliza, para que un script inyectado no pueda solicitarlas.

Las cookies también necesitan atributos

Las cookies de sesión deben configurarse con Secure (solo HTTPS), HttpOnly (no legibles desde JavaScript) y SameSite=Lax o Strict:

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax; Path=/

Revise también el atributo Domain de la cookie. Una cookie con ámbito .yourcompany.com es legible desde cualquier subdominio, algo relevante si alguno de ellos llega a ser secuestrado a través de un registro DNS huérfano.

Cabeceras que conviene eliminar o dejar de usar

  • Server y X-Powered-By con números de versión, como Apache/2.4.41 o PHP/7.4.3. Le dicen a cualquiera exactamente qué software y qué versión buscar. OWASP recomienda eliminar X-Powered-By y hacer que Server no aporte información.
  • X-XSS-Protection. MDN la marca como obsoleta y no estándar y advierte de que puede crear problemas en sitios que, por lo demás, son seguros. OWASP recomienda no configurarla, o configurar X-XSS-Protection: 0, y confiar en la CSP.
  • Expect-CT. OWASP aconseja no utilizarla y eliminarla de las configuraciones existentes.

Dónde configurarlas

Configure las cabeceras en un único punto que cubra todas las respuestas: el servidor web (nginx add_header ... always;, Apache Header always set), la CDN o los ajustes de cabeceras de su plataforma de alojamiento. La palabra clave always en nginx es importante: sin ella, las cabeceras solo se añaden a respuestas correctas y redirecciones, no a las páginas de error.

Lista de comprobación breve

  • Ejecute curl -sI contra todos los nombres de host que tenga.
  • Añada HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy y frame-ancestors.
  • Despliegue una CSP completa primero en modo de solo informe.
  • Configure Secure, HttpOnly y SameSite en las cookies de sesión.
  • Elimine los números de versión de Server y X-Powered-By, y retire X-XSS-Protection y Expect-CT.
  • Vuelva a comprobarlo tras cada cambio de servidor, CDN o plataforma.

Ya que está en la configuración del servidor, asegúrese también de que no sirve archivos .env, .git o copias de seguridad expuestos.

Dónde encaja Datahorses

Datahorses vigila sus sitios web desde fuera todos los días y comprueba lo que reciben los navegadores y los atacantes: cabeceras de seguridad ausentes, cookies sin Secure, HttpOnly o SameSite, servidores que revelan sus versiones y contenido HTTP mixto en páginas HTTPS. No entramos en sus sistemas ni necesitamos ningún acceso, y cada hallazgo incluye el cambio de configuración exacto para su desarrollador. Consulte la lista completa de lo que vigilamos o solicite una propuesta.

Más artículos

Todos los artículos