ES Cabeceras de seguridad web: cómo aplicarlas sin romper el sitio
Las cabeceras HTTP de seguridad deben implantarse después de inventariar cómo funciona la web y mediante un despliegue gradual. Copiar una configuración estricta de otra página puede bloquear pagos, formularios, fuentes, vídeos, analítica o incluso los estilos propios. El objetivo no es acumular cabeceras, sino reducir riesgos concretos sin interrumpir recorridos legítimos.
Una combinación habitual incluye HSTS para reforzar HTTPS, X-Content-Type-Options para evitar interpretaciones inesperadas de archivos, Referrer-Policy para limitar información de navegación y Content Security Policy (CSP) para controlar de dónde puede cargar recursos el navegador. Cada medida resuelve un problema distinto y necesita pruebas propias.
Antes de configurar: inventariar recursos y recorridos
La primera tarea no está en el servidor, sino en el inventario. Hay que localizar scripts, hojas de estilo, imágenes, fuentes, iframes, conexiones asíncronas y destinos de formularios. También deben anotarse los servicios que los proporcionan: pasarela de pago, vídeo, mapas, chat, analítica, gestor de consentimiento, CDN o herramientas de atención al cliente.
Ese inventario debe contrastarse con recorridos reales. No basta con abrir la portada: conviene enviar un formulario, aceptar y rechazar cookies, completar una compra de prueba, reproducir un vídeo, iniciar sesión y revisar las áreas privadas. Los entornos de desarrollo y producción pueden cargar dominios diferentes, por lo que la comprobación final siempre se hace en la infraestructura que recibirá la política.
También es útil registrar las cabeceras actuales y quién las establece. Pueden proceder del servidor web, una CDN, el alojamiento, una extensión del CMS o el código de la aplicación. Si varias capas escriben la misma cabecera, el resultado puede ser distinto del que muestra cada panel por separado.
HSTS: aplicar HTTPS con conocimiento de los subdominios
HTTP Strict Transport Security (HSTS) indica al navegador que acceda al dominio mediante HTTPS durante el periodo declarado. Ayuda a evitar conexiones posteriores por HTTP y redirecciones degradables, pero solo debe enviarse a través de una conexión segura.
Antes de añadir includeSubDomains, hay que confirmar que todos los subdominios activos —incluidos servicios antiguos, paneles y hosts menos visibles— funcionan correctamente con HTTPS. La opción preload requiere todavía más cautela: la inclusión en listas precargadas de navegadores tiene condiciones y una retirada no produce efectos inmediatos en todos los usuarios. Una duración corta durante la validación permite corregir errores antes de ampliar el compromiso.
Evitar que el navegador adivine el tipo de archivo
La cabecera X-Content-Type-Options: nosniff pide al navegador que respete el tipo MIME declarado para scripts y estilos. Es una protección sencilla, pero puede revelar archivos servidos con un Content-Type incorrecto. La solución no es quitar nosniff, sino corregir la respuesta del servidor y comprobar también recursos generados o almacenados por usuarios.
Eliminar cabeceras informativas como X-Powered-By reduce detalles innecesarios sobre la tecnología, aunque no convierte una aplicación vulnerable en segura. El nombre exacto de un servidor puede ocultarse, pero sus fallos siguen existiendo si no se actualiza o configura correctamente.
Limitar la información que viaja como referencia
Cuando una persona sigue un enlace o el navegador solicita un recurso externo, la cabecera Referer puede revelar la página de origen. Referrer-Policy permite limitar esa información. strict-origin-when-cross-origin es una base razonable y el valor predeterminado actual en navegadores, mientras que no-referrer elimina la referencia por completo.
La política más restrictiva no siempre es la más útil. Determinados informes, integraciones o controles antifraude pueden depender del origen. Antes de endurecerla conviene saber qué datos necesita realmente cada tercero y evitar que una URL incluya datos personales o secretos, con independencia de la cabecera.
CSP: empezar observando, no bloqueando
Content Security Policy define qué orígenes pueden proporcionar scripts, estilos, imágenes, fuentes, conexiones y otros contenidos. Bien planteada, reduce el impacto de inyecciones de código y carga de recursos no autorizados. No sustituye la validación de entradas ni la codificación de salidas: es una capa adicional cuando algo falla.
El despliegue prudente comienza con Content-Security-Policy-Report-Only. El navegador informa de incumplimientos sin bloquear los recursos. Durante esta fase se recorren páginas y funciones críticas, se revisan los avisos y se distingue entre dependencias legítimas, recursos obsoletos y cargas que no deberían existir.
Después se puede activar una política limitada y ampliarla por etapas. Algunas directivas requieren especial atención:
default-srcactúa como respaldo para categorías que no tienen una regla propia;script-srcystyle-srccontrolan código y estilos, donde los fragmentos insertados en línea suelen exigir nonces, hashes o una refactorización;connect-srcafecta a API, analítica y conexiones del navegador;form-actionlimita los destinos a los que pueden enviarse formularios;frame-srcregula los marcos que la página carga, mientrasframe-ancestorsdecide quién puede incrustar la propia web.
Permitir unsafe-inline de forma permanente para silenciar avisos debilita una parte importante de CSP. A veces una migración necesita una fase intermedia, pero debe quedar documentada con un siguiente paso. También conviene depurar informes: extensiones del navegador y software instalado por el usuario pueden generar ruido que no procede del sitio.
Evitar incrustaciones no autorizadas
La directiva frame-ancestors permite decidir qué sitios pueden mostrar una página dentro de un frame o iframe. Es una defensa relevante frente a interfaces superpuestas para engañar al usuario. No puede configurarse mediante una etiqueta meta; debe llegar como cabecera HTTP.
Si la aplicación se integra en portales de clientes, intranets o servicios externos, una regla 'none' puede romper ese uso. En esos casos se autorizan explícitamente los orígenes necesarios y se prueban todos los contextos. X-Frame-Options sigue siendo útil para compatibilidad, pero CSP ofrece un control más flexible.
Permissions-Policy: desactivar capacidades que no se necesitan
Permissions-Policy permite controlar funciones del navegador como cámara, micrófono o geolocalización, tanto en la página como en determinados iframes. Una web que no usa esas capacidades puede restringirlas; una herramienta de videollamada o un localizador necesitará una configuración específica.
La disponibilidad de directivas varía entre navegadores y algunas funciones siguen evolucionando. Por eso la política debe basarse en las capacidades reales de la aplicación y en pruebas de compatibilidad, no en una cadena genérica copiada de una lista.
Un despliegue que pueda revertirse
- guardar la configuración actual y definir un procedimiento de reversión;
- inventariar recursos, dominios externos y recorridos críticos;
- corregir HTTPS, certificados, redirecciones y tipos MIME;
- activar primero medidas de bajo riesgo y una CSP en modo informe;
- probar escritorio y móvil, con distintas decisiones de cookies y perfiles de usuario;
- pasar CSP a bloqueo por etapas y vigilar errores reales;
- revisar la política cuando cambien proveedores, etiquetas o funciones.
El OWASP Secure Headers Project mantiene referencias sobre cabeceras recomendadas y obsoletas. Su cheat sheet de cabeceras HTTP es un buen punto de contraste, pero la configuración final siempre debe adaptarse a la aplicación.
VOWE puede abordar el inventario, la configuración y las pruebas dentro del soporte técnico de sitios web o como parte de un proyecto de desarrollo web a medida. Para valorar el caso, puedes enviar la URL, la tecnología y las integraciones principales desde la página de contacto.
Preguntas frecuentes sobre cabeceras de seguridad y VOWE
¿Puede VOWE revisar y configurar las cabeceras de seguridad de una web?
Sí. Dentro del soporte técnico y el desarrollo web, VOWE puede inventariar recursos e integraciones, revisar la configuración actual, proponer una política por fases y comprobar su efecto en la web. El alcance depende del servidor, el gestor de contenidos, la infraestructura y los servicios externos utilizados.
¿Qué necesita VOWE para preparar una política segura?
Para una primera valoración hacen falta la URL, la tecnología y el alojamiento, acceso autorizado a la configuración, un inventario de analítica, pagos, formularios, vídeos y otros recursos externos, además de recorridos críticos que deban probarse. También conviene indicar quién puede aprobar cambios y ejecutar una reversión.
¿Tener todas las cabeceras garantiza que la web sea segura?
No. Las cabeceras reducen riesgos concretos, pero no sustituyen las actualizaciones, el control de acceso, la validación de entradas, la codificación de salidas, la gestión de secretos, las copias de seguridad ni la monitorización. Una web segura necesita varias capas y revisiones periódicas.
Una política útil es la que se entiende, se prueba y se mantiene. Aplicar muchas cabeceras en una sola tarde puede producir una puntuación llamativa en un escáner y, al mismo tiempo, dejar una compra o un formulario fuera de servicio. El avance seguro es gradual, medible y reversible.
