Headers de seguridad

01 // Lee cada header como una política concreta

Los headers de respuesta dan instrucciones al navegador. Reducen riesgos en esa capa, pero no reemplazan validación, autorización ni un diseño seguro. Para evaluarlos, nombra la pregunta que resuelve cada uno: transporte, contenido, navegación o embebido.

02 // HSTS empieza después de recibirlo

Strict-Transport-Security pide usar HTTPS en visitas futuras durante el plazo indicado. Revisa duración, alcance de subdominios cuando corresponda y que todas las rutas cubiertas funcionen por HTTPS. No sustituye un certificado válido ni protege una primera visita que aún no conoce la política.

Ejemplo: si una aplicación declara HSTS para sus subdominios, un subdominio que sólo responde por HTTP queda fuera del funcionamiento esperado. La revisión debe incluir ese alcance antes de ampliar la política.

03 // Controla embebido y tipo de contenido

Content-Security-Policy puede restringir recursos y quién incrusta una página. Su directiva frame-ancestors limita los orígenes que pueden mostrarla dentro de un frame; X-Frame-Options es un control clásico relacionado. Confirma qué política expresa el comportamiento requerido, en vez de marcar sólo que existe un header.

Content-Type declara el tipo del cuerpo y X-Content-Type-Options con nosniff indica al navegador que no adivine otro. La combinación evita inferencias peligrosas, pero no corrige contenido mal clasificado ni datos expuestos sin permiso.

04 // Reduce información al navegar

Referrer-Policy controla cuánta información de la URL de origen acompaña una navegación. Una ruta puede contener identificadores privados aunque no incluya un secreto. Elige la política según el destino y evita que la URL sea el único lugar donde viva un dato sensible.

Ejemplo: documenta para cada header el riesgo que reduce y el control que todavía corresponde a la aplicación. Esa separación evita atribuir a una cabecera una protección que no puede ofrecer.