Explicación de cabeceras de seguridad

Owned by Onesait Security (Unlicensed)
Last updated: 06/06/22
4 min read

A continuación repasaremos las cabeceras de seguridad que se configuran a nivel del servidor, lo que dará una capa extra de seguridad en las aplicaciones.

Strict-Transport-Security

El uso de esta cabecera va a impedir que se degrade la navegación a HTTP sin el cifrado correspondiente, obligando por el tiempo definido a que siempre se navegue a través de HTTPS.

Configuración en Apache:

Apache

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Configuración en Nginx:

Nginx

add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

Content-Security-Policy (CSP)

Esta cabecera previene y mitiga ataques de tipo Cross Site Scripting (XSS). Estos ataques se aprovechan de la confianza del navegador en el contenido que recibe del servidor. El navegador de la víctima ejecutará los scripts maliciosos por lo que este encabezado determina que recursos deben ejecutarse mediante una lista blanca de fuentes de contenido aprobadas, pudiendo denegar este tipo de acciones.

Configuración en Apache:

Apache

Header set Content-Security-Policy "default-src 'self';"

Configuración en Nginx:

Nginx

X-Frame-Options

Habilitar esta cabecera protege a sus visitantes contra ataques de Clickjacking, los cuales consisten en la invocación de un iframe transparente cargado desde un dominio externo en la Web. Por lo que si se superponen falsos botones se puede engañar a la víctima para que realice acciones administrativas sin percatarse de ello (ingeniería social).

Esta cabecera puede adoptar tres valores:

  • DENY lo que significa que su sitio no se puede enmarcar.

  • SAMEORIGIN que le permite enmarcar su propio sitio.

  • ALLOW-FROM permite especificar que sitios pueden enmarcar su propio sitio.

Configuración en Apache:

Apache

Configuración en Nginx:

Nginx

X-XSS-Protection

Esta cabecera obliga al navegador del usuario a habilitar sus filtros anti XSS. Es recomendable solo cuando se usen navegadores antiguos, los cuales no acepten CSP.

Configuración en Apache:

Apache

Configuración en Nginx:

Nginx

X-Content-Type-Options

Esta cabecera ayuda a reducir el riesgo de que se produzca un ataque, en el que se carguen hojas de estilo o scripts maliciosos.

Puede adoptar un valor:

  • nosniff

Configuración en Apache:

Apache

Configuración en Nginx:

Nginx

Referrer-Policy

Esta cabecera permite controlar que información se envía en la cabecera Referrer cuál es utilizada por el navegador para indicar al servidor desde que enlace se ha llegado a la página.

Las tres directivas más utilizadas son:

  • no-referrer No se enviará ningún dato de referente junto con las solicitudes.

  • same-origin establecer las referencias del mismo origen.

  • strict-origin Solo se enviará el origen del documento como referente a destinos que a priori son igual de seguros (HTTPS → HTTPS), pero no lo recibirán destinos menos seguros (HTTPS → HTTP).

 

Configuración en Apache:

Apache

Configuración en Nginx:

Nginx

Permissions-Policy

Esta cabecera controla qué funciones del navegador se pueden utilizar. Además de implementar estas reglas para su propio contenido, también puede evitar que los iFrames externos utilicen estas funciones del navegador, lo que lo convierte en un recurso muy valioso que viene a sustituir a los Feature-Policy.

Consta de múltiples directivas, algunas de estas son:

  • Accelerometer

  • Battery

  • Camera

  • Fullscreen

  • Geolocation

  • Microphone

  • Usb

  • Vibrate

Configuración en Apache:

Apache

Configuración en Nginx:

Nginx

Cache-Control

Esta cabecera permite especificar directivas para mecanismos de almacenamiento en caché tanto en solicitudes como en respuestas. Las directivas de almacenamiento en caché son unidireccionales, lo que significa que una directiva dada en una solicitud no implica que se deba dar la misma directiva en la respuesta. Sin el uso de esta cabecera el contenido cacheado quedará almacenado en el navegador del usuario, por lo que es posible obtener información sensible, por ejemplo, tarjetas de crédito, direcciones, usuarios, etc.

Las directivas más importante son:

  • no-cache obliga a los cachés a enviar la solicitud al servidor de origen para su validación antes de liberar una copia en caché.

  • no-store es la única directiva que se necesita para prevenir el cacheo de respuestas en navegadores modernos.

Configuración en Apache:

Apache

Configuración en Nginx:

Nginx

Políticas CORS


El uso compartido de recursos de origen cruzado (CORS) es un mecanismo que utiliza encabezados HTTP adicionales para indicar a los navegadores que den a una aplicación web que se ejecuta en un origen, acceso a recursos seleccionados de un origen diferente.

Estos son los encabezados que el servidor devuelve en su respuesta.

  • Access-Control-Allow-Origin: <origin>: Se utiliza para especificar el origen al que se le permite acceder al recurso en el servidor. Es posible especificar que solo se permiten solicitudes de un origen específico: Access-Control-Allow-Origin: https://ejemplo.com, o que el origen no importa - Access-Control-Allow-Origin: *.

  • Access-Control-Expose-Headers: <headers>: Como su nombre lo indica, enumera los encabezados a los que tiene acceso el navegador.

  • Access-Control-Max-Age: <seconds>: Esto indica la duración durante la cual se puede almacenar en caché la respuesta de una solicitud de verificación previa.

  • Access-Control-Allow-Credentials: <boolean>: Esto indica que el navegador puede hacer uso de la respuesta cuando la solicitud inicial se realizó con una credencial.

  • Access-Control-Allow-Methods: <methods>: Esto indica los métodos que se permitieron al intentar acceder a un recurso.

  • Access-Control-Allow-Headers: <headers>: Esto indica que los encabezados HTTP se pueden usar en una solicitud.

Ejemplo cabeceras CORS de respuesta