Las cabeceras HTTP permiten indicar al navegador cómo debe tratar determinados recursos y conexiones de una web. Bien configuradas, ayudan a reducir algunos riesgos relacionados con contenido incrustado, carga de recursos externos, origen de referencias y permisos del navegador.

Pero añadir una lista de cabeceras sin revisar cómo funciona la web puede romper analítica, vídeos, formularios, pagos, mapas o herramientas de terceros. La configuración debe ser gradual y debe validarse con el sitio real.

Estas son las cabeceras más habituales y una forma prudente de introducirlas en WordPress.

Las cabeceras no sustituyen al resto de la seguridad

Una cabecera no corrige un plugin vulnerable, una contraseña reutilizada, un servidor desactualizado ni una infección existente.

Antes de configurarlas conviene conocer:

  • Qué servidor web gestiona la instalación.
  • Si existe Cloudflare, un CDN o un proxy inverso.
  • Qué recursos carga la web desde otros dominios.
  • Qué servicios necesitan insertar contenido.
  • Qué formularios, pagos o integraciones están activos.
  • Qué navegadores y dispositivos utilizan los visitantes.
  • Si hay entornos de pruebas separados.

También hay que comprobar dónde se aplican las cabeceras. Una regla en el servidor de origen puede no tener efecto si el CDN la reemplaza, y una regla del CDN puede aplicarse a recursos que no pertenecen a WordPress.

1. Content-Security-Policy

Content-Security-Policy, conocida como CSP, permite definir desde qué orígenes puede cargar recursos el navegador.

Puede controlar, entre otros elementos:

  • Scripts.
  • Hojas de estilo.
  • Imágenes.
  • Fuentes.
  • Marcos incrustados.
  • Conexiones iniciadas desde JavaScript.
  • Objetos antiguos.
  • Formularios.

Una política restrictiva puede reducir el impacto de determinadas inyecciones, pero también puede bloquear partes legítimas de la web si no se conocen todos los orígenes utilizados.

Una política inicial debe partir de un inventario real. No conviene empezar copiando una CSP genérica encontrada en otro sitio.

2. Empieza con Report-Only

La directiva Content-Security-Policy-Report-Only permite observar infracciones sin bloquear todavía los recursos.

Es útil para descubrir:

  • Scripts externos que no estaban documentados.
  • Fuentes de analítica.
  • Servicios de pago.
  • Vídeos incrustados.
  • Herramientas de chat.
  • Recursos cargados por plugins.
  • Conexiones realizadas por formularios o aplicaciones.

Durante esta fase, registra los avisos y clasifica cada origen:

  • Necesario y autorizado.
  • Necesario, pero pendiente de configurar.
  • Antiguo y ya no utilizado.
  • Desconocido y pendiente de investigar.

No conviertas automáticamente todos los avisos en permisos. Un dominio desconocido puede ser una dependencia olvidada o una señal que necesita revisión.

3. Strict-Transport-Security

La cabecera Strict-Transport-Security, o HSTS, indica al navegador que debe utilizar HTTPS durante un periodo determinado.

Antes de activarla, comprueba:

  • Que todas las páginas funcionan por HTTPS.
  • Que no quedan recursos HTTP que deban cargarse.
  • Que los subdominios relevantes tienen HTTPS válido.
  • Que las redirecciones están configuradas correctamente.
  • Que el certificado se renueva sin interrupciones.

La opción includeSubDomains amplía el alcance a los subdominios. No debería activarse sin comprobarlos, porque un subdominio olvidado o sin certificado puede quedar inaccesible para los navegadores que respeten la política.

La inclusión en listas de precarga requiere todavía más cuidado. No es un interruptor para probar sin planificación y puede hacer que el navegador fuerce HTTPS incluso antes de recibir la cabecera.

4. X-Content-Type-Options

X-Content-Type-Options: nosniff evita que algunos navegadores intenten interpretar un recurso con un tipo distinto del declarado.

Suele ser una medida sencilla, pero puede revelar configuraciones incorrectas. Si una hoja de estilos, un script o una fuente se sirve con un tipo MIME equivocado, el navegador puede dejar de cargarlo al aplicar nosniff.

Después de activarla, comprueba la consola del navegador y la pestaña de red para localizar recursos rechazados.

5. Referrer-Policy

Referrer-Policy controla cuánta información de la URL de origen se envía al navegar hacia otra dirección.

Una opción habitual es strict-origin-when-cross-origin, que conserva más información dentro del mismo origen y limita el detalle cuando la petición cruza a otro dominio.

La política debe tener en cuenta:

  • Formularios externos.
  • Plataformas de pago.
  • Enlaces con parámetros sensibles.
  • Analítica.
  • Enlaces de afiliación.
  • Integraciones que esperan una referencia concreta.

No debería utilizarse como mecanismo para enviar secretos en la URL. La política reduce la exposición, pero no convierte en segura una URL que contiene credenciales o información privada.

6. Permissions-Policy

Permissions-Policy permite limitar funciones del navegador como cámara, micrófono, geolocalización o pantalla compartida.

Si la web no necesita una capacidad, es razonable restringirla. Si una funcionalidad sí la utiliza, hay que incluir el origen correcto y comprobar el flujo completo.

Antes de configurarla, revisa:

  • Formularios con cámara o micrófono.
  • Videollamadas.
  • Mapas y geolocalización.
  • Herramientas de soporte.
  • Integraciones incrustadas mediante iframe.
  • Funciones utilizadas solo en páginas concretas.

Una política demasiado amplia no aporta una limitación útil. Una política demasiado estricta puede romper una función que no se prueba durante la revisión de la portada.

7. Protección frente a framing

Una web puede indicar si permite ser cargada dentro de un iframe mediante Content-Security-Policy con frame-ancestors.

Cuando la web no necesita ser incrustada, una política que limite los orígenes autorizados puede ayudar a reducir ciertos escenarios de framing no deseado.

Antes de bloquearlo, comprueba si la instalación utiliza:

  • Pasarelas de pago.
  • Previsualizaciones.
  • Constructores visuales.
  • Formularios incrustados.
  • Widgets.
  • Integraciones con el panel de un proveedor.

No confundas esta protección con una solución completa contra el clickjacking en todos los navegadores y contextos. Hay que probar las páginas y los servicios que dependen de iframes.

8. Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy y Cross-Origin-Embedder-Policy

Estas cabeceras pueden modificar la relación entre documentos y recursos de distintos orígenes.

Son útiles en escenarios concretos, pero no deberían añadirse por defecto a cualquier WordPress. Pueden afectar a:

  • Recursos externos.
  • Ventanas abiertas desde la web.
  • Integraciones de pago.
  • Vídeos.
  • Herramientas de edición.
  • Scripts que esperan comunicación entre ventanas.

Si una aplicación necesita aislamiento entre orígenes o funciones avanzadas del navegador, hay que diseñar y validar la política con más detalle. Para una instalación normal, es preferible no añadirlas sin un motivo claro y pruebas suficientes.

9. Haz un inventario de recursos antes de bloquear

Antes de aplicar una CSP o una política de permisos, navega por las páginas importantes:

  • Portada.
  • Entradas y páginas.
  • Contacto.
  • Formularios.
  • Carrito y pago, si existe.
  • Área de usuario.
  • Buscador.
  • Vídeos y mapas.
  • Consentimiento de cookies.
  • Panel de administración, si procede.

Registra los dominios que aparecen en la consola y en la pestaña de red. No todos los recursos externos tienen que permitirse en todas las directivas, y algunas dependencias solo se cargan después de aceptar cookies o realizar una acción.

El inventario debe actualizarse cuando se instale un plugin o se cambie una integración.

10. Configura las cabeceras en una sola capa cuando sea posible

Las cabeceras pueden establecerse en el servidor web, en PHP, en WordPress, en un plugin, en Cloudflare o en otro proxy.

Si varias capas las añaden o reemplazan, el resultado puede ser difícil de interpretar. Revisa:

  • Qué capa las genera.
  • Si se duplican.
  • Si una capa sobrescribe a otra.
  • Si se aplican a respuestas de error.
  • Si afectan a archivos estáticos.
  • Si cambian entre HTTP y HTTPS.
  • Si el CDN sirve una versión cacheada.

Centralizar la configuración reduce las sorpresas. Si no es posible, documenta qué responsabilidad tiene cada capa.

11. Valida la respuesta real

No basta con revisar el archivo de configuración. Comprueba las cabeceras que recibe el navegador.

Valida:

  • Portada.
  • Páginas internas.
  • Respuestas de formularios.
  • Recursos estáticos.
  • Redirecciones.
  • Errores 404 y 500.
  • Respuestas servidas por el CDN.
  • Versión móvil.

Además de una herramienta de comprobación, utiliza las herramientas del navegador para revisar la consola y la pestaña de red. Una cabecera puede estar presente y, aun así, tener un valor que no coincide con lo que necesita la aplicación.

12. Introduce cambios de forma gradual

Una secuencia prudente puede ser:

1. Hacer una copia de la configuración actual. 2. Inventariar recursos y servicios. 3. Activar cabeceras de bajo riesgo. 4. Configurar la CSP en modo Report-Only. 5. Revisar infracciones reales. 6. Añadir o retirar orígenes justificadamente. 7. Probar formularios, pagos, vídeos y analítica. 8. Aplicar el bloqueo solo cuando el comportamiento sea conocido. 9. Revisar después de vaciar o actualizar las cachés. 10. Documentar la configuración final.

No pruebes una política restrictiva directamente durante una campaña, una migración o un cambio importante sin un plan de vuelta atrás.

Qué puede romperse al añadir cabeceras

Los problemas más habituales son:

  • Analítica que deja de registrar eventos.
  • Fuentes que no cargan.
  • Vídeos incrustados bloqueados.
  • Mapas que aparecen vacíos.
  • Formularios que no se envían.
  • Pasarelas de pago que no completan el flujo.
  • Constructores visuales que pierden funciones.
  • Chats o widgets que desaparecen.
  • Peticiones AJAX bloqueadas.
  • Recursos que siguen cargándose desde HTTP.

Cuando algo se rompe, no conviene eliminar todas las cabeceras sin conservar el error. Revisa qué directiva bloqueó el recurso y decide si el origen es necesario, si puede sustituirse o si la integración debe cambiarse.

Las cabeceras deben formar parte de una revisión más amplia

Las cabeceras de seguridad son una capa útil, pero no sustituyen a las actualizaciones, las copias verificadas, la revisión de usuarios, el control de permisos, la protección del hosting ni la detección de malware.

Su valor está en reducir comportamientos permitidos por el navegador y en hacer más explícita la política de la web. Para que funcionen bien, deben reflejar lo que la instalación realmente necesita.

Una política copiada sin inventario puede dar una falsa sensación de seguridad o romper funciones importantes. Una política revisada, probada y documentada es mucho más útil.