La seguridad de WordPress no termina en mantener el núcleo, el tema y los plugins actualizados. El navegador también puede recibir instrucciones que reduzcan determinados riesgos mediante cabeceras HTTP de seguridad. Bien configuradas, ayudan a limitar la carga de recursos, fuerzan HTTPS, reducen el MIME sniffing y controlan qué información se envía como referencia.
El matiz importante es que no existe una configuración universal que deba copiarse sin pruebas. Una política demasiado restrictiva puede romper formularios, analítica, fuentes, vídeos, iframes o scripts legítimos. Por eso conviene trabajar con inventario, pruebas y despliegue gradual.
Qué son las cabeceras HTTP de seguridad
Son campos incluidos en la respuesta que entrega el servidor. El navegador los interpreta antes o durante el renderizado de la página y aplica las reglas correspondientes. OWASP mantiene un proyecto específico sobre cabeceras seguras y recomienda utilizarlas como una capa adicional, no como sustituto de una aplicación bien mantenida.
En WordPress la configuración puede estar en el servidor web, un proxy, CDN, panel de hosting o una capa de aplicación. Antes de añadir nada, identifica dónde se generan actualmente las respuestas para evitar políticas duplicadas o contradictorias.
Content-Security-Policy: la cabecera más potente y delicada
Content-Security-Policy, o CSP, permite definir desde qué orígenes puede cargar una página scripts, estilos, imágenes, fuentes, frames y otros recursos. Su objetivo es reducir la superficie disponible para determinados ataques de inyección, especialmente cuando un recurso no autorizado intenta ejecutarse en el navegador.
El problema práctico en WordPress es que una web real suele depender de recursos propios y externos: Google Fonts, Analytics, Tag Manager, mapas, vídeos, pasarelas de pago, widgets, formularios o scripts de plugins. Si una directiva no contempla una dependencia legítima, el navegador puede bloquearla.
Por eso es preferible empezar con un inventario de recursos y, cuando sea posible, utilizar primero Content-Security-Policy-Report-Only. Este modo permite observar infracciones sin bloquear el contenido. Después se puede endurecer la política de forma progresiva.
HSTS: fuerza HTTPS en visitas futuras
Strict-Transport-Security (HSTS) indica al navegador que un dominio debe utilizarse únicamente mediante HTTPS durante un periodo determinado. MDN explica que el navegador recuerda esa decisión y actualiza intentos posteriores de acceso por HTTP.
Una cabecera habitual tiene esta forma:
Strict-Transport-Security: max-age=31536000Antes de añadir includeSubDomains o solicitar preload, verifica que todos los subdominios relevantes funcionan correctamente por HTTPS. Una mala decisión aquí puede dejar inaccesible un subdominio que todavía dependa de HTTP.
X-Content-Type-Options: evita el MIME sniffing
La directiva:
X-Content-Type-Options: nosniffindica al navegador que respete los tipos MIME declarados en Content-Type en lugar de intentar reinterpretarlos. OWASP y MDN la recomiendan como una medida sencilla, pero presupone que el servidor entrega correctamente los tipos de contenido de scripts, hojas de estilo y demás recursos.
Si después de activarla aparece un recurso bloqueado, no conviene quitar la cabecera sin más. Revisa primero si el servidor está enviando un Content-Type incorrecto.
Referrer-Policy: controla qué URL se comparte con otros sitios
Cuando un usuario sigue un enlace o el navegador solicita un recurso externo, puede enviarse información del origen mediante la cabecera Referer. Referrer-Policy permite limitar cuánto contexto se comparte.
Una política ampliamente compatible es:
Referrer-Policy: strict-origin-when-cross-originCon ella, las solicitudes dentro del mismo origen pueden conservar más información, mientras que hacia otros orígenes se reduce el dato enviado al origen del sitio. MDN la documenta como una opción equilibrada y hoy también coincide con el comportamiento predeterminado de navegadores modernos.
Protección frente a iframes: frame-ancestors y X-Frame-Options
Impedir que una página sea embebida por sitios no autorizados ayuda a reducir escenarios de clickjacking. OWASP recomienda priorizar la directiva frame-ancestors de CSP cuando sea posible. Para compatibilidad con implementaciones antiguas también puede encontrarse X-Frame-Options.
Una política demasiado agresiva puede afectar a herramientas legítimas que necesiten mostrar contenido embebido. Antes de bloquear todos los frames, revisa si existen integraciones de administración, pagos, soporte o contenido externo que dependan de ellos.
Permissions-Policy: limita funciones del navegador
Permissions-Policy permite decidir qué funciones del navegador pueden utilizarse, por ejemplo cámara, micrófono o geolocalización. En una web corporativa que no necesita esas capacidades, restringirlas puede reducir superficie innecesaria.
No conviene copiar una política extensa sin revisar dependencias. Un formulario con captura multimedia, un mapa o una herramienta de videollamada pueden necesitar permisos concretos.
Qué cabeceras no deberías añadir por inercia
Algunas cabeceras históricas siguen apareciendo en escáneres y tutoriales antiguos. Un ejemplo es X-XSS-Protection. OWASP recomienda no depender de ella y priorizar una CSP correctamente diseñada, porque los filtros XSS antiguos de ciertos navegadores pueden producir comportamientos no deseados.
La regla útil es sencilla: no persigas una puntuación de un escáner añadiendo cabeceras sin entender su efecto. La seguridad real importa más que completar una lista.
Cómo revisar las cabeceras actuales de una web WordPress
Puedes empezar desde el navegador, con curl o con herramientas de diagnóstico. Con curl:
curl -I https://ejemplo.com/Revisa al menos:
Strict-Transport-Security.Content-Security-Policyo su varianteReport-Only.X-Content-Type-Options.Referrer-Policy.Permissions-Policy.- Políticas de framing.
Haz la misma comprobación en páginas que carguen componentes distintos: inicio, contacto, formularios, blog, checkout si existe y páginas con vídeos o mapas.
Orden recomendado para implantar cambios
- Inventaría dependencias: scripts, fuentes, APIs, iframes, analítica y servicios externos.
- Localiza la capa correcta: servidor, proxy, CDN o configuración del hosting.
- Empieza por medidas de bajo riesgo: por ejemplo
nosniffy una política de referrer adecuada, siempre tras probar. - Prueba HSTS: confirma HTTPS correcto antes de ampliar a subdominios o preload.
- Diseña CSP con observación: utiliza Report-Only cuando el entorno lo permita y analiza violaciones.
- Valida funcionalidades: formularios, menús, fuentes, analítica, consentimiento, vídeos y recursos externos.
- Comprueba móvil y escritorio: una integración puede cargar recursos distintos según viewport.
- Documenta la configuración: deja claro dónde se gestiona cada cabecera y cómo revertirla.
Cabeceras de seguridad y mantenimiento WordPress
Las cabeceras forman parte de una estrategia más amplia. La actualización controlada de WordPress, las pruebas de restauración de copias, los permisos, el hosting y la supervisión siguen siendo piezas esenciales.
Si necesitas revisar una instalación existente, el servicio de mantenimiento WordPress puede incluir el diagnóstico de la capa técnica y la priorización de cambios. También puedes contarme qué entorno tienes y qué quieres proteger antes de aplicar una política que pueda afectar a producción.
