Headers HTTP de Seguridad en WordPress: CSP, HSTS y X-Frame-Options (Guia 2026)
Los headers HTTP de seguridad son una capa invisible pero critica. Esta guia explica como configurarlos en .htaccess, nginx y plugins de WordPress sin romper tu sitio.
Headers HTTP de Seguridad en WordPress: CSP, HSTS y X-Frame-Options (Guia 2026)
Cuando pensamos en seguridad para WordPress, lo primero que viene a la mente es un certificado SSL, un buen plugin de contrasenas o quizas actualizar los plugins. Y eso esta bien: son capas necesarias. Pero hay una capa de seguridad igual de critica que casi nadie configura: los headers HTTP de respuesta.
Los headers de seguridad le dicen al navegador del visitante como debe comportarse al cargar tu sitio. Sin ellos, el navegador asume que todo es confiable por defecto, y eso deja la puerta abierta a ataques como inyeccion de scripts (XSS), clickjacking, y robo de informacion de referencia. En Chile, donde cada vez mas pymes usan WordPress para vender online, estos ataques son mas comunes de lo que parece.
Imagina que un atacante inyecta un script malicioso en tu sitio. Sin CSP (Content-Security-Policy), el navegador ejecutara ese script sin preguntas. Sin HSTS, un usuario podria acceder a tu sitio por HTTP — y ahi el certificado SSL no sirve de nada. Sin X-Frame-Options, alguien puede embeber tu sitio en un iframe falso para enganar a tus clientes.
Configurar estos headers no requiere ser experto en seguridad. En esta guia vas a encontrar ejemplos listos para copiar y pegar en .htaccess o nginx.conf, sin rodeos. Si tu sitio esta en Elevocloud, ya tienes una base solida con HTTPS, pero los headers de seguridad son el siguiente paso que marca la diferencia entre un sitio "seguro" y un sitio realmente endurecido.
Que Son los Headers HTTP de Seguridad y Como Funcionan
Cada vez que tu navegador solicita una pagina web, el servidor responde con dos cosas: el contenido (HTML, imagenes, scripts) y un conjunto de metadatos llamados headers HTTP. Estos headers viajan antes del contenido y le indican al navegador como debe procesar lo que viene despues.
Los headers de seguridad son un subconjunto especifico que instruye al navegador sobre politicas de proteccion. No cifran datos ni filtran trafico — esa es labor del SSL o de un WAF. Lo que hacen es definir reglas de comportamiento: que scripts se pueden ejecutar, si el sitio puede ser embebido en un iframe, si el navegador debe forzar HTTPS, y mas.
Funcionan en una logica de "defensa en profundidad". Si un atacante logra inyectar codigo malicioso, CSP puede bloquear su ejecucion. Si alguien intenta acceder por HTTP, HSTS redirige automaticamente a HTTPS. Si un sitio maligno intenta enmarcar el tuyo, X-Frame-Options lo impide. Son capas que se complementan.
El punto clave es que estos headers se configuran del lado del servidor, no del cliente. Eso significa que, una vez implementados, protegen a todos los visitantes sin necesidad de que ellos hagan nada. Para un sitio WordPress en Chile, agregar estos headers es una de las decisiones de seguridad con mejor relacion costo/beneficio: no requiere plugins pagados ni cambios en el codigo del tema, y el impacto es inmediato.
Los headers de seguridad mas importantes para WordPress son seis: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. Los veremos en detalle a continuacion.
Los 6 Headers de Seguridad que Todo WordPress Debe Tener
Estos son los seis headers que necesitas implementar en tu WordPress. Cada uno cumple una funcion especifica de proteccion. Los configuramos en orden de complejidad.
Content-Security-Policy (CSP): Controla que Scripts Pueden Ejecutarse
Content-Security-Policy es el header mas potente y el mas complejo de configurar. Su funcion es definir una lista blanca de origines permitidos para cada tipo de recurso: scripts, estilos, imagenes, fuentes, frames, conexiones y mas. Si algo no esta en la lista, el navegador lo bloquea.
La directiva mas importante es default-src 'self', que establece la regla base: solo se permiten recursos del mismo dominio. A partir de ahi, agregas excepciones segun lo que tu sitio necesite.
Para un WordPress tipico que usa Google Fonts, Google Analytics y quizas un chat en vivo, una politica CSP funcional se ve asi:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com; frame-src 'self';
Notaras que 'unsafe-inline' aparece en script-src y style-src. Es un compromiso: WordPress y sus plugins generan mucho CSS y JS inline, y bloquearlos por completo rompe la interfaz de administracion. La meta es reducir 'unsafe-inline' en la medida de lo posible usando nonces o hashes.
Para capturar los intentos de violacion de CSP sin romper el sitio, usa report-uri o report-to. En WordPress, puedes crear un endpoint con un plugin minimo o apuntar a un servicio como report-uri.com. Los reports te muestran exactamente que recursos estan siendo bloqueados para que ajustes la politica sin ensayo y error a ciegas.
Consejo practico: Implementa CSP primero en modo Content-Security-Policy-Report-Only. Esto reporta violaciones sin bloquear nada. Una vez que verify que no hay falsos positivos, cambia a Content-Security-Policy.
HTTP Strict Transport Security (HSTS): Fuerza HTTPS
HSTS le dice al navegador que tu sitio solo debe ser accedido via HTTPS, y que cualquier intento de acceder por HTTP debe ser convertido automaticamente antes de la conexion. Esto elimina el ataque de "SSL stripping", donde un intermediario intercepta la solicitud HTTP y redirige al usuario a una version insegura sin que este se de cuenta.
La configuracion basica es:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Desglosemos cada directiva:
- max-age=31536000: Tiempo en segundos que el navegador recordara la politica. Un ano (31.536.000 segundos) es el estandar recomendado.
- includeSubDomains: Extiende la politica a todos los subdominios. Si tienes un subdominio que aun no usa HTTPS, no agregues esta directiva hasta que todos esten en HTTPS.
- preload: Permite que tu dominio sea incluido en la lista de preload de navegadores. Una vez en la lista, el navegador forzara HTTPS incluso en la primera visita. La inclusion en la preload list es dificil de revertir, asi que asegurate de que todos tus subdominios funcionen correctamente con HTTPS antes de solicitarla.
Para dominios .cl, HSTS funciona exactamente igual que para cualquier otro dominio. La unica consideracion especial es que el proceso de submission a hstspreload.org es global y no tiene en cuenta el registrador — aplica igual para .cl que para .com.
X-Frame-Options: Previene Clickjacking
X-Frame-Options le indica al navegador si tu sitio puede ser embebido dentro de un iframe. Sin este header, un atacante puede colocar tu sitio en un iframe invisible y usar botones o formularios falsos encima para enganar a tus usuarios — esto se llama clickjacking.
Los valores posibles son:
X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN
DENY impide que cualquier sitio —incluido el tuyo— pueda embeber la pagina. Es la opcion mas segura. SAMEORIGIN permite embeber solo si el iframe es del mismo dominio. Para WordPress, SAMEORIGIN es lo mas comun porque muchos themes y plugins usan iframes internamente (por ejemplo, para widgets de redes sociales o videos).
Ojo con los payment gateways: Si usas WebPay, MercadoPago u otro processor de pagos que embebe su UI en un iframe, X-Frame-Options: DENY va a romper esos flujos. En esos casos, usa SAMEORIGIN y configura excepciones solo para el dominio del payment gateway, o elimina el header en las paginas de checkout usando un plugin que lo gestione por seccion.
X-Content-Type-Options: Detiene MIME Sniffing
Los navegadores modernos "adivinan" el tipo de contenido de un archivo cuando el header Content-Type no lo especifica claramente. Esto se llama MIME sniffing. El problema es que un atacante puede subir un archivo que parece una imagen pero contiene codigo JavaScript malicioso, y el navegador lo ejecutara pensando que es JavaScript.
El header es simple:
X-Content-Type-Options: nosniff
Con nosniff, el navegador respeta el Content-Type declarado por el servidor y no intenta adivinar. Esto es especialmente importante para sitios WordPress que permiten upload de archivos de usuarios: plugins de subida de imagenes, foros, perfiles de usuario, etc.
WordPress por si solo ya sirve los Content-Type correctos para la mayoria de archivos, pero agregar este header es una capa extra de proteccion que no tiene downside.
Referrer-Policy: Controla la Informacion de Referencia
Cada vez que un visitante hace clic en un enlace hacia otro sitio, el navegador envia un header Referer que indica desde que URL proviene. Este header puede filtrar informacion sensible — por ejemplo, si un usuario esta en una pagina de tu sitio con parametros en la URL que contienen un token o ID de sesion, ese dato se comparte con el sitio destino.
La politica recomendada para WordPress es:
Referrer-Policy: strict-origin-when-cross-origin
Esta politica dice: envia el referrer completo solo cuando el destino es del mismo dominio; cuando es cross-origin, envia solo el origen (dominio, sin la URL completa). No envia referrer cuando la conexion es de HTTPS a HTTP.
Si quieres mas privacidad, no-referrer elimina el referrer por completo, pero esto puede afectar tus estadisticas de analytics.
Permissions-Policy y Content-Security-Policy: Alternativas Modernas a X-Frame-Options
Permissions-Policy (antes llamado Feature-Policy) es el header moderno que permite controlar que APIs y caracteristicas del navegador puede usar tu sitio, como camara, microfono o geolocalizacion. Es mas granular que los headers tradicionales.
Por ejemplo, para desactivar geolocalizacion, camara y microfono en todo el sitio:
Permissions-Policy: geolocation=(); camera=(); microphone=()
Para controlar iframes especificamente (reemplazo de X-Frame-Options), debes usar la directiva frame-ancestors dentro del header Content-Security-Policy, no de Permissions-Policy:
Content-Security-Policy: frame-ancestors 'self'
La directiva frame-ancestors de Content-Security-Policy tiene el mismo efecto que X-Frame-Options pero con mas flexibilidad. Si decides usar CSP con frame-ancestors, puedes eliminar X-Frame-Options, ya que Content-Security-Policy: frame-ancestors 'self' es equivalente a X-Frame-Options: SAMEORIGIN.
Como Implementar Headers de Seguridad en WordPress
Tienes tres opciones para implementar estos headers en WordPress, dependiendo de tu nivel de acceso y preferencia tecnica.
Via .htaccess (Apache)
Si tu hosting usa Apache (como la mayoria de hosting compartido con cPanel), puedes agregar todos los headers de seguridad en el archivo .htaccess de tu sitio WordPress, ubicado en la raz del directorio publico:
# Headers de Seguridad
<IfModule mod_headers.c>
Header always set X-Content-Type-Options: "nosniff"
Header always set X-Frame-Options: "SAMEORIGIN"
Header always set X-XSS-Protection: "1; mode=block"
Header always set Referrer-Policy: "strict-origin-when-cross-origin"
Header always set Permissions-Policy: "geolocation=(), camera=(), microphone=()"
# HSTS (descomenta solo si todos los subdominios usan HTTPS)
Header always set Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload"
# CSP (descomenta cuando hayas probado con Report-Only)
# Header always set Content-Security-Policy: "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com; frame-src 'self';"
# CSP Report-Only (para probar antes de activar)
# Header always set Content-Security-Policy-Report-Only: "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com; frame-src 'self'; report-uri /csp-report-endpoint/;"
</IfModule>
Asegurate de que el modulo mod_headers esta habilitado en tu Apache. En hosting compartido con cPanel usualmente ya lo esta. La linea de HSTS esta comentada porque necesitas verificar que todos tus subdominios tienen HTTPS antes de activarla.
Via nginx.conf
Si tu servidor usa Nginx (comun en VPS o hosting de alto rendimiento), agrega los headers en el bloque server de tu archivo de configuracion:
server {
listen 443 ssl http2;
server_name tusitio.cl;
# Headers de Seguridad
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com; frame-src 'self';" always;
# ... resto de la configuracion
}
La directiva always al final de cada add_header asegura que el header se aplica a todas las respuestas, incluyendo respuestas de error. Si usas Nginx como reverse proxy frente a Apache, necesitas agregar los headers tanto en Nginx como en Apache para que cubran todas las respuestas.
Via Plugin: Really Simple SSL y Headers
Si prefieres no tocar archivos de configuracion, el plugin gratuito Really Simple SSL incluye opciones para activar headers de seguridad ademas de forzar HTTPS. Ve a SSL > Configuracion > Hardening y activa las opciones de headers que necesites.
Otra opcion dedicada es Security Headers, un plugin especifico que te permite activar, desactivar y personalizar cada header sin escribir codigo. Su ventaja es que te da control granular sobre cada directiva y te muestra una preview de como quedan tus headers antes de aplicar los cambios.
Ten en cuenta que los plugins de cache como LiteSpeed Cache o WP Rocket tambien incluyen opciones para headers de seguridad. Si ya usas alguno de estos, verifica si tienen la funcionalidad antes de instalar un plugin adicional.
Verificar tus Headers: Herramientas de Diagnostico
Una vez implementados, necesitas verificar que los headers estan funcionando correctamente. Tres herramientas gratuitas para esto:
securityheaders.com: Ingresa tu URL y obtienes una calificacion de A+ a F junto con un resumen de que headers tienes y cuales faltan. Es la forma mas rapida de validar tu configuracion.
Mozilla Observatory (observatory.mozilla.org): Similar a securityheaders.com pero con mas detalle tecnico. Te indica exactamente que falta y por que cada header mejora tu seguridad.
Chrome DevTools > Security tab: Abre tu sitio, presiona F12, ve a la pestana Security. Veras un resumen de los headers de seguridad activos y advertencias si algo falta.
Para verificar CSP especificamente, abre Chrome DevTools > Console despues de activar CSP. Si hay violaciones, las veras en rojo con el origen que fue bloqueado y la directiva que lo prohibio. Esto es mas detallado que las herramientas online porque refleja tu navegador real con tu sesion real.
Errores Comunes al Configurar CSP en WordPress
CSP es el header mas propenso a romper cosas si se implementa sin pruebas. Los errores mas comunes que vemos:
Bloquear Google Fonts: Muchos articles de CSP 'duros' dicen que fonts.googleapis.com debe estar en font-src. Pero si tu CSP no tiene font-src definido, fallback a default-src 'self', que bloquea Google Fonts. Asegurate de listar https://fonts.googleapis.com y https://fonts.gstatic.com en font-src.
Bloquear el admin bar de WordPress: El admin bar usa inline styles. Si tu CSP tiene style-src restrictivo, el admin bar se rompe. Incluye 'unsafe-inline' en style-src al menos para el area de administracion.
Bloquear iframes de payment gateways: Como mencionamos antes, WebPay, MercadoPago y otros usan iframes. Si tu CSP no tiene frame-src correctamente configurado, los pagos fallan silenciosamente.
No probar en Report-Only primero: Implementar CSP en modo de aplicacion directa sin haberlo probado en Report-Only es como cambiar el aceite del motor sin primero revisar que nivel tiene. Un CSP mal configurado puede romper tu sitio entero sin que te des cuenta hasta que un cliente te llama.
No actualizar la politica cuando agregas nuevos servicios: Cada vez que agregas un nuevo script third-party (un chat, un widget de reservas, una fuente nueva), necesitas actualizar tu CSP. Si no lo haces, el nuevo servicio no funcionara.
Conclusion: Headers de Seguridad = Capa Invisible pero Critica
Los headers de seguridad son una de esas mejoras que no ves, no afectan la experiencia del usuario y no cuestan nada — pero pueden ser la diferencia entre un sitio que sobrevive a un ataque y uno que compromete a tus usuarios.
La buena noticia es que implementarlos no es dificil. Empieza con los basicos (X-Content-Type-Options, X-Frame-Options, Referrer-Policy) que no tienen riesgo de romper nada. Activa HSTS solo despues de verificar que todos tus subdominios tienen HTTPS. Y CSP, si decides implementarlo, pruebalo primero en modo Report-Only durante al menos una semana.
En Elevocloud, nuestros planes de hosting incluyen soporte para todos estos headers. Si tienes dudas sobre como configurarlos en tu servidor, nuestro equipo tecnico puede orientarte sin costo adicional.
Imagen: Archivo .htaccess en la raz de tu WordPress con los headers de seguridad configurados. Asegurate de hacer backup del archivo antes de modificarlo.
Articulos relacionados: Que es SSL/TLS y para que sirve · Configurar SPF, DKIM y DMARC en cPanel · Hardening de seguridad WordPress
