Cabeceras de seguridad en WordPress en 2026: CSP, HSTS, Trusted Types y reporting

Las cabeceras de seguridad son una capa defensiva útil porque permiten que el navegador aplique restricciones antes de ejecutar o cargar determinados recursos. Sin embargo, en WordPress rara vez existe una configuración universal. Una instalación puede incluir Elementor, WooCommerce, Google Tag Manager, pasarelas de pago, vídeos, fuentes externas, gestores de consentimiento, chat y scripts de plugins. Una política copiada desde un tutorial puede bloquear funciones críticas o terminar relajándose tanto que apenas aporte valor. En 2026 hay además dos cambios relevantes en la plataforma web: la directiva CSP require-trusted-types-for alcanzó estado Baseline en febrero y la Reporting API alcanzó Baseline en marzo, ampliando las posibilidades de reducir ciertos sinks DOM XSS y recoger telemetría de políticas en navegadores modernos. El enfoque correcto es medir, probar y endurecer gradualmente.

1. Antes de añadir cabeceras, crea una línea base real

La primera pregunta no es qué cabeceras recomienda una lista, sino cuáles recibe realmente el navegador en las páginas críticas. Un CDN puede sobrescribir al servidor, un plugin puede añadir valores duplicados y un proxy inverso puede aplicar reglas diferentes por entorno. Conviene comprobar home, login, carrito, checkout, cuenta, formularios y cualquier ruta con comportamiento distinto.

Security Inspector puede detectar de forma pasiva la presencia o ausencia de señales públicas y ayudar a priorizar. Esa observación no sustituye una revisión interna de configuración, pero evita empezar a ciegas. Guardar una línea base también permite demostrar qué cambió después de cada ajuste.

• Comprobar varias rutas, no solo la portada.
• Registrar valores duplicados o contradictorios.
• Identificar qué capa añade cada cabecera.

2. HTTPS primero; HSTS después

HSTS indica al navegador que debe utilizar HTTPS para futuras conexiones al dominio durante el periodo configurado. Es una protección útil, pero presupone que HTTPS está bien resuelto. Antes de ampliar max-age, includeSubDomains o preload hay que comprobar certificados, redirecciones y subdominios.

MDN recuerda que la política solo se aprende a través de una respuesta HTTPS y que includeSubDomains extiende el comportamiento a subdominios. En organizaciones con herramientas heredadas, paneles o servicios en subdominios, activar un alcance demasiado amplio puede causar indisponibilidad. HSTS debe tratarse como una decisión de infraestructura, no como una puntuación que hay que maximizar.

3. CSP controla orígenes, pero necesita inventario

Content-Security-Policy permite definir qué fuentes pueden aportar scripts, estilos, imágenes, fuentes, frames, conexiones y otros recursos. OWASP la considera una capa importante para ayudar a mitigar XSS y ataques de inyección. En WordPress, el desafío es conocer el ecosistema real de recursos antes de bloquear.

Un sitio puede cargar scripts de analítica, consentimiento, mapas, chat, vídeos, pasarelas, widgets y plugins. Si esos orígenes no se inventarían, la primera CSP suele terminar llena de comodines o excepciones amplias. La política mejora cuando primero se retiran dependencias innecesarias y después se permite únicamente lo que el sitio todavía necesita.

4. Usa CSP Report-Only para aprender antes de bloquear

Content-Security-Policy-Report-Only permite observar qué habría bloqueado una política sin aplicar el bloqueo. Esto es especialmente útil en WooCommerce porque una violación aparentemente secundaria puede corresponder a un método de pago, un flujo de autenticación o un script de consentimiento.

La fase de observación debe tener una duración suficiente para cubrir tráfico y escenarios reales, pero no convertirse en un estado permanente. Los informes se agrupan por directiva, origen, ruta y frecuencia; después el equipo decide si el recurso es legítimo, si puede eliminarse o si necesita una excepción más precisa. El resultado debería ser una política más pequeña, no una allowlist infinita.

5. frame-ancestors es preferible a depender solo de X-Frame-Options

La directiva frame-ancestors de CSP permite controlar qué sitios pueden embeber una página en frames. Es relevante para reducir escenarios de clickjacking y ofrece más flexibilidad que la cabecera histórica X-Frame-Options. En WordPress debe revisarse especialmente si existen páginas legítimamente embebidas en portales, herramientas internas o integraciones.

No conviene aplicar DENY de forma mecánica si la organización utiliza iframes autorizados. La política debe reflejar los orígenes realmente necesarios y probarse en los flujos donde el contenido se integra dentro de otro sistema.

6. X-Content-Type-Options sigue siendo simple y útil

X-Content-Type-Options con nosniff indica al navegador que respete el Content-Type declarado en determinados contextos y evita MIME sniffing. Comparada con CSP, es una medida sencilla y con poca complejidad operativa cuando los tipos de contenido del servidor están bien configurados.

Aun así, si aparecen errores después de activarla, el problema puede revelar respuestas con Content-Type incorrecto. Corregir el tipo real suele ser mejor que retirar la protección para ocultar el síntoma.

7. Referrer-Policy controla cuánto contexto sale del sitio

Referrer-Policy permite limitar la información de la URL que el navegador envía como Referer al navegar hacia otros orígenes. En sitios que incluyen parámetros, rutas internas o contenido sensible, reducir esa exposición puede ser útil. La política debe coordinarse con analítica y atribución para entender el efecto sobre medición.

No existe un único valor correcto para todas las organizaciones. La configuración debe equilibrar privacidad, seguridad y necesidades legítimas de analítica, evitando enviar más información de la necesaria a terceros.

8. Permissions-Policy: restringe capacidades, pero revisa compatibilidad

Permissions-Policy permite controlar qué funcionalidades del navegador están disponibles para la página y sus iframes, por ejemplo cámara, micrófono o ciertas APIs. MDN sigue marcándola con disponibilidad limitada para algunas capacidades, por lo que la política debe diseñarse con la tabla de compatibilidad delante.

En una web corporativa que no usa cámara o micrófono puede ser razonable restringir esas funciones. En cambio, una web con videollamadas, captura de documentos o componentes embebidos puede necesitarlas. La regla útil es negar capacidades que el producto no utiliza, no copiar una lista extrema sin comprenderla.

9. Trusted Types ganó relevancia práctica en 2026

MDN marca require-trusted-types-for como Baseline 2026 desde febrero. Esta directiva CSP puede exigir valores creados mediante políticas Trusted Types en determinados sinks DOM, reduciendo la superficie para ciertas variantes de DOM XSS. No es una cabecera que deba activarse sin preparación porque JavaScript propio o de terceros puede depender de asignaciones de cadenas a APIs afectadas.

En WordPress, plugins, builders y scripts externos hacen que la compatibilidad sea especialmente importante. Un equipo puede empezar inventariando sinks y bibliotecas, probar en staging y desplegar de forma progresiva. Trusted Types complementa, no sustituye, sanitización, escaping, actualizaciones y una CSP bien diseñada.

10. Reporting API: telemetría útil si se gestiona con límites

La Reporting API alcanzó estado Baseline 2026 en marzo y ofrece un mecanismo común para recibir informes generados por funciones como CSP y otras políticas. Esto puede convertir violaciones del navegador en señales operativas que el equipo agrupa y revisa.

La telemetría también necesita gobierno. Los endpoints deben estar protegidos, los informes deben agregarse para evitar ruido y la retención debe limitarse a lo necesario. En sitios de alto tráfico, almacenar cada evento sin deduplicación puede crear costes y ocultar los problemas importantes.

11. WooCommerce: prueba siempre checkout y pagos

WooCommerce suele depender de scripts y frames externos para pagos, fraude, wallets, consentimiento o analítica. Una CSP nueva puede permitir la home y romper únicamente el checkout, lo que convierte una mejora de seguridad en un incidente comercial. Por eso las pruebas deben cubrir métodos de pago reales y estados alternativos.

El inventario debe relacionar cada origen externo con un propietario y una finalidad. Si una pasarela deja de utilizarse, sus dominios pueden retirarse de la política. Esta disciplina evita que CSP acumule excepciones durante años.

12. Las cabeceras no sustituyen mantener WordPress actualizado

El 22 de septiembre de 2026 WordPress publicó 7.1.2 para corregir una vulnerabilidad crítica y recomendó actualizar inmediatamente. Días antes, 7.1.1 había incluido múltiples correcciones de seguridad. Estos avisos demuestran que ninguna combinación de cabeceras compensa un core vulnerable o un plugin desactualizado.

Las cabeceras deben formar parte de una estrategia más amplia: actualizaciones, mínimo privilegio, copias verificadas, control de plugins, logs, monitorización, HTTPS y revisión de terceros. Security Inspector ayuda a observar la postura pública; el hardening interno completa lo que no puede determinarse desde fuera.