Cabeceras de seguridad HTTP: CSP, HSTS y las demás
Qué hacen realmente CSP, HSTS y las demás cabeceras de seguridad HTTP, cómo configurarlas y qué ataque bloquea cada una, sin jerga técnica.
Equipo de rabbitclipPublicación: 4 min. de lectura
En breve
Las cabeceras de seguridad HTTP son reglas que un servidor web añade a cada respuesta para decirle al navegador cómo comportarse. CSP limita desde qué orígenes pueden cargarse scripts e imágenes, HSTS obliga al navegador a usar siempre una conexión cifrada, y otras más pequeñas como X-Content-Type-Options y Referrer-Policy cierran riesgos igual de reales. Ninguna necesita código a medida; unas pocas líneas en la configuración del servidor o del CDN bastan.
Cuando el sitio de un bufete de abogados ejecuta un script publicitario de terceros sin una CSP bien configurada, ese script puede inyectar casi cualquier código en la página; en una página donde alguien está rellenando un formulario, ese riesgo no es abstracto. Las cabeceras de seguridad limitan desde el principio lo que un script así puede llegar a hacer.
¿Qué es una cabecera de seguridad HTTP y cómo funciona?
Una cabecera de seguridad HTTP es una línea de instrucción extra que el servidor envía con cada respuesta; el navegador la lee y restringe la página en consecuencia. Las cabeceras no cambian el contenido de la página, solo lo que el navegador puede hacer con ese contenido.
Añadirlas no requiere escribir una funcionalidad nueva; bastan unas pocas líneas en la configuración de Nginx, Apache, Cloudflare o un framework como Next.js. Una vez configuradas correctamente, se envían de forma automática con cada petición de página.
¿Qué hace realmente Content-Security-Policy (CSP)?
CSP define desde qué direcciones puede una página cargar scripts, imágenes, fuentes y estilos. Según la guía de cabeceras HTTP de OWASP, CSP es la única cabecera que mitiga de forma real que un código ya inyectado en una página llegue a ejecutarse; eso la convierte en una de las defensas más eficaces contra los ataques de scripting entre sitios (XSS).
La parte difícil de la configuración es listar de verdad cada recurso de terceros que usa el sitio, analítica, un servicio de fuentes, un proveedor de pagos; dejar uno fuera rompe parte de la página. Por eso CSP suele ejecutarse primero en modo solo informe, se revisan los registros, antes de pasar al modo restrictivo.
¿Qué garantiza HSTS (Strict-Transport-Security)?
HSTS le dice al navegador que nunca vuelva a conectarse a un sitio por http:// sin cifrar; la instrucción se guarda en el navegador, así que aunque alguien escriba http en la barra de direcciones, la conexión se sube automáticamente a https. Esto evita que una conexión se rebaje a texto plano a mitad de camino, un ataque de intermediario.
La configuración que recomienda MDN mantiene un max-age largo, alrededor de dos años, cubre también los subdominios, y puede enviarse a la lista de precarga; pero antes de unirse a esa lista, cada subdominio debe funcionar realmente sobre https, porque salir de esa lista después no es sencillo.
Cómo configurar un conjunto básico de cabeceras
Para un sitio corporativo pequeño, las siguientes cinco cabeceras son un punto de partida razonable; cada una cierra un riesgo distinto.
- Content-Security-Policy: limita desde dónde pueden cargarse scripts y recursos
- Strict-Transport-Security: mantiene la conexión cifrada en todo momento
- X-Content-Type-Options: nosniff, evita que el navegador adivine mal el tipo de un archivo
- Referrer-Policy: limita qué información de la página se filtra hacia otros sitios
- Permissions-Policy: restringe el acceso a funciones del navegador como la cámara o la ubicación
Probar las cabeceras y mantenerlas sin errores
Una cabecera mal configurada puede romper la página de forma visible o desactivar una función en silencio; ambas cosas deben probarse antes de publicar. La consola de desarrollador del navegador muestra directamente las violaciones de CSP; cuando se bloquea un recurso, la consola lo nombra y explica por qué.
Los cambios deberían probarse primero en un entorno de pruebas y después en una página en producción de bajo riesgo; aplicarlos a todo el sitio a la vez arriesga romper alguna integración de terceros inesperada.
Errores frecuentes
Las cabeceras de seguridad pueden convertirse en un ajuste que se configura una vez y se olvida; eso provoca una rotura que nadie nota hasta que se añade una nueva integración.
- relajar CSP con unsafe-inline, lo que anula en gran medida el propósito de la cabecera
- añadir HSTS a la lista de precarga sin probarlo antes
- no actualizar la lista de CSP cuando se añade un nuevo script de terceros
- configurar las cabeceras solo en la página de inicio y olvidar el resto del sitio
Las cabeceras de seguridad HTTP no cambian el aspecto de un sitio; definen qué puede hacer el navegador con él. Configurarlas es un trabajo de una sola vez, pero mantenerlas al día no lo es. Una primera llamada con rabbitclip es un buen sitio para comprobar qué cabeceras tiene realmente su sitio hoy.
Preguntas frecuentes
¿Afectan las cabeceras de seguridad al SEO?
No de forma directa, pero cabeceras como HSTS, que fuerzan HTTPS, son una señal positiva indirecta para los buscadores que valoran las conexiones seguras.
¿Puede configurar CSP romper un sitio que funciona?
Sí, si se configura mal. Probar antes en modo solo informe y revisar los registros antes de pasar al modo restrictivo reduce ese riesgo.
¿Dónde se configuran estas cabeceras?
En la configuración de Nginx, Apache, Cloudflare o un framework como Next.js; la sintaxis cambia, la lógica es la misma.
¿Necesita realmente un sitio pequeño estas cabeceras?
Sí. El tamaño no importa aquí; cualquier sitio con un formulario, una página de acceso o scripts de terceros enfrenta los mismos riesgos básicos.
