Cabeceras de seguridad HTTP que toda web de empresa debería enviar
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
ServeryX-Powered-Bycon números de versión, comoApache/2.4.41oPHP/7.4.3. Le dicen a cualquiera exactamente qué software y qué versión buscar. OWASP recomienda eliminarX-Powered-Byy hacer queServerno 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 configurarX-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 -sIcontra todos los nombres de host que tenga. - Añada HSTS,
X-Content-Type-Options,Referrer-Policy,Permissions-Policyyframe-ancestors. - Despliegue una CSP completa primero en modo de solo informe.
- Configure
Secure,HttpOnlyySameSiteen las cookies de sesión. - Elimine los números de versión de
ServeryX-Powered-By, y retireX-XSS-ProtectionyExpect-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
Requisitos de Gmail y Yahoo para remitentes: qué cambió en 2024 y qué revisar
Desde febrero de 2024, Gmail y Yahoo esperan de los envíos masivos correo autenticado y alineado y bajas sencillas. Esto dicen las reglas y así puede revisar su propio dominio.
Caducidad de certificados SSL/TLS: por qué sigue tumbando sitios web
Un certificado caducado bloquea a los visitantes con un aviso del navegador a pantalla completa y puede romper APIs y correo. Las vigencias se acortan, así que la renovación debe funcionar siempre.
PHP2Shell: qué versiones de PHP están corregidas y cómo comprobar la suya
El proyecto PHP corrigió 2 fallos críticos el 21 de octubre de 2026. Le explicamos qué versiones incluyen el parche, qué indica su servidor y qué preguntar a su proveedor de hosting.