Security Headers: qué son y cómo usarlos
Autor: Redacción Domeny.ForSale Publicado
En breve: los Security Headers son cabeceras de respuesta HTTP que indican al navegador cómo gestionar la página de forma segura. Ayudan a limitar, entre otras cosas, la ejecución de scripts no deseados, la inserción de la página en marcos de otros sitios y la divulgación de información al navegar entre sitios web. No sustituyen al código seguro ni a las actualizaciones, pero aportan una capa adicional de protección.
Cómo funcionan las cabeceras de seguridad
Cuando el navegador descarga una página, el servidor envía su contenido junto con metadatos, es decir, información que describe la respuesta. Las cabeceras HTTP forman parte de esos metadatos. No aparecen en el texto de la página, pero el navegador puede utilizarlas para restringir el uso de los recursos recibidos.
Las cabeceras de seguridad pueden exigir una conexión cifrada, indicar los orígenes permitidos para los scripts o prohibir que la página se inserte en un marco de otro sitio. Suelen definirse en la configuración del servidor, la aplicación, un proxy inverso o una CDN, la infraestructura que actúa como intermediaria en la distribución de contenidos.
Son medidas de protección que aplica principalmente el navegador. No impiden enviar peticiones directamente a la aplicación mediante otras herramientas, por lo que no sustituyen a la comprobación de permisos en el servidor.
Principales Security Headers y sus usos
No existe una configuración adecuada para todas las páginas. Las siguientes cabeceras abordan distintas amenazas y deben adaptarse al funcionamiento de cada sitio.
| Cabecera | Para qué sirve | Qué hay que tener en cuenta |
|---|---|---|
Content-Security-Policy | Define, entre otras cosas, los orígenes permitidos para scripts, estilos y otros recursos. | Una política demasiado restrictiva puede bloquear un formulario, los pagos o la analítica. |
Strict-Transport-Security | Obliga al navegador a utilizar HTTPS durante el periodo indicado. | Un periodo de vigencia largo y la inclusión de subdominios requieren preparar toda la infraestructura. |
X-Content-Type-Options | Con el valor nosniff, limita los intentos de deducir un tipo de recurso distinto del declarado por el servidor. | El servidor debe enviar un Content-Type correcto, por ejemplo, para los scripts y las hojas de estilo. |
Referrer-Policy | Controla qué información sobre la dirección de la página se transmite en la cabecera Referer. | La configuración debe tener en cuenta la privacidad y las necesidades de las integraciones. |
Permissions-Policy | Restringe el acceso a determinadas funciones del navegador, como la cámara o la geolocalización. | La compatibilidad con cada directiva depende del navegador. |
X-Frame-Options | Restringe la inserción de la página en marcos. | Es menos flexible que la directiva frame-ancestors de CSP. |
CSP, siglas de Content Security Policy, ayuda a limitar los efectos de XSS: ataques que ejecutan código no deseado en el contexto de la página. Una lista de dominios de confianza no garantiza por sí sola una protección completa: también importan las directivas concretas, la forma de cargar los scripts y evitar excepciones demasiado amplias.
La directiva frame-ancestors de CSP ofrece, entre otras medidas, protección frente al clickjacking, que consiste en engañar al usuario para que haga clic en un elemento de una página oculta dentro de otro sitio. Esta directiva puede prohibir por completo la inserción de la página o permitirla únicamente en los sitios indicados.
Ejemplo: una página con un formulario y servicios externos
Supongamos que una web corporativa utiliza un formulario de contacto, un mapa y una herramienta de analítica externa. Implantar una CSP que solo permita recursos del propio dominio puede dejar fuera de servicio el mapa y la analítica. Por eso, antes de aplicarla hay que identificar de dónde obtiene la página los scripts, estilos, imágenes y marcos, y a dónde envía las peticiones.
Si el sitio no debe insertarse en ningún marco, un fragmento de ejemplo de la política sería el siguiente:
Content-Security-Policy: frame-ancestors 'none'
Esto es únicamente una regla sobre la inserción en marcos, no una política CSP completa. No restringe los orígenes de los scripts ni las conexiones de red. Si la página ya tiene una CSP, hay que integrar esta regla con la configuración existente de forma deliberada, en lugar de añadir otra política sin comprobar sus efectos.
Para una página que no necesita la cámara ni el micrófono, se puede considerar lo siguiente:
Permissions-Policy: camera=(), microphone=()
Esta configuración no debe copiarse en una aplicación de videollamadas. Una buena cabecera restringe capacidades innecesarias, no funciones esenciales para el usuario.
Cómo comprobar e implantar las cabeceras de forma segura
Lo más sencillo es abrir las herramientas de desarrollo del navegador, ir a la pestaña de red, actualizar la página y seleccionar la petición del documento principal. En la sección de cabeceras de respuesta se puede comprobar qué ha recibido realmente el navegador. Que una cabecera figure en la configuración del servidor no significa que llegue al usuario.
Un orden práctico para implantarlas:
- Comprueba direcciones representativas: la página de inicio, el acceso a la cuenta, los formularios y las páginas de error. Las respuestas pueden pasar por distintas capas de la infraestructura.
- Determina dónde gestionas las cabeceras. La aplicación, el servidor y la CDN no deben sobrescribir ajustes por accidente ni añadir reglas contradictorias.
- Prepara la CSP en modo
Content-Security-Policy-Report-Only. Permite observar las infracciones sin bloquear recursos; la recopilación de informes requiere una configuración adicional. - Prueba las acciones clave del usuario, como iniciar sesión, enviar un formulario y realizar un pago, si existe esa opción.
- Activa la aplicación efectiva de la política y vigila los errores tras su implantación.
Implanta HSTS, el mecanismo que se activa mediante Strict-Transport-Security, solo cuando HTTPS funcione correctamente. El parámetro includeSubDomains también abarca los subdominios, así que antes de utilizarlo comprueba incluso los servicios menos evidentes. Confirma la sintaxis actual y la compatibilidad con las directivas en la documentación oficial de la plataforma utilizada y de los navegadores.
Lo que no revela el resultado de un escáner de seguridad
Un escáner puede detectar la ausencia de una cabecera o un valor arriesgado, pero su evaluación no demuestra que la aplicación sea segura. Algunas políticas solo son necesarias en determinados casos, y añadirlas para mejorar la puntuación puede romper integraciones.
Las cabeceras no corrigen permisos mal configurados, vulnerabilidades de la base de datos ni la exposición de secretos en el código. Empieza por comprobar las respuestas reales de tu sitio y elige un cambio cuyo funcionamiento puedas verificar antes de publicarlo.
Consulta también: ¿Qué es CSP?
Lee también
