Encabezados de seguridad HTTP: Guía

La seguridad en los servidores ya no es algo que puedas dejar para «más tarde». Configurar encabezados de seguridad HTTP es una de las formas más eficientes —y relativamente sencillas— de blindar tu sitio contra ataques habituales como Cross-Site Scripting (XSS), clickjacking y ciertos tipos de inyección de código. Piensa en estas directivas como una capa de defensa que le habla al navegador: le dice exactamente cómo comportarse al cargar tu contenido.

Da igual si gestionas un servidor Nginx o uno Apache; la lógica de fondo es la misma, aunque cambie la sintaxis. Vamos a repasar los encabezados críticos, qué hacen y cómo ponerlos en marcha en tu entorno de producción.

Los encabezados que no pueden faltar

Antes de tocar nada de configuración, conviene saber qué estamos activando. No todos los headers son iguales, y algunos pueden romper partes de tu sitio si no se ajustan con cuidado. Aquí tenemos el «cuarteto fantástico» que cualquier sitio moderno debería llevar.

X-Content-Type-Options: nosniff

Este encabezado evita que el navegador intente adivinar el tipo de archivo (MIME type) si no se declara explícitamente. Esta función, el MIME sniffing, es útil en algunos casos, pero los atacantes la explotan para ejecutar scripts maliciosos disfrazados de imágenes o archivos inofensivos. Al activar esto, obligas al navegador a respetar el tipo de contenido que tú declaras.

X-Frame-Options: DENY o SAMEORIGIN

Protegerse del clickjacking es fundamental. Este header controla si tu sitio puede ser incrustado dentro de un frame o un iframe. Usar DENY prohíbe cualquier intento de inclusión. SAMEORIGIN es más flexible: permite que tu propio sitio se iframe a sí mismo, pero bloquea los intentos externos. Para la mayoría de los gestores de contenido, SAMEORIGIN es el punto medio ideal entre seguridad y funcionalidad.

Strict-Transport-Security (HSTS)

HSTS fuerza a los navegadores a hablar con tu servidor solo a través de HTTPS. Incluso si el usuario escribe «http://» en la barra, el navegador hará la actualización automática. Esto evita ataques de degradación de protocolo. Ten cuidado al implementarlo por primera vez; asegúrate de que tu certificado SSL funcione sin fisuras y usa un tiempo de cache (max-age) corto al principio. No querrás bloquearte a ti mismo por un error de configuración.

Content-Security-Policy (CSP)

Este es el más potente y, a la vez, el más complicado. La CSP define qué fuentes de contenido (scripts, estilos, imágenes, fuentes) son legítimas en tu sitio. Si un atacante logra inyectar un script desde un dominio no autorizado, el browser lo bloqueará al instante. Configurar la CSP requiere paciencia: tienes que permitir explícitamente los dominios de tus analytics, fuentes externas y CDNs uno a uno.

Configuración en Apache

Apache utiliza el módulo mod_headers para estas directivas. Asegúrate de que el módulo esté activado ejecutando a2enmod headers en sistemas Debian/Ubuntu antes de tocar nada más.

Lo ideal es poner la configuración directamente en el archivo principal o en uno específico dentro de /etc/apache2/conf-available/. Así te aseguras de que los encabezados se apliquen a todos los hosts virtuales que alojes en ese servidor.

<IfModule mod_headers.c>
  # Protección contra XSS y MIME Sniffing
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  
  # Habilitar HSTS por 6 meses (en segundos)
  Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
  
  # Política de Seguridad de Contenido básica (ajustar según necesidades)
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google-analytics.com; object-src 'none'"
  
  # Opcional: Referrer Policy
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Hecho esto, recarga la configuración de Apache sin cortar las conexiones activas. Usa systemctl reload apache2 o service httpd graceful.

El caso .htaccess

Si no tienes acceso al servidor principal y debes usar .htaccess, el código es el mismo. Ten en cuenta, no obstante, que esto afecta un poco al rendimiento, ya que el archivo se lee en cada petición. Asegúrate también de que AllowOverride permita el uso de Header en tu host virtual.

Configuración en Nginx

En Nginx la cosa es más directa y, en general, más eficiente. La directiva add_header suele ir dentro del bloque server (para tu sitio) o location (para rutas específicas). Yo recomiendo poner los encabezados de seguridad en el bloque server de tu archivo en /etc/nginx/sites-available/.

server {
    listen 443 ssl http2;
    server_name tu-dominio.com;
    
    # ... configuración SSL ...

    # Encabezados de Seguridad
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    
    # HSTS: Solo activar si el SSL está correctamente configurado
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    
    # CSP: Permitir solo recursos propios y Google Fonts
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; object-src 'none';" always;
    
    # Protección de Referer
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    
    # Resto de la configuración del bloque location...
}

Fíjate en el parámetro always al final de cada línea. Es crucial. Garantiza que los encabezados se envíen incluso si hay errores (como un 404 o 500). Es un detalle pequeño que a veces se pasa por alto, pero que mantiene la seguridad coherente.

Validando la sintaxis

Nginx es estricto. No recargará si hay errores de sintaxis. Antes de reiniciar el servicio, ejecuta siempre nginx -t. Si la prueba es limpia, aplica los cambios con systemctl reload nginx. Recuerda: recargar es mejor que reiniciar para evitar tiempos de inactividad (downtime).

Verificación y problemas

No asumas que funciona nada hasta que lo compruebes. La verificación es clave. Usa herramientas como Security Headers (securityheaders.com) o la pestaña «Network» en las herramientas de desarrollador de tu navegador para inspeccionar las respuestas.

Problemas con CSP

Es muy probable que, al activar una CSP estricta, algo deje de funcionar. Verás errores en la consola del navegador indicando que un script o fuente ha sido bloqueado. La solución es identificar el dominio culpable y agregarlo a la directiva correspondiente. Por ejemplo, si usas Font Awesome, tendrás que añadir font-src 'self' use.fontawesome.com;.

Precaución con HSTS

Si pones un max-age muy alto en HSTS y luego pierdes tu certificado SSL, los usuarios no podrán entrar a tu sitio ni manualmente. El navegador se negará a conectarse por HTTP. Para probar, empieza con un valor bajo (unos 300 segundos) y, tras verificar que todo es estable durante días, sube el valor a 31536000 (un año).

Conclusión

Implementar encabezados de seguridad HTTP no es algo de «configurar y olvidar». Es un proceso continuo de ajuste y verificación. Aun así, el retorno de inversión en seguridad es enorme. Con pocas líneas en Nginx o Apache, cierras puertas importantes a actores maliciosos y proteges los datos de tus usuarios. Si en algún punto la configuración se te va de las manos o compromete la estabilidad de tus servicios, en RedServicio (redservicio.net) estamos listos para ayudar a gestionar y asegurar tu infraestructura web.