Cabeceras de seguridad en WordPress: HTTPS, HSTS y CSP paso a paso

Las cabeceras de seguridad en WordPress se añaden en el servidor, en la CDN o con un pequeño plugin que engancha en send_headers, porque WordPress no las envía en las páginas públicas. Empieza por forzar HTTPS y después añade HSTS con un max-age corto, nosniff, Referrer-Policy, protección contra iframes, Permissions-Policy y una CSP en modo informe.

Para comprobarlo en tu web: Auditoría SEO

Una cabecera de seguridad es una línea de la respuesta HTTP que le dice al navegador qué puede y qué no puede hacer con tu página: si debe ir siempre por HTTPS, si otra web puede meterla en un iframe o desde dónde puede cargar scripts. WordPress controla el HTML que genera y unas pocas cabeceras de su escritorio. El resto depende de dónde se sirva la web: el servidor, la CDN o el alojamiento. Esta guía explica qué trae WordPress, qué añadir, con qué valor y dónde.

¿Qué cabeceras de seguridad envía WordPress por sí solo?

Muy pocas, y casi ninguna en las páginas que ven tus visitantes. Esto es lo que hace el código del núcleo en la rama 7.1, la actual1:

La conclusión práctica es que tus entradas, páginas y fichas salen sin HSTS, sin protección contra iframes y sin CSP salvo que alguien las añada. Si un análisis de cabeceras te las marca como ausentes, no es un fallo de tu tema: es lo normal en WordPress.

Paso 1: fuerza HTTPS en WordPress y en el servidor

Sin HTTPS, el resto de cabeceras sirve de poco: el navegador ignora HSTS si llega por HTTP3. El cambio tiene tres partes:

1. El certificado. Lo instala el alojamiento o el servidor. Comprueba que https:// carga sin avisos antes de seguir.
2. Las dos URL de WordPress. En Ajustes > Generales, cambia a https:// la Dirección de WordPress (URL) y la Dirección del sitio (URL). Si están definidas en wp-config.php con WP_SITEURL y WP_HOME, los campos salen bloqueados y hay que cambiarlas allí4. Desde la 5.7, la Salud del sitio ofrece además un botón para pasar todo el sitio a HTTPS cuando detecta que el servidor lo admite, y sustituye al vuelo las URL http:// del contenido5.
3. La redirección 301 en el servidor. WordPress redirige algunas URL, pero las imágenes, el CSS y cualquier fichero que sirva el servidor directamente no pasan por PHP. La redirección de http a https va en el servidor: tienes el paso a paso en las guías de .htaccess con HTTPS y HSTS en Apache y de HTTPS y HSTS en Nginx.

Para el acceso y el escritorio, la documentación de WordPress propone la constante FORCE_SSL_ADMIN en wp-config.php, que obliga a que el acceso y las sesiones de administración vayan por HTTPS6. Si un proxy inverso o una CDN terminan el TLS y te reenvían la petición por HTTP, la misma página documenta cómo marcar la petición como segura para evitar un bucle de redirecciones6. Esta es su versión, con una comprobación añadida para que no dé un aviso si la cabecera no llega:

define( 'FORCE_SSL_ADMIN', true );

// Solo si un proxy de confianza termina el TLS y te llega por http.
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
	&& false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
	$_SERVER['HTTPS'] = 'on';
}

Úsalo solo si de verdad hay un proxy delante: cualquiera puede enviar X-Forwarded-Proto si el servidor es accesible directamente.

Paso 2: qué cabeceras añadir y con qué valor

Esta tabla resume un punto de partida razonable para un WordPress, con los valores que documenta MDN:

Dos cabeceras que no conviene añadir:

• X-XSS-Protection: 1. MDN recomienda usar CSP en su lugar y avisa de que esta cabecera puede crear vulnerabilidades en webs que eran seguras10. Si tu alojamiento la pone, el valor menos arriesgado es 0.
• HSTS con preload el primer día. Para entrar en la lista de precarga de los navegadores hace falta includeSubDomains y un max-age de al menos un año, y salir de esa lista es muy difícil3. Afecta a todos los subdominios, también al que aún no tiene certificado. Llega a ello solo cuando lleves meses con HSTS sin problemas.

X-Frame-Options frente a frame-ancestors

Las dos impiden que otra web cargue la tuya en un iframe. X-Frame-Options es la antigua y solo admite DENY o SAMEORIGIN; la directiva frame-ancestors de CSP es la moderna y admite una lista de orígenes8. WordPress envía ya las dos en el acceso y el escritorio2. En las páginas públicas, mientras tu CSP siga en modo informe, mantén X-Frame-Options: SAMEORIGIN, porque frame-ancestors dentro de una política Report-Only avisa pero no protege.

¿Por qué una CSP estricta es difícil en WordPress?

Una CSP (Content Security Policy) es la lista de orígenes desde los que la página puede cargar scripts, estilos, imágenes o marcos. Por defecto, si la política incluye script-src, el navegador no ejecuta JavaScript en línea, y MDN advierte de que 'unsafe-inline' anula buena parte del sentido de tener una CSP11.

En WordPress hay mucho JavaScript en línea: el que imprime el núcleo, el de los temas y el de casi cualquier plugin de formularios, analítica o cookies. Desde la 5.7, WordPress tiene funciones y filtros para añadir atributos a las etiquetas de script que imprime, y su anuncio las presentaba como un camino hacia una CSP en el núcleo, los plugins y los temas12. Pero los plugins que escriben su propio <script> no pasan por ahí.

Por eso el orden sensato es este:

1. Publica la política como Content-Security-Policy-Report-Only. No bloquea nada.
2. Navega por la web con las herramientas de desarrollo abiertas: cada infracción aparece en la consola. Si quieres recibir los informes, declara un destino con Reporting-Endpoints y la directiva report-to9.
3. Ajusta la política hasta que las páginas importantes no den avisos.
4. Solo entonces cámbiala a Content-Security-Policy. Ten en cuenta que, si hay dos políticas, el navegador aplica las dos y gana la más restrictiva11.

Dónde poner las cabeceras: servidor, CDN o PHP

Si no puedes tocar el servidor ni la CDN, un mu-plugin es la opción más limpia. Los must-use plugins son ficheros PHP en wp-content/mu-plugins/ que WordPress carga siempre y que no se pueden desactivar desde el escritorio13. La acción send_headers sirve para añadir cabeceras a la respuesta y, desde la 6.1, se ejecuta después de la consulta principal, así que admite etiquetas condicionales14. Guarda esto como wp-content/mu-plugins/cabeceras-seguridad.php:

<?php
/**
 * Plugin Name: Cabeceras de seguridad
 * Description: Añade cabeceras de seguridad a las páginas que genera WordPress.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'send_headers', function () {
	if ( headers_sent() ) {
		return;
	}

	// HSTS solo por HTTPS (por HTTP el navegador la ignora).
	// Empieza con 5 minutos; súbelo a 31536000 cuando todo vaya por https.
	if ( is_ssl() ) {
		header( 'Strict-Transport-Security: max-age=300' );
	}

	header( 'X-Content-Type-Options: nosniff' );
	header( 'Referrer-Policy: strict-origin-when-cross-origin' );
	header( 'X-Frame-Options: SAMEORIGIN' );
	header( 'Permissions-Policy: camera=(), microphone=(), geolocation=()' );

	// CSP en modo informe: no bloquea nada, solo avisa en la consola.
	header(
		"Content-Security-Policy-Report-Only: default-src 'self'; "
		. "script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; "
		. "img-src 'self' data: https:; font-src 'self' data:; "
		. "frame-ancestors 'self'; object-src 'none'; base-uri 'self'"
	);
} );

La CSP de ejemplo es un punto de partida, no una política segura: lleva 'unsafe-inline' para que puedas ver primero qué más carga tu web. Si usas fuentes, vídeos o analítica de otros dominios, la consola te dirá cuáles añadir.

Tres límites de esta vía:

• No cubre los ficheros estáticos (imágenes, CSS, JS) que entrega el servidor sin pasar por WordPress, ni el escritorio.
• Una caché de página puede saltársela. Si tu caché sirve el HTML guardado sin ejecutar PHP, las cabeceras pueden no salir en las páginas cacheadas. Compruébalo con curl en una página que ya esté en caché.
• Una cabecera, un sitio. Si el servidor ya pone X-Frame-Options y el mu-plugin también, acabarás con valores duplicados. Elige dónde vive cada cabecera.

Cómo comprobarlo

Empieza por pedir las cabeceras de una página pública y de una imagen. Si la página las lleva y la imagen no, las estás poniendo desde PHP:

curl -sI https://www.ejemplo.es/
curl -sI https://www.ejemplo.es/wp-content/uploads/2026/10/foto.jpg

Después:

1. Pasa la portada por el HTTP Observatory de Mozilla, que revisa las cabeceras de seguridad y la redirección a HTTPS15.
2. Abre la consola del navegador en tus páginas clave y busca avisos de la CSP en modo informe.
3. Revisa en Herramientas > Salud del sitio que no haya avisos de HTTPS.

Qué hace SmoothSeen con esto

SmoothSeen comprueba en cada análisis si la página va por HTTPS, si http redirige a https y qué cabeceras de seguridad envía, usando el HTTP Observatory de Mozilla. El resultado entra en la nota de Posicionamiento web y, si falta algo, aparece como tarea en el plan de acción con el motivo.

Qué hacer esta semana

Haz el curl -I a tu portada y anota qué cabeceras faltan. Si tienes acceso al servidor, añádelas allí; si no, instala el mu-plugin con HSTS a cinco minutos y la CSP en modo informe, y revisa la consola durante unos días. Para ver el resultado junto al resto de comprobaciones técnicas, analiza tu web con SmoothSeen.

Preguntas frecuentes

¿Necesito un plugin de seguridad para añadir cabeceras en WordPress?

No. Un plugin de seguridad puede hacerlo, pero también lo hace el servidor, la CDN o un mu-plugin de veinte líneas que controlas tú. Lo importante es que cada cabecera se defina en un único sitio, porque varios plugins o capas añadiendo la misma cabecera producen valores duplicados que cuesta depurar. Si ya tienes un plugin que las gestiona, revisa sus valores con curl -I.

¿Cuándo puedo subir HSTS a un año?

Cuando lleves al menos unos días con un max-age corto sin ningún problema: todas las páginas cargan por HTTPS, no hay contenido mixto y los subdominios que usas tienen certificado. Entonces sube a 31536000 segundos. Añadir includeSubDomains o preload es otra decisión, porque afecta a todos los subdominios y la precarga es muy difícil de retirar.

¿Por qué mi CSP rompe el escritorio de WordPress?

Porque probablemente la has puesto en el servidor para todo el dominio, incluido /wp-admin/, y el escritorio y el editor de bloques usan JavaScript y estilos en línea. El mu-plugin de esta guía no tiene ese problema porque send_headers no se ejecuta en el escritorio. Si la configuras en el servidor, limítala a la parte pública o pruébala antes en modo Report-Only.

¿Sigue haciendo falta FORCE_SSL_ADMIN si todo el sitio ya va por HTTPS?

Con las dos URL en https:// y la redirección en el servidor, el escritorio ya va por HTTPS en la práctica. La constante añade una garantía: WordPress fuerza HTTPS en el acceso y las sesiones de administración aunque falle otra capa. Es una línea en wp-config.php y la documentación oficial la sigue proponiendo, así que vale la pena dejarla puesta.