Cómo configurar cabeceras de seguridad HTTP

Q: ¿Puedo configurar las cabeceras de seguridad en un hosting compartido?

Depende del proveedor. La mayoría permite .htaccess en Apache, lo que es suficiente para las cabeceras básicas. CSP avanzada y la directiva preload de HSTS pueden requerir acceso al VirtualHost, que normalmente solo tienes en VPS o servidores dedicados.

Las cabeceras de seguridad HTTP son instrucciones que tu servidor envía al navegador para indicarle cómo debe comportarse al cargar tu sitio. Configurarlas correctamente te protege contra ataques como XSS, clickjacking e inyección de contenido — sin modificar una sola línea de tu código PHP o HTML.

En esta guía verás cuáles cabeceras importan, qué hace cada una y cómo añadirlas en Apache o Nginx en menos de treinta minutos.

¿Por qué importan las cabeceras de seguridad HTTP?

Un sitio puede tener SSL activo, contraseñas fuertes y plugins actualizados, y aun así ser vulnerable si el navegador no sabe con qué reglas debe cargar el contenido. Las cabeceras de seguridad llenan ese hueco:

Evitan que páginas externas incrusten tu sitio en un <iframe> (clickjacking).
Le ordenan al navegador que solo ejecute scripts de orígenes que tú apruebas (XSS).
Fuerzan conexiones HTTPS aunque el usuario escriba http://.
Impiden que el navegador "adivine" el tipo de archivo y ejecute código malicioso disfrazado de imagen.

Google los verifica cuando audita tu sitio con Lighthouse y herramientas como securityheaders.com te dan una calificación de A+ a F. Una F pública daña la confianza y el SEO.

Las seis cabeceras esenciales

1. Strict-Transport-Security (HSTS)

Fuerza HTTPS por un período definido. Una vez que el navegador la ve, nunca volverá a conectarse por HTTP durante ese tiempo, incluso si el usuario escribe la URL sin https://.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age=31536000 son 12 meses. Empieza con un valor más corto (86400 = 1 día) mientras pruebas, y auméntalo cuando todo funcione. Lee más sobre HSTS en nuestra guía de seguridad SSL.

2. Content-Security-Policy (CSP)

Define de dónde puede cargar recursos el navegador: scripts, estilos, imágenes, fuentes. Es la defensa más poderosa contra XSS.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.tudominio.com; img-src 'self' data:

CSP requiere inventariar tus recursos antes de activarla. Usa primero Content-Security-Policy-Report-Only para detectar bloqueos sin romper nada.

3. X-Frame-Options

Impide que tu sitio se cargue dentro de un <iframe> en otro dominio, bloqueando ataques de clickjacking.

X-Frame-Options: SAMEORIGIN

Si no necesitas iframes de dominios externos, usa DENY para una protección total.

4. X-Content-Type-Options

Evita el "MIME sniffing": el navegador no intentará adivinar el tipo de archivo y ejecutar contenido que no sea lo que tu servidor declaró.

X-Content-Type-Options: nosniff

5. Referrer-Policy

Controla qué información de la URL de origen se envía cuando el usuario sigue un enlace hacia otro sitio. Protege rutas internas y parámetros sensibles.

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

6. Permissions-Policy

Reemplaza a Feature-Policy. Permite desactivar acceso a APIs del navegador (cámara, micrófono, geolocalización) que tu sitio no necesita.

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

Cómo añadirlas en Apache

Edita tu archivo .htaccess o la configuración del VirtualHost (/etc/httpd/conf.d/tudominio.conf):

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy "default-src 'self';"
</IfModule>

Activa el módulo si no lo está:

a2enmod headers   # Debian/Ubuntu
# En CentOS/AlmaLinux ya viene activo con mod_headers

Recarga Apache para aplicar los cambios:

systemctl reload httpd   # o apache2 en Ubuntu

Cómo añadirlas en Nginx

En el bloque server de tu archivo de configuración (/etc/nginx/sites-available/tudominio):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self';" always;

Verifica la sintaxis y recarga:

nginx -t && systemctl reload nginx

La palabra clave always es importante en Nginx: garantiza que las cabeceras se envíen incluso en respuestas de error (4xx, 5xx).

Verificar que las cabeceras están activas

Una vez aplicados los cambios, verifica con:

curl: curl -I https://tudominio.com — muestra los encabezados en la terminal.
securityheaders.com — calificación visual de A+ a F con descripción de cada cabecera.
Google Lighthouse — auditoría integrada en Chrome DevTools, pestaña "Best Practices".

Apunta a una calificación A o A+. Si ves advertencias de CSP, usa el modo report-only para ajustar antes de bloquear.

Si tienes un hosting compartido y no puedes editar la configuración del servidor, los profesionales de elenlace.com pueden aplicar estas cabeceras dentro de los límites de tu plan o migrar tu sitio a un entorno con acceso completo.

Conclusiones clave

Las cabeceras de seguridad HTTP son la primera línea de defensa a nivel navegador — independientes de tu CMS o lenguaje.
HSTS fuerza HTTPS; CSP bloquea XSS; X-Frame-Options frena clickjacking; nosniff evita MIME sniffing.
En Apache se configuran con mod_headers en .htaccess o VirtualHost; en Nginx con directivas add_header.
Prueba siempre CSP en modo report-only antes de activarla en producción.
Verifica con securityheaders.com o curl -I que los encabezados lleguen al navegador.

¿Tu servidor no permite editar la configuración directamente? En elenlace.com te ofrecemos planes de hosting y gestión técnica donde configuramos estas cabeceras por ti y auditamos tu sitio completo.

Preguntas frecuentes

¿Puedo configurar las cabeceras de seguridad en un hosting compartido?

Depende del proveedor. La mayoría permite .htaccess en Apache, lo que es suficiente para las cabeceras básicas. CSP avanzada y la directiva preload de HSTS pueden requerir acceso al VirtualHost, que normalmente solo tienes en VPS o servidores dedicados.

¿Las cabeceras de seguridad afectan la velocidad de mi sitio?

No de forma apreciable. Son líneas de texto añadidas a la respuesta HTTP — su tamaño es de décimas de kilobyte. El único impacto posible es una CSP muy estricta que bloquee recursos externos que el sitio intente cargar, lo que no es un problema de velocidad sino de configuración.

¿Qué pasa si activo HSTS con preload y luego necesito volver a HTTP?

Es muy difícil. Una vez que el dominio entra en la lista de preload de navegadores, los usuarios no podrán acceder por HTTP durante el max-age aunque elimines la cabecera. Por eso se recomienda empezar con un max-age corto (86400) y sin preload, y aumentarlo sólo cuando estés seguro de que HTTPS es permanente.

¿CSP funciona con WordPress?

Sí, pero requiere trabajo extra. WordPress, sus plugins y temas cargan scripts, estilos e imágenes de múltiples orígenes. Debes construir la política usando report-only primero, recopilar los reportes de violaciones y luego construir una política que permita todo lo legítimo. Hay plugins como CSP with Google Analytics que facilitan el proceso.

Compara proveedores

Otros proveedores y guías que vale la pena comparar: