Cabeceras de seguridad en WordPress con LiteSpeed (2026)

Actualizado el 02/09/2026: Se incorporan secciones nuevas sobre la elección entre X-Frame-Options DENY y SAMEORIGIN, cómo leer violaciones de CSP en DevTools paso a paso, y una matriz de impacto que muestra exactamente qué funcionalidad puede romperse con cada header.

En pocas palabras: Configurá seis cabeceras de seguridad —X-Frame-Options, Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy y Permissions-Policy— en el .htaccess de tu servidor LiteSpeed y bloqueás clickjacking, XSS y MIME sniffing sin plugins pagos: la tarea toma menos de 15 minutos.

Si tu WordPress corre sobre LiteSpeed, configurar cabeceras de seguridad HTTP toma menos de quince minutos y no necesita plugins pagos: seis cabeceras (X-Frame-Options, Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy y Permissions-Policy) bloquean clickjacking, XSS y MIME sniffing directo desde el .htaccess.

Las cabeceras de seguridad HTTP son instrucciones que tu servidor envía al navegador junto con cada respuesta, antes de renderizar cualquier contenido. Le indican al navegador cómo comportarse con tu sitio: si puede mostrar la página dentro de un iframe, qué scripts puede ejecutar, si debe exigir HTTPS. En WordPress se configuran a nivel servidor (Apache, NGINX o LiteSpeed) o desde el propio CMS, y complementan tu plugin de seguridad, no lo reemplazan.

¿Qué son las cabeceras de seguridad HTTP y por qué protegen WordPress?

Protegen WordPress porque actúan donde tu plugin de seguridad no llega: en el navegador del visitante, después de que tu página ya salió del servidor. Tu plugin escanea archivos, limita logins, bloquea IPs. Todo eso pasa dentro de WordPress. Pero hay toda una familia de ataques que arranca cuando el navegador ya recibió tu HTML: si no le das instrucciones claras, el navegador hace lo que el atacante quiere.

Ponele que alguien arma una réplica de tu tienda con un iframe invisible encima del botón «Comprar». El usuario cree que está comprando en tu sitio, pero el clic va a parar a otra acción que el atacante eligió. Eso es clickjacking, y se evita con una sola línea de configuración. Cada cabecera tapa un agujero concreto:

• Clickjacking: cargan tu sitio dentro de un iframe invisible para robar clics. Lo frenan X-Frame-Options y frame-ancestors.
• XSS (Cross-Site Scripting): inyección de JavaScript malicioso que roba sesiones o credenciales. La mitigación principal es Content-Security-Policy.
• MIME sniffing: el navegador «adivina» el tipo de un archivo y termina ejecutando algo que era un texto inofensivo. X-Content-Type-Options: nosniff lo corta.
• Filtración de datos y downgrade: Referrer-Policy evita filtrar URLs internas (a veces con tokens incluidos) y HSTS impide que te bajen de HTTPS a HTTP.
• CSRF: acá la pieza clave es el atributo SameSite de las cookies, que también viaja en una cabecera. Las cabeceras de esta guía ayudan, pero SameSite hace el trabajo pesado.

¿Cuáles son las cabeceras imprescindibles para hardening de WordPress?

Son seis. Ni una más, ni una menos para cubrir los ataques comunes de un WordPress típico. Te puede servir nuestra cobertura de cuándo un solo firewall no alcanza.

• X-Frame-Options está marcada como obsoleta y aun así conviene mandarla. La referencia de X-Frame-Options en MDN indica que la alternativa moderna es frame-ancestors dentro de CSP, pero enviar ambas cubre navegadores que no implementan CSP completa.
• HSTS es la única capaz de dejarte afuera de tu propio sitio. Le estás diciendo al navegador «por un año, entrá solo por HTTPS». Si tu certificado vence o nunca tuviste SSL bien configurado, el visitante ve un error y no puede pasar ni queriendo. Primero SSL impecable, después HSTS. Y ojo con includeSubDomains: solo si todos tus subdominios tienen HTTPS.
• CSP es la más potente y la más traicionera. Una política mal armada rompe sliders, formularios y chats embebidos. Por eso tiene sección propia más abajo.

¿Cómo agregar cabeceras de seguridad en el .htaccess con LiteSpeed?

LiteSpeed Web Server lee el archivo .htaccess y soporta las directivas Header de mod_headers de Apache, así que configurar cabeceras de seguridad en LiteSpeed es idéntico a hacerlo en cualquier hosting Apache, como confirma la documentación oficial de LiteSpeed. No hace falta reiniciar nada ni pedirle favores al soporte.

• Hacé backup del .htaccess actual. Descargalo por FTP o desde el administrador de archivos del panel. Si algo falla, lo subís de vuelta y listo.
• Abrí el editor de archivos. El .htaccess vive en la raíz de tu instalación, al lado de wp-config.php. Suele estar oculto: activá «mostrar archivos ocultos» si no aparece.
• Pegá el bloque antes de «# BEGIN WordPress». Antes, no después: WordPress reescribe su bloque cuando cambiás los permalinks, y lo tuyo tiene que sobrevivir a eso.
• Guardá, purgá caché y probá. Recargá el sitio y verificá con DevTools o con securityheaders.com.

# Cabeceras de seguridad
<IfModule mod_headers.c>
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 Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Ese «always» no es decoración: hace que la cabecera salga también en respuestas de error (404, 500), que es justo cuando algunos ataques aprovechan. Y esto aplica en cualquier hosting que corra LiteSpeed o Apache, que es la mayoría del mercado argentino; si tu sitio está en donweb.com, por ejemplo, el administrador de archivos del panel te deja editar el .htaccess sin abrir ni FTP.

¿Y si tu servidor es NGINX? Ahí no existe .htaccess: las cabeceras van en la configuración del bloque server y necesitás acceso root o un ticket al soporte. Otra razón para celebrar que LiteSpeed hable el idioma de Apache.

¿Debería usar X-Frame-Options DENY o SAMEORIGIN?

Para la mayoría de los sitios WordPress, SAMEORIGIN es la opción correcta. Bloquea que tu sitio se embeba en iframes de dominios externos, pero permite que tus propias páginas se muestren dentro de otras páginas del mismo dominio. DENY, en cambio, lo prohíbe absolutamente todo: ni tu propio sitio puede incluirse en un iframe propio.

La diferencia parece técnica, pero tiene consecuencias concretas. Si usás DENY y tenés un widget embebido desde tu propio dominio, una vista previa de página en el admin de WordPress, o cualquier iframe que cargue una URL del mismo sitio, va a romperse. Eso incluye cosas tan inocentes como algunos constructores de páginas que usan iframes internos para la vista previa en vivo. SAMEORIGIN sortea eso.

El tercer valor, ALLOW-FROM, que en teoría permitía definir un dominio específico autorizado, está deprecado. Los navegadores modernos lo ignoran por completo, según documenta Malcare en su análisis de X-Frame-Options para WordPress. No vale la pena incluirlo.

Ahora bien, hay un detalle que pocas guías aclaran: si ya tenés CSP activa con la directiva frame-ancestors 'self', estás cubriendo el mismo terreno que SAMEORIGIN. Los navegadores modernos prefieren la directiva CSP y, en caso de conflicto, gana frame-ancestors. Pero los navegadores más viejos que no entienden CSP completa siguen leyendo X-Frame-Options. El consejo práctico es enviar ambas durante un tiempo largo: las diferencias de comportamiento entre navegadores justifican la redundancia. Complementá con estrategia integral de defensa en capas.

En la práctica, si el sitio es un blog, un ecommerce o un portfolio, SAMEORIGIN es la configuración que vas a querer. DENY tiene sentido para páginas de alta sensibilidad donde estás dispuesto a aceptar posibles roturas a cambio de máxima restricción. Una alternativa limpia para quien ya tiene CSP bien configurada: usá frame-ancestors 'self' en la política y mandá X-Frame-Options SAMEORIGIN como fallback.

¿Cómo añadir cabeceras desde functions.php sin tocar el servidor?

El hook send_headers de WordPress te permite mandar cabeceras desde functions.php, útil cuando el hosting no te da acceso al .htaccess o cuando preferís mantener todo dentro del tema.

add_action('send_headers', 'agregar_cabeceras_seguridad');

function agregar_cabeceras_seguridad() {
 if (is_admin()) {
 return;
 }
 header('X-Frame-Options: SAMEORIGIN');
 header('X-Content-Type-Options: nosniff');
 header('Referrer-Policy: strict-origin-when-cross-origin');
}

• A favor: no tocás el servidor, funciona en cualquier hosting y sobrevive actualizaciones si lo ponés en un tema hijo o en un plugin de snippets.
• En contra: PHP procesa cada petición, así que pesa un poco más que la ruta .htaccess, y solo cubre respuestas generadas por WordPress: imágenes y CSS servidos directo quedan afuera.

Ojo con actualizar el tema padre: si pusiste el código ahí, se borra con la próxima actualización. Tema hijo o plugin de snippets, siempre.

¿Qué plugins gratuitos configuran cabeceras de seguridad en WordPress?

En el repositorio oficial hay varias opciones gratuitas con panel de control: Headers Security Advanced & HSTS WP, HTTP Headers y All In One WP Security & Firewall son los tres nombres que aparecen en todas las guías serias, incluida la de Patchstack. Instalás, activás, tildás cada cabecera desde el dashboard y listo. Sin tocar una línea de código.

Una mención aparte merece WPCode. No es un plugin de security headers sino un gestor de snippets de código, pero es una de las mejores formas de implementar el hook send_headers sin editar el tema: pegás el snippet en WPCode, lo activás, y sobrevive actualizaciones del tema sin perder nada. Es la alternativa intermedia entre functions.php manual y un plugin dedicado, y es especialmente útil si el hosting no te da acceso al .htaccess.

La contracara de cualquier plugin: un plugin más que actualizar, y según cómo esté implementado, las cabeceras salen solo de páginas PHP. Para un blog chico zafa perfecto; para un sitio grande, prefiero la ruta del servidor.

¿Y LiteSpeed Cache? Acá va un matiz que pocas guías aclaran: ese plugin maneja cabeceras de caché (fijate en DevTools y vas a ver x-litespeed-cache y sus amigas), no un panel de security headers. Su papel en esta historia es otro: después de editar el .htaccess, botón de purgar caché, o vas a seguir viendo las cabeceras viejas media hora preguntándote por qué no cambió nada. En endurecer WordPress con Patchstack profundizamos sobre esto.

Plugin, código manual o CDN: ¿qué conviene para cabeceras de seguridad?

Las tres rutas llegan al mismo lugar. La diferencia está en dónde se aplica cada cabecera y cuánto control tenés.

Todas las opciones tienen camino gratis: el .htaccess y functions.php no cuestan nada, los plugins del repositorio son gratuitos y hasta algunos CDN permiten modificar cabeceras de respuesta en su plan free. Pagar solo tiene sentido si querés que alguien más se ocupe. Para más detalles técnicos, mirá fortalecer el acceso administrativo.

¿Qué headers pueden romper funcionalidad? Matriz de impacto

La pregunta que más se repite en los foros de soporte no es «¿cómo activo los headers?» sino «¿por qué se me rompió X después de activarlos?». Cada cabecera afecta una dimensión distinta del comportamiento del navegador, y hay combinaciones de plugins o servicios de terceros que rozan exactamente esas restricciones.

Lo más común: activás CSP y de repente el widget de chat embebido desde un dominio externo desaparece, o el checkout de WooCommerce deja de cargar el script de la pasarela de pago. El problema no es la cabecera en sí, sino que la política no incluye el dominio del servicio externo. Según documenta Really Simple SSL en su guía de CSP para WordPress, este es el error más frecuente al implementar Content Security Policy: arrancar con una política estricta sin mapear antes todos los recursos externos que el sitio ya carga.

La Referrer-Policy merece un párrafo propio porque su impacto en analytics sorprende a muchos. Si configurás no-referrer o no-referrer-when-downgrade sin entender las implicancias, tus herramientas de medición van a empezar a registrar tráfico orgánico como «directo», haciendo inútiles los reportes de adquisición. El valor strict-origin-when-cross-origin es el equilibrio que recomiendan tanto Mozilla como la guía de Melapress sobre políticas de seguridad en WordPress: manda el origen (el dominio, sin la ruta) en pedidos cross-origin por HTTPS, nada más. Eso protege URLs internas que podrían contener tokens o parámetros de sesión, sin destruir la atribución de tráfico.

Permissions-Policy es el header menos urgente y el que menos rompe cosas, siempre que no uses cámara ni micrófono en el sitio. Si tu sitio tiene un plugin de videollamadas o formularios de video, revisá bien antes de deshabilitar esos permisos. En la mayoría de los blogs y sitios de contenido, camera=(), microphone=(), geolocation=() está perfectamente bien.

¿Cómo verifico que los headers están funcionando correctamente?

securityheaders.com escanea tu sitio gratis en segundos y te da una nota de A+ a F, igual que un boletín escolar pero con menos drama. El flujo es simple:

• Escaneá tu dominio. Poné la URL, dale Scan y esperá unos segundos.
• Leé el reporte. Te lista cada cabecera que falta, con explicación de para qué sirve.
• Corregí y repetí. Aplicá los cambios, purgá caché y volvé a escanear hasta clavar la nota que buscás.

Sin salir del navegador también podés: apretás F12, vas a Network, recargás la página, hacés clic en el primer pedido (el documento HTML) y mirá Response Headers. Ahí están todas las cabeceras que tu servidor mandó, en vivo.

Para el A+ hace falta HSTS serio, con un max-age largo y la directiva preload si querés entrar al registro de HSTS Preload. Los criterios exactos los publica el propio servicio, así que tomá la nota como guía y no como dogma. Dos ayudas extra: HSTS Preload valida tu política de transporte estricto, y CSP Evaluator (herramienta de Google) revisa tu Content-Security-Policy antes de que la actives y rompas algo.

¿Cómo configurar Content-Security-Policy sin romper el sitio?

Todos conocemos la película: activás una CSP estricta un viernes a la tarde, guardás, recargás la home y de repente el slider no desliza, el formulario de contacto no envía, el widget de WhatsApp desapareció y el cliente te está llamando, porque cada plugin mete sus propios scripts inline y ninguno estaba en tu lista de permitidos.

Por eso existe Content-Security-Policy-Report-Only: le avisás al navegador que reporte violaciones en la consola sin bloquear nada. Vivís una o dos semanas leyendo la consola, anotás cada dominio que tu sitio realmente usa, y recién ahí activás la CSP en firme.

# Modo prueba: reporta sin bloquear
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"

# Modo firme, una vez validado
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; frame-ancestors 'self'"

Lo que muchas guías omiten es cómo leer las violaciones en DevTools. Abrís F12, vas a Console y buscás mensajes del tipo Refused to load the script o Content Security Policy: The page's settings blocked the loading of a resource. Cada mensaje te dice tres cosas: la directiva que falló (script-src, img-src, etc.), el recurso bloqueado (la URL exacta del script o imagen), y la página donde ocurrió. Con esa lista construís tu política real: por cada dominio bloqueado que es legítimo, lo agregás a la directiva correspondiente. Ya lo cubrimos antes en guía completa de headers HTTP.

Esa política de arranque acepta scripts y estilos inline (WordPress core y la mitad de los plugins los inyectan, es la cruda realidad) pero ya bloquea todo lo externo que no declaraste. De ahí en adelante vas cerrando: sacás unsafe-inline cuando identifiques qué scripts podés mover a archivos, agregás dominios específicos por directiva. Un sitio típico de WordPress con analytics, un mapa de Google y fuentes externas termina con una política de cuatro o cinco líneas que cubre el 95% de los casos.

¿Las cabeceras de seguridad afectan la velocidad o el SEO de WordPress?

En la práctica, no. Hablamos de unos cientos de bytes extra por respuesta y de instrucciones que el navegador procesa igual que cualquier otra cabecera. No hay caso documentado de caída de rendimiento atribuible a estas cabeceras.

Al SEO hasta le juega a favor: un sitio con HTTPS forzado por HSTS transmite confianza, y Google usa HTTPS como señal de ranking desde hace años, leve pero existe. Lo que sí te puede hundir el SEO es una CSP mal configurada que rompe el checkout o los embeds. De nuevo: Report-Only primero.

Velocidad intacta, SEO neutro o mejor. El riesgo está en configurar mal, no en configurar. Lo explicamos a fondo en asegurar la base de datos MySQL.

¿Con cabeceras de seguridad alcanza o necesito también un WAF?

No, no alcanza sola. Las cabeceras frenan ataques del lado del navegador, pero no parchean un plugin vulnerable, no detienen fuerza bruta en tu login y no limpian malware ya instalado.

La receta completa sigue siendo la de siempre: todo actualizado, un WAF (el de tu plugin de seguridad o uno a nivel DNS), backups automáticos y estas cabeceras como capa extra. Cada capa cubre lo que la anterior no ve.

Errores comunes al configurar cabeceras de seguridad (y cómo evitarlos)

Estos cinco tropiezos aparecen una y otra vez en los foros de soporte de WordPress. Todos tienen arreglo, y mejor todavía: todos tienen prevención.

• Activar HSTS sin SSL funcionando. Síntoma: el sitio queda inaccesible incluso para vos, porque el navegador se niega a bajar a HTTP. Arreglo: esperá a que expire el max-age (por eso arrancá con valores cortos tipo max-age=300 mientras probás) o entrá desde otro navegador. Prevención: SSL verificado primero, HSTS después.
• CSP estricta de un saque. Síntoma: sliders muertos, formularios que no envían, embeds rotos. Arreglo: volvé a Report-Only y reconstruí la política con lo que la consola te muestra. Prevención: siempre Report-Only una o dos semanas.
• No purgar la caché después de editar. Síntoma: cambiaste todo y el escáner sigue mostrando lo mismo. Spoiler: casi siempre es la caché. Arreglo: purgá LiteSpeed Cache (o el que uses) y volvé a escanear.
• Olvidar Permissions-Policy. Síntoma: avisos en la consola sobre permisos denegados. No es un agujero de seguridad, pero ensucia la consola y complica debuggear. Arreglo: una línea con camera=(), microphone=(), geolocation=() y silencio.
• Copiar una configuración «universal» de internet. Síntoma: media funcionalidad rota porque tu stack carga servicios que la config del tutorial no contemplaba. Arreglo: partí de la base mínima y agregá según lo que tu sitio realmente use.

Qué está confirmado y qué no

• Confirmado: LiteSpeed Web Server soporta directivas Header de Apache en .htaccess, según su documentación oficial.
• Confirmado: securityheaders.com ofrece análisis gratuito con notas de A+ a F.
• Confirmado: MDN documenta X-Frame-Options como reemplazada por frame-ancestors de CSP en navegadores modernos.
• Confirmado: el valor ALLOW-FROM de X-Frame-Options está deprecado y los navegadores actuales lo ignoran.
• Confirmado: los tres métodos de esta guía (.htaccess, functions.php, plugins del repositorio) son gratuitos.

• No hay configuración única: la CSP depende de qué scripts carga cada sitio, así que ninguna receta copiada sirve tal cual.
• Los criterios de puntaje los define securityheaders.com y puede ajustarlos; consultá siempre su propia documentación.
• No existen cifras públicas confiables sobre qué porcentaje de sitios WordPress usa estas cabeceras. Desconfiá de quien te tire un número.
• Habría que ver cómo evoluciona la adopción de frame-ancestors: hasta que todos los navegadores en circulación soporten CSP completa, conviene enviar X-Frame-Options como fallback.

Preguntas Frecuentes

¿Qué son las cabeceras de seguridad HTTP y por qué importan en WordPress?

Son instrucciones que el servidor adjunta a cada respuesta y que el navegador cumple antes de mostrar la página: con quién puede enmarcar tu sitio, qué scripts ejecutar, si exigir HTTPS. Importan porque cubren ataques como clickjacking, XSS y MIME sniffing, que ocurren en el navegador, donde tu plugin de seguridad no llega. Sobre eso hablamos en autenticación moderna con passkeys.

¿Cuál es la diferencia entre X-Frame-Options DENY y SAMEORIGIN?

DENY prohíbe que tu sitio se muestre en cualquier iframe, sin excepción. SAMEORIGIN lo permite solo cuando el iframe está dentro de una página del mismo dominio. Para la mayoría de los sitios WordPress, SAMEORIGIN es la opción correcta: DENY puede romper vistas previas de constructores de página y widgets propios embebidos, sin agregar una protección significativamente mayor contra clickjacking externo.

¿Cómo verifico si mis security headers están activos?

Escaneá tu dominio en securityheaders.com y obtenés una nota de A+ a F con el detalle de lo que falta. También podés abrir DevTools (F12), ir a Network, recargar la página y revisar Response Headers del documento principal: ahí aparecen todas las cabeceras que tu servidor mandó en esa respuesta.

¿Las cabeceras de seguridad reemplazan a un plugin de seguridad o a un firewall?

No. Las cabeceras protegen la interacción del navegador con tu sitio; un WAF filtra tráfico malicioso antes de que llegue y un plugin de seguridad cubre login y malware. Son capas complementarias, y un hardening serio usa las tres.

¿Cómo configuro CSP en WordPress sin romper iframes ni scripts externos?

Activá primero Content-Security-Policy-Report-Only en lugar de Content-Security-Policy. Eso hace que el navegador registre violaciones en la consola sin bloquear nada. Revisá DevTools durante una o dos semanas, anotás cada dominio externo que el sitio carga (analytics, fuentes, pasarelas de pago, chats), los agregás a las directivas correspondientes, y recién ahí cambiás a la cabecera en firme.

¿Qué pasa con Referrer-Policy y las herramientas de analytics?

Si configurás Referrer-Policy con un valor demasiado restrictivo (como no-referrer), tus herramientas de analytics van a ver el tráfico externo como «directo» y perdés la atribución de fuentes. El valor strict-origin-when-cross-origin manda solo el dominio de origen (sin la ruta) en pedidos HTTPS cross-origin: protege URLs internas con tokens sin romper la medición de tráfico.

Conclusión

Implementar headers de seguridad HTTP en WordPress sigue siendo una de las mejores relaciones costo-beneficio en hardening: quince minutos de trabajo, cero costo, y cubrir un vector de ataque que ningún plugin toca por defecto. Lo que cambió con la información que sumamos en esta actualización es la claridad sobre las decisiones clave: SAMEORIGIN en lugar de DENY para X-Frame-Options, Report-Only antes de activar CSP, strict-origin-when-cross-origin como valor seguro para Referrer-Policy sin destruir analytics.

El orden sigue siendo el mismo: SSL primero, cabeceras básicas después, CSP al final y en modo Report-Only. Si después de leer esto todavía no tenés una nota mínima de B en securityheaders.com, el paso siguiente está claro. Si ya tenés B o mejor, la próxima tarea es revisar qué recursos externos carga tu sitio y construir una política CSP a medida. Es iterativo, no dramático.

¿Qué hago si activé HSTS y ya no puedo entrar a mi sitio?

Respirá: HSTS no borra ni daña nada, solo le ordena al navegador usar únicamente HTTPS durante el plazo que definiste. La solución rápida es arreglar el certificado SSL para que HTTPS vuelva a responder bien. Mientras tanto, en Chrome podés eliminar la política del dominio desde chrome://net-internals/#hsts con la opción Delete domain security policies y recuperar el acceso en esa máquina.

¿Agregar cabeceras de seguridad hace más lento mi WordPress?

No: cada cabecera suma apenas unas decenas de bytes a la respuesta HTTP, un impacto imperceptible incluso en sitios con tráfico alto. Además viajan junto con la respuesta del servidor, así que no agregan procesos extra; servidas desde .htaccess ni siquiera pasan por PHP. Una CSP muy extensa exige algo más de trabajo al navegador, pero sigue siendo despreciable frente a cualquier plugin pesado.

¿Cómo saco una nota A+ en securityheaders.com con mi WordPress?

El scanner premia la cobertura completa: enviá las seis cabeceras de esta guía y sumá la directiva preload a tu HSTS, que es el requisito diferencial para llegar a A+. Ojo antes de dar ese paso: preload te mete en una lista permanente de navegadores y salir después toma meses, así que hacelo solo cuando todos tus subdominios tengan HTTPS estable.

Fuentes

• LiteSpeed Technologies — Documentación oficial de security headers en LiteSpeed Web Server
• MDN Web Docs — Referencia técnica de X-Frame-Options y su relación con frame-ancestors
• Really Simple SSL — Guía de implementación de Content Security Policy en WordPress
• Malcare — X-Frame-Options en WordPress: análisis de valores y deprecación de ALLOW-FROM
• Melapress — Content Security Policy para WordPress: directivas y mejores prácticas
• Malcare — HSTS en WordPress: implementación y riesgos de activación sin SSL
• Patchstack — Guía de security headers para WordPress
• Security Headers — Analizador gratuito de cabeceras HTTP (A+ a F)