🔒 Cabeceras de seguridad HTTP para WordPress: guía completa de configuración

Su sitio WordPress está funcionando, el plugin de seguridad está instalado, pero una verificación en securityheaders.com le da una F. ¿Le suena familiar?

Las cabeceras de seguridad HTTP son una capa invisible de protección que se pasa por alto incluso después de configurar un firewall y la autenticación de dos factores. No necesitan renovación de licencias, no cargan el servidor y bloquean clases enteras de ataques: desde el clickjacking hasta el secuestro de sesión. Y se añaden en 10 minutos.

A continuación, paso a paso: qué cabeceras necesita realmente, cómo configurarlas mediante.htaccess, functions.php o un plugin, y cómo verificar que la protección funciona, no solo que está listada.

💡 Resumen rápido:

• Verifique las cabeceras actuales de su sitio mediante securityheaders.com o Mozilla Observatory para ver la imagen real
• Active un conjunto básico de 4 a 5 cabeceras: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Elija su método: un par de líneas en.htaccess (Apache/LiteSpeed), un fragmento en functions.php o el plugin Headers Security Advanced & HSTS WP
• Deje CSP para más adelante: es delicado de configurar y rompe Gutenberg si se hace sin probar
• Tras la implementación, vuelva a verificar: una puntuación A+ se consigue en 10 minutos

Qué son las cabeceras de seguridad HTTP

Cuando un navegador solicita una página, el servidor web envía de vuelta algo más que código HTML. Cada respuesta HTTP contiene campos de servicio, las cabeceras. Algunas gestionan la caché y el tipo de contenido, y otras gestionan la seguridad.

El navegador lee las cabeceras de seguridad incluso antes de empezar a renderizar la página. Si el servidor dice «prohíbo incrustar este sitio en marcos», el navegador no lo hará, aunque el código de la página contenga un <iframe>. Si el servidor dice «use solo HTTPS durante un año», el navegador lo recuerda y no irá a la versión HTTP, aunque el usuario la escriba manualmente.

Aquí no intervienen JavaScript, ni plugins, ni firewalls. Esto es a nivel de protocolo. Esa es precisamente la razón por la que las cabeceras son una línea de defensa separada e independiente.

Por qué un sitio WordPress necesita esto

Los plugins de seguridad como Wordfence o Solid Security cierran vulnerabilidades a nivel de aplicación: fuerza bruta, inyecciones, cargas maliciosas. Las cabeceras HTTP funcionan un nivel por encima: protegen el propio canal de comunicación entre el servidor y el visitante.

Esto es lo que bloquean las cabeceras correctamente configuradas:

• Clickjacking. Un atacante incrusta su sitio en un marco transparente sobre el suyo propio e intercepta los clics del usuario. Bloqueado por la cabecera X-Frame-Options o la directiva frame-ancestors en CSP.

• MIME sniffing. El navegador intenta «adivinar» el tipo de archivo y puede ejecutar una imagen cargada como JavaScript. Bloqueado por X-Content-Type-Options: nosniff.

• Secuestro de sesión. Un atacante en una red wifi abierta altera la respuesta del servidor y roba las cookies de inicio de sesión. HSTS prohíbe al navegador acceder a la versión HTTP del sitio.

• Fuga de referrer. Al seguir un enlace externo, el sitio de destino ve desde qué página llegó el usuario, incluida la URL con parámetros. Referrer-Policy limita esto.

• Acceso no autorizado a dispositivos. Una página web solicita el micrófono, la cámara o la geolocalización sin que el usuario lo sepa. Permissions-Policy bloquea dichas solicitudes a nivel de navegador.

CSP añade otra capa: usted define explícitamente qué dominios pueden cargar scripts, estilos y fuentes. Incluso si código malicioso entra en la base de datos, el navegador no lo ejecutará porque el origen no está en la lista de permitidos. Pero CSP requiere cuidado: un pequeño error y el editor Gutenberg deja de funcionar.

Cabeceras de seguridad HTTP clave: qué incluyen y por qué

A continuación, las cabeceras que vale la pena configurar en cualquier sitio WordPress. Para cada una, especificamos: contra qué ataque protege, el valor recomendado y dónde podrían romperse las cosas.

X-Content-Type-Options

La más simple y segura de configurar. El único valor válido es nosniff. El navegador deja de «adivinar» el tipo MIME de un archivo basándose en su contenido y confía solo en el tipo que el servidor envió en la cabecera Content-Type.

Sin esta cabecera, el navegador podría tratar una imagen subida por un usuario como un script y ejecutarla, un escenario clásico de ataque por carga de archivos.

Valor recomendado: nosniff

Riesgos de rotura: mínimos. Solo puede haber problemas si el servidor sirve archivos con un Content-Type incorrecto, pero eso es un problema aparte que conviene corregir en lugar de enmascarar.

X-Frame-Options

Controla si su sitio puede ser incrustado en un <frame>, <iframe> u <object> en otro sitio.

Dos valores principales:

• DENY, prohibición total de incrustación. Máxima protección.
• SAMEORIGIN, incrustación permitida solo desde el mismo dominio. Necesario si usted mismo usa frames para sus propias páginas (por ejemplo, vista previa en el panel de administración).

Para la mayoría de los sitios WordPress, SAMEORIGIN funciona. Si sabe con certeza que no se usan frames, configure DENY.

Valor recomendado: SAMEORIGIN

Riesgos de rotura: algunos plugins usan iframes para vistas previas. Si algo deja de mostrarse en el panel de administración tras activar DENY, cambie a SAMEORIGIN.

Strict-Transport-Security (HSTS)

Le dice al navegador: «durante los próximos N segundos, acceda a este dominio solo mediante HTTPS». Protege contra ataques de degradación y secuestro de cookies en redes abiertas.

El parámetro clave es max-age. Se recomienda comenzar con un valor pequeño (un día o una semana) y, tras la verificación, aumentarlo a un año.

El parámetro opcional includeSubDomains extiende la regla a todos los subdominios, importante si tiene varios y usa un CDN.

El parámetro preload añade el sitio a la lista HSTS global de los navegadores: Chrome, Firefox y Safari accederán a su dominio solo mediante HTTPS incluso antes de la primera solicitud. Envíe una solicitud a través de hstspreload.org.

Valor recomendado: max-age=31536000; includeSubDomains

Riesgos de rotura: si habilita HSTS y el certificado SSL caduca, los usuarios no podrán acceder al sitio en absoluto. Vigile la renovación automática del certificado.

Referrer-Policy

Gestiona qué información sobre la página de origen envía el navegador al seguir un enlace a otro sitio.

Valores principales, del más estricto al más permisivo:

• no-referrer, no se envía nada en absoluto.
• strict-origin-when-cross-origin, a un dominio diferente, solo se envía el dominio (sin ruta ni parámetros); al propio, la URL completa. El equilibrio óptimo entre privacidad y analítica.
• strict-origin, siempre solo el dominio, sin ruta.

Si no quiere que los sitios de destino sepan de dónde vino el usuario, configure no-referrer. Pero tenga en cuenta: perderá el tráfico de referencia en su propia analítica.

Valor recomendado: strict-origin-when-cross-origin

Riesgos de rotura: mínimos. Algunos servicios de terceros pueden requerir un referrer para funcionar (por ejemplo, pasarelas de pago con verificación de origen). Puede rastrear estos casos a través de la consola del navegador.

Permissions-Policy

Anteriormente llamada Feature-Policy. Restringe el acceso de la página web a las API de «hardware» del navegador: micrófono, cámara, geolocalización, USB, API de pago, etc.

Formato: название-фичи=(разрешённый-источник). Por ejemplo:

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

Este ejemplo bloquea completamente el acceso a la cámara y al micrófono para todas las fuentes, y permite la geolocalización solo para el propio sitio (self).

Lista completa de funciones en MDN. Para un sitio WordPress sin videochats ni funcionalidades PWA, basta con bloquear la cámara, el micrófono y la geolocalización; el resto es opcional.

Valor recomendado: depende de la funcionalidad del sitio. Mínimo: camera=(), microphone=(), geolocation=(self).

Riesgos de rotura: si el sitio tiene funcionalidad de videollamadas, PWA o WebUSB, verifique qué funciones necesita y no las bloquee.

Content-Security-Policy (CSP)

La cabecera más potente y la más peligrosa de configurar. Define una lista blanca de fuentes para scripts, estilos, fuentes, imágenes, frames y otros recursos.

Ejemplo de una política mínima para WordPress:

1
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
2

*Por qué unsafe-inline y unsafe-eval:* WordPress, Gutenberg y decenas de plugins generan scripts en línea y usan eval(). Sin estas directivas, el panel de administración simplemente no funcionará. Este es el precio de la compatibilidad.

Recomendación: no habilite CSP primero. Configure las otras 5 cabeceras antes. Implemente CSP solo si dispone de recursos para pruebas y monitoreo; comience con el modo Content-Security-Policy-Report-Only y recopile registros de violaciones durante un par de semanas antes de cambiar al modo de aplicación.

Riesgos de rotura: altos. Un error en CSP puede romper por completo el frontend y el panel de administración. Pruebe siempre en un entorno de staging o mediante Report-Only.

Cómo verificar las cabeceras actuales de su sitio

Antes de configurar, una auditoría. Tres herramientas, de simple a detallada:

• securityheaders.com, introduzca la URL y obtenga una puntuación de A+ a F con un desglose para cada cabecera. Gratuito, sin registro.

• Mozilla Observatory, una auditoría más detallada: evalúa no solo las cabeceras, sino también la configuración TLS, los atributos de cookies, CORS y otros aspectos. También gratuito.

• Chrome DevTools, abra la pestaña Network, seleccione cualquier solicitud a su sitio y observe la sección Response Headers. Una forma rápida de comprobar si los cambios «surtieron efecto» tras editar.htaccess.

Verifique su sitio ahora mismo. Si la puntuación es inferior a B, no tiene ni siquiera las cabeceras básicas, y un tercio de los elementos siguientes los configurará en 5 minutos.

Formas de configurar encabezados HTTP en WordPress

Tres caminos, de manual a automático. Elija según su situación.

Método 1: vía.htaccess (Apache/LiteSpeed)

El método más rápido para sitios en Apache o LiteSpeed. Añada al archivo .htaccess en la raíz del sitio (antes de # BEGIN WordPress):

1
<IfModule mod_headers.c>
2
    Header set X-Content-Type-Options "nosniff"
3
    Header set X-Frame-Options "SAMEORIGIN"
4
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
5
    Header set Referrer-Policy "strict-origin-when-cross-origin"
6
    Header set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
7
</IfModule>

El envoltorio <IfModule mod_headers.c> asegura que el sitio no falle con un error 500 si el módulo mod_headers no está habilitado. Si sabe con certeza que está activo, puede omitirlo.

Después de guardar, ejecute en la terminal (si tiene WP-CLI) o simplemente abra el sitio y verifique los encabezados mediante securityheaders.com. Los cambios en .htaccess se aplican al instante; no es necesario reiniciar el servidor.

Método 2: vía functions.php (Nginx / universal)

Funciona independientemente del servidor web, adecuado tanto para Nginx como para Apache. Añada al functions.php de su tema hijo o mediante el plugin Code Snippets:

1
function sdstudio_add_security_headers() {
2
    header( 'X-Content-Type-Options: nosniff' );
3
    header( 'X-Frame-Options: SAMEORIGIN' );
4
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
5
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
6
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(self)' );
7
}
8
add_action( 'send_headers', 'sdstudio_add_security_headers' );

El hook send_headers se dispara antes de que WordPress empiece a enviar contenido, por lo que los encabezados salen en la primera respuesta del servidor.

Para Nginx, este método es preferible a hurgar en la configuración del servidor (especialmente en hosting compartido, donde el acceso a nginx.conf a menudo no está disponible). La desventaja: los encabezados solo funcionan para las peticiones PHP que pasan por WordPress. Los archivos estáticos (imágenes, CSS, JS) los sirve directamente Nginx y no recibirán los encabezados. Requieren configuración a nivel de servidor.

Método 3: mediante el plugin headers security advanced & hsts wp

Si no quiere tocar código, use un plugin dedicado. Headers Security Advanced & HSTS WP reúne todos los encabezados de seguridad en una interfaz y los habilita con un solo botón.

El plugin establece valores predefinidos para todos los encabezados clave inmediatamente después de la activación: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy y varios adicionales (CORP, COOP, COEP). Cada encabezado puede desactivarse o personalizarse según sus necesidades.

La ventaja de este enfoque: el plugin no depende del servidor web y funciona de forma idéntica en Apache, Nginx, LiteSpeed e IIS. Al desactivarlo, devuelve la configuración del sitio a su estado original.

Alternativa: Redirection

El plugin Redirection es conocido como un gestor de redirecciones, pero también puede añadir encabezados HTTP. Después de la instalación y configuración básica, vaya a la sección Site → Headers; la interfaz le permite especificar cualquier par "encabezado: valor".

Esta opción funciona si ya tiene Redirection instalado para la gestión de enlaces y no quiere añadir otro plugin. Pero un plugin de encabezados dedicado ofrece más control y valores predefinidos.

En el vídeo, una demostración visual de la configuración de encabezados mediante el plugin Headers Security Advanced: desde la instalación hasta la verificación del resultado en securityheaders.com.

⁉️🤔 Preguntas frecuentes

¿Qué pasa si el sitio se rompe después de habilitar los encabezados?

Primero, revise el encabezado Content-Security-Policy: causa la gran mayoría de las roturas. Desactive CSP (o cámbielo a modo Report-Only) y revise el sitio de nuevo. Un error 500 después de editar.htaccess: compruebe la sintaxis en busca de un espacio extra, comillas sin cerrar o un módulo mod_headers faltante. Por FTP, renombre.htaccess, el sitio volverá a la vida y podrá encontrar el error con calma.

En 9 de cada 10 casos, el problema es específicamente CSP, no los otros encabezados. X-Content-Type-Options, X-Frame-Options, HSTS y Referrer-Policy no pueden físicamente romper el sitio; no afectan al renderizado ni a la lógica PHP. Empiece siempre por esos.

¿Es obligatorio un plugin o se puede hacer por código?

Se puede y se debe hacer por código si sabe editar functions.php o.htaccess. Establecer los encabezados directamente mediante la configuración del servidor funciona más rápido que un plugin, sin una capa PHP intermedia. Pero un plugin es más conveniente para quienes no quieren tocar código y proporciona una interfaz visual con valores predefinidos para cada encabezado.

En nuestros sitios de prueba, usamos ambos enfoques: en producción,.htaccess (menos puntos de fallo); en sitios de cliente donde el hosting no permite editar la configuración, el plugin. El resultado en securityheaders.com es idéntico: A+ en ambos casos.

¿Necesito configurar CSP si el sitio está en WordPress?

Para la mayoría de los sitios, no. CSP en WordPress requiere unsafe-inline y unsafe-eval para que Gutenberg y decenas de plugins funcionen, lo que reduce el efecto protector a algo simbólico. Un CSP completo tiene sentido en proyectos de alta carga con un especialista en seguridad dedicado que analice cada informe de violación. Para todos los demás, los 5 encabezados básicos proporcionan la mayor parte de la protección práctica.

¿Cómo verifico que los encabezados funcionan después de la instalación?

Abra el sitio en un navegador, lance DevTools (F12) → pestaña Network → haga clic en la primera petición a su dominio → sección Response Headers. Si ve los encabezados añadidos, todo funciona. Para una verificación automatizada, use securityheaders.com: muestra no solo la presencia sino también la corrección de los valores, además de una puntuación final de A+ a F.

¿Qué pasa si el hosting no permite editar.htaccess y no hay acceso a functions.php?

Instale Headers Security Advanced & HSTS WP desde el panel de administración de WordPress. El plugin inyecta los encabezados a nivel de PHP y no requiere editar archivos del servidor. Esto funciona en cualquier hosting donde funcione WordPress, desde compartido barato hasta Managed WordPress.

¿Afectan los encabezados HTTP a la velocidad del sitio?

Prácticamente no. Los encabezados son un par de docenas de bytes de texto en la respuesta del servidor. No realizan cálculos, no hacen consultas a la base de datos y no cargan la CPU. El retraso que añaden se mide en microsegundos. La única excepción es CSP con una lista de permitidos compleja de cientos de dominios: el navegador tarda en analizarla, pero incluso entonces, el impacto en la velocidad de renderizado no supera un par de milisegundos.

Qué configurar y por dónde empezar

Los encabezados de seguridad HTTP no son una acción puntual de "configúrelo y olvídese". Son una línea base que debería estar en cada sitio por defecto, como un certificado SSL.

El plan para hoy:

• Compruebe su sitio en securityheaders.com. Si la puntuación es D o F, ni siquiera tiene X-Content-Type-Options.

• Añada los 5 encabezados básicos usando cualquiera de los tres métodos anteriores. Si el sitio está en Apache, vía.htaccess (30 segundos). Nginx sin acceso a la configuración, vía functions.php (2 minutos). Si no quiere tocar código, el plugin Headers Security Advanced (3 minutos incluyendo la instalación).

• Vuelva a comprobar el sitio. La puntuación debería subir a A o A+.

• Deje CSP de lado. Vuelva a ello una vez que los encabezados básicos hayan funcionado durante un mes sin problemas y tenga tiempo para pruebas mediante Report-Only.

Una hora, y su sitio WordPress gana una capa de defensa de la que carece la gran mayoría de los sitios en internet. Empiece con una comprobación ahora mismo.