Cabeceras HTTP: CSP, HSTS y seguridad web

Implementaste la aplicación. Las páginas se cargan, los formularios funcionan y nada parece roto. Luego ejecuta un escaneo y regresa con una lista de hallazgos sobre encabezados - y nada de eso es obvio.

Esa es una primera reacción normal. Los encabezados no aparecen en la pantalla, por lo que es difícil saber si son importantes o si el escáner simplemente está siendo quisquilloso. Esta guía le explica los encabezados que verá con más frecuencia, lo que realmente hace cada uno en un lenguaje sencillo y cómo verificar el suyo sin conjeturas.

Los encabezados de seguridad son instrucciones que su servidor envía al navegador junto con la página. El navegador los lee y ajusta cómo maneja su contenido: qué scripts pueden ejecutarse, si la página puede cargarse sobre HTTP simple, si otro sitio puede incrustarla en un marco.

Nada en la página cambia. Es exactamente por eso que estos hallazgos parecen abstractos: el sitio puede verse y comportarse perfectamente sin tener un conjunto de protecciones que serían importantes el día en que algo salga mal.

El marco honesto es el siguiente: los encabezados reducen una clase específica de riesgo. No hacen que un sitio sea seguro por sí solos, y una verificación de encabezado limpio no prueba que un sitio sea completamente seguro. Piense en ellas como una capa entre varias y una de las capas más baratas de hacer bien.

Cuando un navegador solicita una página, su servidor responde con la página y un bloque de metadatos llamado encabezados de respuesta. Puede verlos usted mismo: abra las herramientas de desarrollo de su navegador, vaya a la pestaña Red, vuelva a cargar la página y haga clic en la solicitud superior. Los encabezados están ahí.

Los encabezados de seguridad son simplemente los que le indican al navegador que aplique una regla. Algunos son estrictos, otros son consultivos y todos están configurados en la configuración de su servidor, su marco o su plataforma de alojamiento, no en su HTML.

CSP le dice al navegador qué fuentes de contenido pueden cargar en su página. Es el encabezado más poderoso aquí y el que la gente encuentra más intimidante.

En la práctica, un CSP detalla cosas como: los scripts sólo pueden provenir de su propio dominio y de una CDN confiable; las imágenes pueden provenir de cualquier lugar por encima de HTTPS; la página no puede estar enmarcada por otro sitio. Si algo intenta cargarse desde una fuente que no permitiste, el navegador lo bloquea y registra el intento en la consola.

CSP es una defensa adicional contra la inyección de scripts, junto con la codificación y desinfección de salida segura. También es el encabezado con mayor probabilidad de romper algo si lo configuras de manera demasiado agresiva. El camino práctico para un principiante es comenzar en modo de solo informe, observar lo que se habría bloqueado, solucionar los problemas reales y luego aplicarlo.

HSTS le dice al navegador que solo se comunique con su sitio a través de HTTPS, durante un período definido. Una vez que un navegador haya visto este encabezado, se negará a realizar una conexión HTTP insegura a su dominio, incluso si un usuario escribe http:// o sigue un enlace antiguo.

Una vez que el navegador conoce la política HSTS, actualiza las solicitudes HTTP antes de enviarlas. La primera visita aún puede usar HTTP a menos que el dominio ya esté cubierto por una entrada de precarga HSTS.

Lo único que hay que respetar aquí es el compromiso. El navegador recuerda HSTS durante el tiempo que usted especifique, así que comience con una duración corta mientras confirma que cada subdominio funciona en HTTPS, luego alarguela una vez que esté seguro.

X-Frame-Options controla si otro sitio puede cargar sus páginas dentro de un marco: un <iframe> en la página de otra persona.

¿Por qué preocuparse? Porque el encuadre es el mecanismo detrás del clickjacking, donde un atacante superpone su página real con elementos invisibles o disfrazados para que un usuario haga clic en algo que no era su intención. Si su aplicación tiene alguna acción de inicio de sesión (un botón de eliminación, un pago, un cambio de configuración), enmarcarla en otro lugar es un riesgo que no desea.

El escenario común es SAMEORIGIN, que permite que tus propias páginas se enmarquen entre sí pero bloquea a todas las demás. Si nunca tiene la intención de que le incriminen, esa suele ser la opción correcta.

Referrer-Policy decide qué parte de su URL se comparte con otros sitios cuando un usuario hace clic en un enlace fuera de su página. Los navegadores modernos normalmente usan strict-origin-when-cross-origin: la URL completa se puede enviar en solicitudes del mismo origen, mientras que las solicitudes HTTPS de orígenes cruzados reciben solo el origen. Una política explícitamente más débil puede revelar más.

Esto es importante porque las URL completas a veces contienen valores confidenciales en las cadenas de consulta: tokens, ID, direcciones de correo electrónico, términos de búsqueda. Filtrarlos a un tercero es silencioso y fácil de pasar por alto.

Una base sensata es enviar sólo el origen, o nada en absoluto, en las solicitudes entre sitios. No le cuesta casi nada y elimina una fuga de datos accidental.

Algunos encabezados más aparecen con suficiente frecuencia como para saberlos por su nombre:

• X-Content-Type-Options: nosniff impide que el navegador adivine el tipo de archivo, lo que de otro modo puede convertir un archivo cargado en un script ejecutable.

• Permissions-Policy desactiva las funciones del navegador que no utilizas, como la cámara, el micrófono o la geolocalización.

• Cross-Origin-Opener-Policy y los encabezados de origen cruzado relacionados aíslan su página de otras, lo que ayuda a contener ciertos ataques.

No los necesita todos el primer día. Saber lo que hacen le ayuda a leer un informe de escaneo sin entrar en pánico.

Tienes dos maneras de mirar.

Primero, la ruta manual: herramientas de desarrollo, pestaña Red, haga clic en la solicitud de página y lea los encabezados de respuesta. Esto es útil para confirmar que hay un único encabezado y configurarlo de la forma esperada.

En segundo lugar, la ruta práctica para más de una página: ejecutar un escaneo. Un escáner busca su sitio como lo haría un navegador e informa qué encabezados de seguridad están presentes, cuáles faltan y qué expone cada brecha. Esto le brinda una lista priorizada en lugar de un muro de texto sin formato, y verifica las páginas que no habría pensado abrir manualmente.

Una herramienta de uso general como el análisis de seguridad liviano y gratuito de VICE señalará los hallazgos del encabezado junto con otros problemas, con la evidencia detrás de cada uno para que pueda ver por qué se planteó.

Los encabezados se encuentran en la configuración, por lo que la mayoría de las correcciones son pequeñas: agregue una línea a la configuración de su servidor, una configuración en su marco o una opción en el panel de su host. Cambie un encabezado a la vez y confirme que el sitio aún funciona.

Luego vuelva a escanear. Este es el paso que la gente se salta. Editar una configuración no significa que el encabezado ahora sea correcto en cada página, y marcar algo como arreglado en un panel no es lo mismo que confirmarlo. Sólo un nuevo análisis en el mismo ámbito indica que el cambio realmente tuvo efecto.

Comience con un escaneo gratuito, observe lo que realmente hacen sus encabezados y corrija los principales hallazgos uno por uno. Ése es un primer paso razonable y una posición mucho mejor que esperar que los valores predeterminados estén bien.