¿Cómo proteger mi web? Cabeceras HTTP para mejorar la seguridad y el SEO

Sergio Vergara -

Esta semana volvemos con más seguridad en desarrollo web con cabeceras HTTP como Feature-policy, X-Content-Type-Options, X-Permitted-Cross-Domain-Policies y Referrer-Policy.

Son varios los protocolos y cabeceras necesarias para securizar la comunicación entre tu web y la de tus usuarios. Aplicando medidas mejorarás la protección de tu desarrollo web y también mejorarás el posicionamiento SEO de la misma, tal como ya comentamos en Seguridad web y posicionamiento SEO con HTTPS y HSTS.

Actualmente hay un amplio espectro de cabeceras HTTP relacionadas con la seguridad. A continuación resumo cada una de ellas explicando cómo implementarlas en tu web y qué tipo de beneficios te aportarían. Todas cumplen con su objetivo, así que es importante aplicar cada una de ellas:

  • HTTPS
  • HTTP Strict-Transport-Security (HSTS)
  • X-Frame-Options
  • Content-Security-Policy (CSP)
  • Feature-policy
  • X-Content-Type-Options
  • X-Permitted-Cross-Domain-Policies
  • Referrer-Policy

Hace unos meses comentamos las cuatro primeras prácticas,  por eso te invitamos a que antes de continuar con la lectura repases la Seguridad web y posicionamiento SEO con HTTPS y HSTS.

Ahora veamos cómo aplicar las otras cuatro prácticas: Feature-policy, X-Content-Type-Options, X-Permitted-Cross-Domain-Policies y Referrer-Policy.

Feature-policy

Con las cabeceras HTTP Feature-Policy podrás definir qué funciones del navegador permitir y/o denegar desde tu propio dominio web o desde cualquier otro contenido como de un <iframe>.

Con una sintaxis muy similar a CSP. Aquí te facilito un ejemplo que podrías utilizar en tu desarrollo web:

Feature-Policy: "geolocation none;midi none;notifications none;push *;sync-xhr none;microphone none;camera none;magnetometer none;gyroscope none;speaker self;vibrate none;fullscreen self;payment none;";

Esta política interactúa directamente con las funciones del navegador del usuario. Analicemos algunas de las características del ejemplo anterior:

  • push *: la página actual y cualquier iframe pueden usar las funciones de notificaciones push.
  • camera 'none': se deniega el acceso a la función de la cámara a la página actual y a cualquier <iframe>.
  • fullscreen 'self': Permite fullscreen tu web y en cualquier <iframe> del mismo dominio.

Feature-policy es una cabecera muy reciente pero estoy convencido que la prevención que aporta no puede pasarse por alto. Con esta práctica podrás controlar las acciones que realicen los scripts que integran tu desarrollo web. Si tu web no requiere de, por ejemplo, realizar una foto o grabar un audio, recomiendo restringir dicho acceso mediante Feature-policy.

Saber más: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

X-Content-Type-Options

A veces, las funciones inteligentes del navegador terminan perjudicándonos desde el punto de vista de la seguridad. Un claro ejemplo es MIME-sniffing, una técnica popularizada por Internet Explorer.

La detección de MIME es la capacidad para un navegador de detectar automáticamente (y corregir) el tipo de contenido de un recurso que está descargándose. Por ejemplo, le pedimos al navegador que muestre una imagen en /awesome-picture.png, pero el servidor establece el tipo incorrecto cuando se lo sirve al navegador (por ejemplo Content-Type: text/plain). Esto generalmente provocaría que el navegador no pueda mostrar la imagen correctamente.

Para solucionar el problema, IE hizo todo lo posible para implementar una capacidad de detección MIME: al descargar un recurso, el navegador lo "escanearía" y si detectara que el tipo de contenido del recurso no es el anunciado por el servidor en la cabecera Content-Type, ignorará el tipo enviado por el servidor e interpretaría el recurso de acuerdo con el tipo MIME detectado por el navegador.

Ahora, imagina alojar una web que permita a los usuarios cargar sus propias imágenes, e imagina a un usuario cargando un archivo /test.jpg que contiene código JavaScript.

¿Ves a dónde va esto? Una vez que se carga el archivo el sitio lo incluirá en su propio HTML y cuando el navegador intente representar el documento encontrará la "imagen" que el usuario acaba de cargar. Al mismo tiempo que el navegador descarga dicha imagen detecta que es un script y la ejecutará en el navegador de la víctima.

Para evitar este problema, podemos configurar el X-Content-Type-Options:

X-Content-Type-Options: "nosniff" always;

Con esta cabecera podrás deshabilitar por completo la detección de MIME. Al hacerlo, le estamos diciendo al navegador que somos plenamente conscientes de que algunos archivos pueden tener una discrepancia en términos de tipo y contenido, y que el navegador no debería preocuparse por eso. Sabemos lo que estamos haciendo y, por lo tanto, el navegador no debería tratar de adivinar el tipo de contenido, ya que podría representar una amenaza para la seguridad de nuestros usuarios.

Saber más: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

X-Permitted-Cross-Domain-Policies

Muy relacionado con CORS, las X-Permitted-Cross-Domain-Policies;  políticas de dominio cruzado para los productos de Adobe (Flash, Acrobat, etc).

No entraré minuciosamente en los detalles, ya que esta es una cabecera que se dirige a casos de uso muy específico. En pocas palabras, los productos de Adobe manejan la solicitud de dominio cruzado a través de un crossdomain.xml, archivo en la raíz del dominio al que se dirige la solicitud, y X-Permitted-Cross-Domain-Policies define las políticas para acceder a este archivo.

¿Suena complicado? Simplemente sugeriría agregar

X-Permitted-Cross-Domain-Policies: none

Para ignorar a los clientes que desean realizar solicitudes entre dominios con Flash.

Referrer-Policy

Esta joven cabecera nacida a principios de 2017, actualmente compatible con todos los principales navegadores, es usada para implementar una restricción de seguridad en tu desarrollo web. Si el encabezado contiene una URL específica en una lista blanca que nosotros mismos definimos, dejaremos pasar a los usuarios.

Algunos de los valores más comunes de Referrer-Policy son:

  • no-referrer: la cabecera Referer se omitirá por completo
  • origin: redirecciona https://example.com/private-page a https://example.com/
  • strict-origin: Solo envía el origen como referencia cuando el nivel de seguridad del protocolo se mantenga igual (HTTPS → HTTPS), en ningún caso lo enviará a un destino menos seguro (HTTPS → HTTP).

Aquí va un ejemplo:

Referrer-Policy: "strict-origin"

Vale la pena señalar que hay muchas más variaciones de Referrer-Policy (same-origin, no-referrer-when-downgrade, etc.), pero los que he mencionado anteriormente son los que probablemente van a cubrir la mayor parte de los casos de uso. Si deseas comprender mejor todas y cada una de las variaciones que puedes usar recomendaría ir a la página dedicada de OWASP o en Mozilla.

La cabecera Origin es muy similar al Referer, ya que lo envía el navegador en solicitudes de dominio cruzado para asegurarse de que el usuario pueda acceder a un recurso en un dominio diferente. La cabecera Origin es controlada por el navegador, por lo que no hay forma de que un usuario malintencionado pueda manipularlo.

Verifica la seguridad de tu desarrollo web

Securityheaders.com es una web muy útil que te permitirá verificar que si tu desarrollo web dispone de las cabeceras correctas relacionadas con la seguridad. Aquí hay un informe de ejemplo de itdo.com:

Conclusión

Este artículo debería haberte presentado algunas cabeceras HTTP interesantes, permitiéndote comprender cómo fortalecer tus aplicaciones web a través de características específicas y de  cabeceras HTTP, junto con un poco de ayuda de las características de los navegadores web.

¿Configuras las cabeceras de tu servidor web para securizar? ¿Optimizas el SEO de tu web mejorando la seguridad?

Photo by Sam Erwin on Unsplash

Referencias: