Apuntes redes

No vayas a access.log, donde habitan los monstruos.

Cabeceras HTTP de Seguridad

Los navegadores modernos son mucho más que simples visualizadores de páginas: ejecutan scripts, gestionan cookies, interpretan metadatos y permiten interacciones cada vez más complejas. Por eso, los servidores web pueden (y deben) enviar cabeceras de seguridad que indiquen cómo debe comportarse el navegador al recibir una respuesta HTTP.

Estas cabeceras son instrucciones que ayudan a prevenir ataques como XSS (Cross-Site Scripting), Clickjacking, Inyección de código, Fuga de datos sensibles, y otros tantos que aprovechan comportamientos inseguros o ambiguos.

¿Qué hacen realmente?

No “protegen” tu sitio por sí solas. Lo que hacen es **limitar las capacidades del navegador y reforzar ciertas buenas prácticas**:

  • Prohíben cargar scripts desde dominios externos.
  • Bloquean la ejecución de contenido sospechoso.
  • Impiden incrustaciones maliciosas mediante <iframe>.
  • Obligan al navegador a usar siempre HTTPS.
  • Desactivan funciones peligrosas como el sniffing de tipos MIME.

En esencia, ayudan a aplicar una postura de “desconfianza activa” frente a todo lo que venga del exterior, algo esencial en la seguridad web moderna.

¿Cómo se configuran?

Estas cabeceras se definen desde el servidor web (Apache, Nginx, etc.), y en el caso de Apache, suelen declararse dentro del archivo .htaccess. Puedes añadirlas directamente con Header set ..., o dentro de un bloque IfModule para mayor compatibilidad.

NOTA: Aunque estas cabeceras no afectan el funcionamiento básico del servidor, sí pueden romper tu web si se aplican “sin más”, por ejemplo, bloqueando scripts legítimos, impidiendo que funcionen iframes de servicios externos (YouTube, mapas, etc.), o forzando HTTPS en sitios que aún no lo tienen bien configurado.

Por eso, antes de activarlas:

  • Prueba localmente o en un entorno de staging
  • Verifica que no interfieren con recursos externos
  • Usa herramientas como Mozilla Observatory o SecurityHeaders para comprobar compatibilidad

En las siguientes secciones verás las cabeceras más importantes, qué hacen, por qué se usan, y cómo aplicarlas. También se incluye la sintaxis para Apache .htaccess, que puedes adaptar fácilmente a tu proyecto.

1. X-Content-Type-Options: nosniff

¿Qué hace?

Evita que el navegador intente adivinar el tipo MIME de un recurso. Se asegura de que solo se use el tipo especificado en Content-Type.

¿Por qué es útil?

Previene ataques donde un archivo malicioso (como un script) se disfraza de imagen, PDF u otro tipo de contenido.

Ejemplo .htaccess

Header set X-Content-Type-Options "nosniff"

2. X-Frame-Options: DENY

¿Qué hace?

Prohíbe que tu página se cargue dentro de un <iframe>.

¿Por qué es útil?

Evita ataques de clickjacking, donde alguien inserta tu página en una web externa para engañar a los usuarios.

Alternativas

  • DENY - Nunca permitir iframes.

  • SAMEORIGIN - Solo permitir iframes desde tu propio dominio.

Ejemplo .htaccess

Header set X-Frame-Options "DENY"

3. Referrer-Policy: no-referrer-when-downgrade

¿Qué hace?

Controla si, y cuánta, información de referencia (la URL de origen) se envía al navegar a otra página.

¿Por qué es útil?

Limita la exposición de información sensible en URLs, especialmente cuando se navega de HTTPS a HTTP.

Significado de esta política

  • Se envía el Referer solo si el destino es HTTPS.

  • No se envía nada si se pasa de HTTPS a HTTP (downgrade).

Ejemplo .htaccess

Header set Referrer-Policy "no-referrer-when-downgrade"

4. Strict-Transport-Security (HSTS) ¿Qué hace?

Indica al navegador que siempre debe usar HTTPS al acceder a tu sitio, incluso si el usuario escribe http://.

Opciones explicadas

  • max-age=63072000 - Vigencia de la instrucción en segundos (2 años).

  • includeSubDomains - Aplica también a subdominios.

  • preload - Permite incluir tu sitio en la lista de precarga HSTS de los navegadores.

Advertencia

Asegúrate de que todo tu sitio y subdominios estén disponibles solo en HTTPS antes de activar esta cabecera con preload.

Ejemplo .htaccess

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

5. Permissions-Policy ¿Qué es?

Permissions-Policy (antes llamada Feature-Policy) es una cabecera HTTP que permite controlar qué APIs o funcionalidades del navegador están disponibles para tu sitio web o sus iframes.

¿Por qué es útil?

Aunque tu sitio no use funciones como cámara, micrófono o geolocalización, esta cabecera permite desactivar explícitamente estas capacidades, reduciendo la superficie de ataque y mejorando la seguridad y privacidad.

Ejemplo .htaccess

Header set Permissions-Policy "geolocation=(), camera=(), microphone=(), usb=(), payment=()"

Este ejemplo bloquea completamente el acceso a:

  • geolocalización

  • cámara

  • micrófono

  • dispositivos USB

  • API de pagos

Cómo funciona la sintaxis

  • "feature=()" significa que la función está deshabilitada para todos los orígenes.

  • Si quisieras permitirla solo para tu propio dominio, usarías "feature=('self')".

6. Content-Security-Policy (CSP) ¿Qué hace?

Controla desde qué orígenes se pueden cargar recursos como scripts, estilos, fuentes o imágenes. Es una defensa clave contra XSS (Cross-Site Scripting) y otros ataques de inyección de contenido.

¿Por qué es útil?

Evita que scripts maliciosos se ejecuten en tu página. Puedes restringir que solo se carguen recursos desde tu propio dominio o desde fuentes de confianza.

Ejemplo .htaccess

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self';"

Este ejemplo permite cargar scripts solo desde tu dominio y Google APIs, y estilos solo desde tu dominio.

Variantes comunes

  • 'none': bloquea completamente ese tipo de recurso.

  • 'self': permite cargar desde el mismo origen.

  • 'unsafe-inline': permite estilos o scripts dentro del HTML (evitar cuando sea posible).

  • 'unsafe-eval': permite usar eval() en JavaScript (altamente inseguro).

7. X-XSS-Protection

¿Qué hace?

Activaba el filtro anti-XSS en navegadores antiguos (como IE o versiones anteriores de Chrome).

¿Por qué es útil?

Aunque está obsoleta en navegadores modernos, aún se puede usar como medida extra en entornos antiguos.

Ejemplo .htaccess

Header set X-XSS-Protection "1; mode=block"

Esto indica al navegador que bloquee la carga de la página si detecta un intento de XSS.

Nota

La mayoría de navegadores actuales ignoran esta cabecera si ya se usa Content-Security-Policy, que es más robusta.

8. Cache-Control: no-store

¿Qué hace?

Evita que el navegador o cualquier proxy cacheen contenido sensible (como formularios, credenciales, o páginas privadas).

¿Por qué es útil?

Protege datos personales o sensibles frente a accesos posteriores a través del historial o la caché.

Ejemplo .htaccess

Header set Cache-Control "no-store"

configuración combinada para máxima protección

Puedes combinar las cabeceras recomendadas así:

<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
 Header set X-Frame-Options "DENY"
 Header set Referrer-Policy "no-referrer-when-downgrade"
 Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
 Header set Content-Security-Policy "default-src 'self'; script-src 'self'"
 Header set Permissions-Policy "geolocation=(), camera=(), microphone=(), usb=(), payment=()"
 Header set Cache-Control "no-store"
</IfModule>

Recomendación

Estas cabeceras no afectan el funcionamiento habitual del sitio, pero conviene probar su impacto en navegadores y servicios externos si usas recursos de terceros (como YouTube o Spotify).

Puedes comprobar los efectos con herramientas como:

¿Cómo se aplican en Apache?

En la mayoría de los casos, puedes añadir las cabeceras directamente en el archivo .htaccess sin necesidad de condiciones adicionales:

Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "DENY"
Header set Referrer-Policy "no-referrer-when-downgrade"
Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Sin embargo, si quieres asegurarte de que el módulo mod_headers esté presente (por ejemplo, para portabilidad o evitar errores si el módulo está desactivado), puedes envolver las instrucciones dentro de una directiva <IfModule>:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "DENY"
  Header set Referrer-Policy "no-referrer-when-downgrade"
  Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Ambos métodos son válidos. El segundo añade una capa de seguridad frente a entornos mal configurados o módulos deshabilitados.

Conclusión

Las cabeceras HTTP de seguridad son una herramienta esencial para proteger tu sitio web y sus usuarios. Aunque no son una solución mágica, su correcta implementación ayuda a mitigar muchos riesgos comunes en la web actual.

Recuerda siempre probar los cambios en un entorno seguro antes de aplicarlos en producción, y ajustar las configuraciones según las necesidades específicas de tu sitio.

TOP