Cabeceras HTTP de seguridad en WordPress (2026)

Actualizado el 25/08/2026: incorporamos la guía de hardening 2026 con el set ampliado de cabeceras (sumamos Permissions-Policy y desarrollamos X-Content-Type-Options y Referrer-Policy), la tabla de riesgo por cabecera, el error 153 de YouTube bajo CSP y herramientas de auditoría como CSP Evaluator de Google.

En pocas palabras: Las cabeceras HTTP de seguridad en WordPress se configuran en el servidor vía .htaccess, nginx.conf o wp-config.php, y cubren cuatro frentes: Content-Security-Policy contra XSS, Strict-Transport-Security para forzar HTTPS, X-Frame-Options contra clickjacking y Referrer-Policy. Bien implementadas, alcanzan calificación A+ en securityheaders.com.

Los headers de seguridad HTTP para WordPress son instrucciones que el servidor agrega a cada respuesta para limitar lo que el navegador puede hacer con tu sitio: qué scripts ejecuta, si tu página puede mostrarse dentro de un iframe ajeno y si debe conectarse siempre por HTTPS. Se configuran vía .htaccess, nginx.conf, wp-config.php o plugins, se apoyan en cabeceras como Content-Security-Policy, Strict-Transport-Security y X-Frame-Options, y están documentadas por MDN Web Docs y por el proyecto Secure Headers de OWASP.

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

Son metadatos que viajan en la respuesta HTTP, antes del HTML, y le dicen al navegador cómo comportarse con tu contenido. Importan en WordPress por un motivo simple: el CMS mueve más del 40% de la web según W3Techs, y su ecosistema de plugins mete scripts de terceros en millones de sitios. Si nadie define reglas, cualquier script inyectado corre sin restricciones.

La diferencia clave: el código de tu tema vive en el servidor, pero la ejecución pasa en el navegador del visitante. Las cabeceras son el contrato entre ambos. Sin ese contrato, estás expuesto a XSS (scripts ajenos corriendo en tu dominio), clickjacking (tu página disfrazada dentro de un iframe) y downgrades a HTTP aunque tengas certificado instalado.

¿La buena noticia? Todo esto se resuelve con unas líneas en el servidor. (Que no es poco, viniendo del mundo WordPress, donde cada arreglo suele costar tres plugins y un sacrificio.)

¿Cómo funciona Content-Security-Policy en un sitio WordPress?

Ponele que tenés una tienda en WooCommerce y un proveedor de reservas carga su widget desde su propio dominio. Un día activás una CSP copiada de un tutorial, con default-src ‘self’, y el widget desaparece. ¿Qué pasó? La política le dijo al navegador que solo aceptara recursos de tu dominio, y el widget venía de otro. Eso es exactamente lo que hace la CSP: dibuja la lista blanca de todo lo que tu página puede cargar.

• default-src: la política base para todos los recursos; si no definís algo más específico, rige esa.
• script-src: de dónde puede venir JavaScript. Acá se juega la mayor parte de la protección contra XSS.
• style-src: ídem para CSS. Ojo, porque los constructores visuales inyectan estilos inline a diario.
• img-src: imágenes, incluyendo data: si usás SVG embebidos.
• frame-src: qué iframes podés mostrar: YouTube, pasarelas de pago, mapas.
• frame-ancestors: quién puede incrustarte a vos, el reemplazo moderno de X-Frame-Options.

Dos ejemplos reales. Un blog con GA4 necesita script-src ‘self’ https://www.googletagmanager.com y su correspondiente connect-src para los hits. Una tienda con Mercado Pago suma sdk.mercadopago.com en script-src y frame-src; con Stripe, js.stripe.com. Cada servicio externo que cargues es un origen que tenés que anotar. Te puede servir nuestra cobertura de autenticación sin contraseñas usando passkeys.

Los conflictos conocidos en WordPress vienen por el lado de Elementor (montañas de CSS inline que exigen style-src ‘unsafe-inline’) y de reCAPTCHA, que reparte peticiones entre google.com y gstatic en varios frentes. Lo ideal sería firmar cada script con nonces o hashes, pero WordPress no firma sus scripts inline por defecto, así que muchos terminan con unsafe-inline global. Funciona, pero es una CSP «de adorno»: levanta la barrera sin cerrar la puerta. El análisis de CSP en WordPress de MalCare detalla bien ese compromiso.

Antes de activar nada en firme, tenés Content-Security-Policy-Report-Only: misma sintaxis, pero no bloquea nada, solo reporta violaciones en la consola. ¿Y qué pasó cuando alguien lo saltó y mandó la CSP directa a producción? Exacto: el slider del home dejó de existir. Usá Report-Only una semana, siempre. La implementación de CSP paso a paso de Really Simple SSL sigue justamente ese camino.

¿Para qué sirve HSTS en WordPress y cómo se activa?

Strict-Transport-Security es una cabecera que le ordena al navegador usar solo HTTPS con tu dominio durante el tiempo que indiques en max-age, medido en segundos. Una vez recibida, el navegador ni siquiera intenta HTTP: redirige internamente antes de tocar la red. Según la referencia de MDN, es la defensa estándar contra downgrade attacks y robo de cookies en redes abiertas.

• max-age: cuántos segundos dura la política. 31536000 equivale a un año, el valor mínimo que exige la lista de preload de Chromium.
• includeSubDomains: extiende la regla a todos los subdominios. Si blog.tudominio.com todavía navega en HTTP, se rompe.
• preload: habilita el envío a la lista precargada de Chrome, Firefox y Edge, para que hasta el primer visitante evite HTTP.

Ojo con esto: HSTS es difícil de revertir. Suena exagerado, no lo es. El navegador guarda la política en caché local; si mañana quitás la cabecera, los visitantes que ya la recibieron siguen forzando HTTPS hasta cumplir el max-age. Y si enviaste la versión con preload, salir de la lista de Chromium toma meses.

El camino prudente: verificá que el certificado cubra el dominio y todos los subdominios, arrancá con un max-age chico (300 segundos), mirá que nada se rompa, y recién ahí subí a un año. Como meta final, OWASP sugiere llegar a 63072000 —dos años completos— una vez que el sitio acumula meses de operación estable con HTTPS; el tutorial de headers de seguridad de HostMyCode para Apache y Nginx documenta esa escalera de valores. La cabecera protege al visitante recurrente; la lista de preload protege también al primero. Son cosas distintas, y conviene activarlas en ese orden.

X-Frame-Options vs frame-ancestors: ¿cuál conviene contra el clickjacking?

Contra clickjacking, hoy conviene frame-ancestors dentro de la CSP, porque permite listar orígenes específicos; X-Frame-Options sobrevive como cabecera de compatibilidad con solo dos valores útiles. El ataque es simple: el atacante incrusta tu página en un iframe transparente sobre un señuelo, y el usuario clickea creyendo que aprieta otro botón. Clásico: aprobar un pago o borrar una cuenta sin enterarse.

Matiz que evita dolores de cabeza: X-Frame-Options protege tus páginas de ser incrustadas; no controla qué iframes vos mostrás (eso es frame-src). Si incrustás videos de YouTube, esta cabecera no te afecta. Y si tu checkout de WooCommerce vive en un subdominio distinto, SAMEORIGIN lo va a bloquear: en ese caso usá frame-ancestors con ambos orígenes. Tema relacionado: proteger la base de datos MySQL.

¿Qué headers de seguridad HTTP para WordPress pide el hardening 2026?

El estándar de hardening 2026 se cumple con siete cabeceras: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (o frame-ancestors), X-Content-Type-Options, Referrer-Policy, Permissions-Policy y la eliminación de todo header que exponga tecnología. Las tres primeras ya las viste arriba; el resto es lo que las guías de referencia —como el repaso de headers de seguridad de CoderCops para 2026— dejaron de tratar como extras y pidieron como base mínima. La buena parte: estas se activan sin proceso gradual, en una sola pasada.

Permissions-Policy es la más nueva del grupo y reemplazó a Feature-Policy. Ordena al navegador qué funciones puede usar tu página: cámara, micrófono, geolocalización, acelerómetro. Un valor como camera=(), microphone=(), geolocation=(self) niega cámara y micro a cualquiera —incluido un script malicioso inyectado— y deja la geolocalización solo para tu origen. En WordPress el caso de uso es concreto: los formularios con campos de ubicación siguen andando, pero un payload XSS no puede pedir permisos sensibles al visitante. Sobre eso hablamos en endurecer todo tu WordPress con Patchstack.

X-Content-Type-Options: nosniff cierra otra puerta silenciosa. Le prohíbe al navegador adivinar el tipo de archivo cuando el servidor ya declaró uno. Sin esta cabecera, un archivo subido a tu biblioteca de medios puede terminar interpretándose como JavaScript si alguien lo solicita desde un contexto distinto. No conozco un caso documentado de rotura por activarla: se pone y se olvida.

Referrer-Policy define cuánta procedencia viaja cuando alguien sale de tu sitio. El default histórico era no-referrer-when-downgrade; los navegadores actuales usan strict-origin-when-cross-origin, que envía solo el dominio entre sitios distintos y nada hacia conexiones sin cifrar. Mi consejo: declarala explícito en vez de depender del default del navegador. Único efecto colateral: alguna plataforma de analítica pierde la ruta exacta de origen.

X-XSS-Protection, en cambio, quedó en el cajón. Era el filtro XSS interno de IE, Chrome y Safari; Chrome lo retiró en 2020 porque generaba más falsos positivos que defensas reales. Algunos escáneres siguen listándolo, así que enviarlo no molesta. Pero no te engañes: hoy la protección XSS de verdad vive en la CSP.

Queda el talón de Aquiles de toda CSP en WordPress: los scripts inline. La salida limpia son los nonces —un token aleatorio por respuesta, inyectado en la cabecera y en cada etiqueta script— o los hashes fijos para código que nunca cambia. La guía de security headers de Patchstack recorre esa implementación con detalle WordPress. Ahora bien, hay que ser honestos: con page builders y snippets de marketing por todos lados, sostener nonces puede convertirse en tarea permanente. Mi criterio: nonces en script-src si tu equipo puede mantenerlos; si no, ‘unsafe-inline’ acotado a style-src se acepta, siempre que script-src quede cerrada con lista de dominios. Una CSP perfecta que nadie mantiene pierde contra una buena que sigue vigente seis meses después.

Último ítem, el que casi todos omiten: dejar de contar cómo estás armado. Los headers Server y X-Powered-By publican versiones de Apache, Nginx y PHP, información valiosa para quien busca exploits conocidos. Dos líneas por servidor lo resuelven:

# Apache (httpd.conf o virtualhost, no funciona en .htaccess)
ServerTokens Prod
ServerSignature Off
<IfModule mod_headers.c>
 Header unset X-Powered-By
</IfModule>

# Nginx (bloque http o server)
server_tokens off;
fastcgi_hide_header X-Powered-By;

Para cerrar el mapa completo, esta tabla resume las siete cabeceras con su riesgo de rotura y el valor que recomiendo de acá en adelante:

Leída la tabla, el plan sale solo: las cinco de riesgo bajo o nulo entran hoy mismo en una sola edición del .htaccess. CSP y HSTS merecen su proceso escalonado, que ya describimos en sus secciones. Nada más, nada menos.

¿Cómo agregar cabeceras de seguridad en WordPress sin plugins?

Tenés cuatro caminos, y la elección depende de tu acceso al servidor: .htaccess en Apache, nginx.conf en Nginx, wp-config.php si querés que la configuración viaje con el sitio, o el hook send_headers desde functions.php. Todos llegan al mismo resultado; ninguno requiere plugin. Ya lo cubrimos antes en proteger el acceso con passkeys y 2FA.

Opción 1: .htaccess (Apache). La más común en hostings compartidos. En un panel con cPanel, como los planes de DonWeb, entrás al Administrador de archivos, editás el .htaccess de la raíz y listo; estos entornos suelen traer mod_headers activo.

<IfModule mod_headers.c>
 Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
 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 Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-src 'self' https://www.youtube-nocookie.com"
</IfModule>

Opción 2: nginx.conf (Nginx). Si administrás un VPS, agregá las cabeceras en el bloque server, con always al final para que se envíen también en respuestas de error. Trampa clásica de Nginx: si declarás cualquier add_header dentro de un location, el servidor deja de heredar los del bloque superior. Medio que te deja las cabeceras a medias sin avisar.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;

Opción 3: wp-config.php. Pegá llamadas a header() al inicio del archivo, debajo de la apertura de PHP. Ventaja: la configuración viaja con el sitio en migraciones y no depende de que el hosting tenga mod_headers expuesto.

header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Frame-Options: SAMEORIGIN");
header("X-Content-Type-Options: nosniff");

Opción 4: functions.php con el hook send_headers. Útil si solo querés tocar el tema, aunque conviene hacerlo en un child theme para no perderlo con la próxima actualización.

add_action("send_headers", function () {
 header("X-Frame-Options: SAMEORIGIN");
 header("X-Content-Type-Options: nosniff");
});

Editás el .htaccess, lo subís por FTP, purgás la caché del CDN, probás en una ventana de incógnito, ves la cabecera nueva en curl, respirás tranquilo, y dos horas después un cliente te avisa que el calendario de reservas desapareció porque la CSP le bloqueó el dominio del proveedor que nadie tenía anotado en ningún lado. Por eso: un cambio por vez, y verificación después de cada uno.

¿Orden de carga? El servidor gana. Si Apache ya manda la cabecera, un plugin la va a duplicar o pisar. Elegí un solo lugar, y si usás Cloudflare o el CDN del hosting, purgá caché tras cada cambio; si no, vas a auditar headers viejos toda la tarde. En configurar el firewall de Sucuri profundizamos sobre esto.

¿Qué plugins sirven para gestionar cabeceras HTTP en WordPress?

Pocos plugins hacen bien esta tarea, y varios de los famosos ni la intentan. Mi criterio después de años dando soporte: si tenés acceso al servidor, manejá las cabeceras ahí y ahorráte un plugin; si no, buscá uno dedicado y verificá con curl después de activarlo.

Según el tipo de sitio, mi recomendación cambia:

• Blog personal: .htaccess y listo; un plugin dedicado solo si tu hosting no te da acceso a archivos.
• Tienda WooCommerce: armá la CSP en Report-Only una semana, revisá la consola, y después activala en firme; las pasarelas suman dominios todo el tiempo.
• Publisher con muchos embeds: frame-ancestors amplio y auditoría mensual, porque cada socio de contenido nuevo es un origen nuevo.

Los botones de «blindar todo» que traen algunos packs de seguridad me generan desconfianza: aplican presets genéricos con unsafe-inline en todas las directivas, y eso es una falsa sensación de blindaje. Menos magia, más control.

¿Cómo verificar que tus cabeceras HTTP están activas?

Tres herramientas gratuitas cubren todo: securityheaders.com para el puntaje, curl para el dato crudo y DevTools para inspeccionar respuesta por respuesta. Entre las tres te sacás cualquier duda en cinco minutos. Esto se conecta con lo que analizamos en blindar también tu base de datos MySQL.

• SecurityHeaders.com: escribís tu dominio y te da una nota de A+ a F con el detalle por cabecera. Fijate que el informe marca exactamente qué falta para subir de letra.
• curl -I https://tudominio.com: desde la terminal, te muestra los headers tal como salen del servidor. Sumale grep -i security para filtrar el ruido.
• DevTools (F12, pestaña Network): recargá, cliqueá el documento principal y mirá Response Headers. Ideal para ver qué llega después de pasar por el CDN.
• chrome://net-internals/#hsts: consultá si tu dominio ya tiene política HSTS cacheada en ese navegador. Poco conocido, muy útil cuando HSTS se vuelve contra vos.

Novedad de este ciclo: CSP Evaluator de Google audita la política como texto. Pegás tu string de CSP y la herramienta señala directivas débiles o combinaciones riesgosas, sin necesidad de tocar el servidor. Si preferís arrancar de una plantilla, los generadores con presets por tipo de sitio —WooCommerce, Elementor, blog— entregan la línea inicial lista para adaptar; la guía de security headers de OffSecKit compara esas opciones junto con DomSignal y otros verificadores.

Acordate que tu entorno local puede mostrar otras cabeceras que producción: el CDN o el WAF del medio agrega, quita o cachea cosas. Verificá siempre contra el dominio público. Cuando la CSP bloquea algo, la consola lo grita con mensajes «Refused to load… violates Content-Security-Policy», así que también la consola es una herramienta de verificación. Mozilla mantuvo por años su propio escáner (Observatory); si querés sumarlo a la rutina, chequeá primero que siga operativo.

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

No en la práctica. Un conjunto completo de cabeceras pesa unos cientos de bytes por respuesta, imperceptible frente a una sola imagen sin optimizar. Al revés: HTTPS es factor de ranking confirmado por Google hace años, y HSTS garantiza que nadie caiga en la versión insegura de tu sitio.

Lo único que puede lastimar tu SEO es una CSP mal armada que bloquee recursos: si el CSS principal no carga, la página se ve rota, el usuario rebota y ahí sí perdés posiciones. Por eso existe Report-Only, y por eso se prueba antes de activar. Cubrimos ese tema en detalle en activar la verificación en dos pasos.

Errores comunes al configurar cabeceras en WordPress (y cómo arreglarlos)

¿Por qué mi WordPress se rompe al activar Content-Security-Policy?

Síntoma típico: el sitio carga a medias, la consola acumula mensajes de violación de CSP y el carrusel no arranca. Casi siempre es un recurso externo que no anotaste en script-src o style-src. Solución: volvé a Report-Only, colectá las violaciones durante una semana, agregá esos orígenes y recién entonces activá la política en firme. Evitá el atajo de unsafe-inline global, que te deja abierta justo la puerta que querías cerrar.

¿Por qué mi sitio queda inaccesible después de activar HSTS?

Activaste HSTS con includeSubDomains y algún subdominio seguía en HTTP, o tu certificado no cubre todo. El navegador ahora exige HTTPS donde no lo hay, y el visitante ve error. Primero arreglá el certificado (uno wildcard cubre *.tudominio.com). El afectado puede limpiar la política local desde chrome://net-internals/#hsts, aunque eso solo vale para su navegador. Lección: max-age chico al principio, y subir de a poco.

¿Por qué securityheaders.com muestra cabeceras viejas que ya cambié?

Caché. El CDN guardó la respuesta anterior con sus headers y te la sigue sirviendo. Purgá la caché completa (no solo la de páginas) y volvé a probar. Si persiste, consultá el origen directamente, saltándote el CDN, para confirmar que el servidor ya manda lo nuevo. El problema casi nunca es tu configuración; es la capa de arriba.

¿Por qué un plugin pisa o duplica mis cabeceras?

Algunos plugins de seguridad envían sus propias cabeceras con prioridades distintas, y terminás con X-Frame-Options repetido o contradictorio. El resultado es impredecible según el navegador. Regla: un solo dueño por cabecera. Auditá con curl después de activar cada plugin nuevo y desactivá el que pelee con tu configuración de servidor.

¿Por qué los videos de YouTube tiran el error 153 cuando activás CSP?

Porque el reproductor no carga solo desde youtube-nocookie.com. Detrás de cada embed hay pedidos a www.youtube.com, a i.ytimg.com y a los servidores de video de Google; si tu frame-src o script-src no los incluye, el player arranca cortado y muestra el error 153 en lugar del clip. Abrí la consola, anotá cada dominio que aparezca en las violaciones y agregalos a frame-src. Es el mismo síntoma de cualquier recurso bloqueado, solo que YouTube lo disfraza con su propio código de error. Más contexto en un firewall como Sucuri bien configurado.

Cabeceras HTTP en WordPress: qué está confirmado y qué depende de tu entorno

Lo confirmado, según la documentación oficial:

• La sintaxis y las directivas: están documentadas en MDN y en el proyecto Secure Headers de OWASP; no cambian según tu hosting.
• ALLOW-FROM está muerto: los navegadores lo retiraron; para permitir orígenes específicos, frame-ancestors.
• Preload exige compromiso: un año de max-age, includeSubDomains y HTTPS en todos los subdominios, según los requisitos públicos de la lista de Chromium.

Lo que depende de tu entorno:

• Si podés editar .htaccess o nginx.conf: la mayoría de los hostings con cPanel lo permite, pero algunos planes administrados lo restringen.
• Cómo trata las cabeceras tu CDN o WAF: puede agregar, quitar o cachear; hay que auditarlo caso por caso.
• Llegar a A+: depende de los servicios externos que cargues; con muchos terceros, una A zafa perfecto y es un resultado honesto.

Preguntas Frecuentes

¿Qué son las cabeceras HTTP de seguridad en WordPress?

Son instrucciones que el servidor incluye en cada respuesta HTTP para restringir el comportamiento del navegador: qué scripts puede cargar, si la página puede mostrarse en un iframe ajeno y si debe usar siempre HTTPS. En WordPress se configuran en el servidor (.htaccess, nginx.conf, wp-config.php) o con plugins dedicados, y las principales son CSP, HSTS y X-Frame-Options.

¿Qué headers de seguridad HTTP necesita WordPress para hardening 2026?

Siete: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options o frame-ancestors, X-Content-Type-Options con nosniff, Referrer-Policy en strict-origin-when-cross-origin, Permissions-Policy y la supresión de Server y X-Powered-By. Con ese set completo llegás a A+ en securityheaders.com. Solo CSP y HSTS requieren proceso gradual; las demás se activan de una.

¿Cuál es la diferencia entre Content-Security-Policy y Content-Security-Policy-Report-Only?

La primera aplica la política y bloquea cualquier recurso fuera de la lista; la segunda usa la misma sintaxis pero solo registra violaciones en la consola, sin bloquear nada. Se usan en secuencia: enviás Report-Only durante una o dos semanas, colectás los dominios que disparan violaciones, y recién después pasás a la cabecera definitiva. Mismo contenido, efecto opuesto.

¿Cómo implemento CSP en WordPress sin romper el sitio?

Arrancá con Content-Security-Policy-Report-Only, que registra violaciones sin bloquear nada, y revisá la consola del navegador durante unos días. Con el inventario de dominios en mano, escribí la política definitiva con script-src, style-src y frame-src, y activala. Probá siempre en staging antes de producción.

¿Cómo activo HSTS en WordPress de forma segura?

Primero confirmá que todo el sitio y los subdominios funcionan con certificado válido. Después agregá la cabecera Strict-Transport-Security con un max-age corto (300 segundos), verificá que nada se rompa y subilo de a poco hasta 31536000. Recién cuando estés seguro, considerá includeSubDomains y preload, porque revertirlos toma meses.

¿Qué plugin uso para agregar cabeceras de seguridad en WordPress?

Si tu hosting te da acceso a archivos, ninguno: editá el .htaccess directamente, que es más rápido y tiene menos puntos de falla. Si necesitás interfaz gráfica, los plugins dedicados de cabeceras HTTP cumplen, y Really Simple SSL suma un módulo de headers en su versión Pro. No esperes esta función de plugins de caché o firewall genéricos.

¿Cómo verifico que mis cabeceras HTTP están activas?

Entrá a securityheaders.com, poné tu dominio y mirá la nota con el detalle por cabecera. Para el dato crudo, corré curl -I https://tudominio.com en la terminal, o abrí DevTools, sección Network, y revisá los Response Headers del documento principal. Para auditar la política de CSP antes de subirla, usá CSP Evaluator de Google.

Conclusión

El tablero de headers de seguridad HTTP para WordPress se agrandó en 2026: ya no alcanza con CSP, HSTS y X-Frame-Options. El estándar completo suma X-Content-Type-Options, Referrer-Policy y Permissions-Policy, y exige además que tu servidor deje de publicar versiones de software. Lo que no cambió es el método: Report-Only antes de bloquear, max-age corto antes del año, verificación en securityheaders.com después de cada movimiento. Arrancá hoy por las cinco cabeceras de riesgo cero —una sola edición del .htaccess— y dejá la CSP madurando dos semanas en Report-Only. Desde ahí, auditá cada trimestre: cada plugin nuevo que instales puede traer un dominio externo que tu política todavía no conoce.

Fuentes

• WordPress Developer Resources – Hardening: guía oficial de endurecimiento de WordPress
• Patchstack – WordPress Security Headers: implementación de cabeceras y nonces en sitios WordPress
• Really Simple SSL – Implementing CSP on WordPress: proceso de migración desde Report-Only
• MalCare – Content Security Policy WordPress: análisis de directivas y conflictos con plugins
• MDN Web Docs – Strict-Transport-Security: sintaxis de max-age, includeSubDomains y preload