6 en-têtes de sécurité que vous devriez utiliser sur votre site web

Parlons des en-têtes de sécurité ! Un en-tête de sécurité est une instruction supplémentaire que le serveur web envoie au navigateur web en réponse à une requête, en même temps que le corps de contenu de la réponse. Cette instruction donne au navigateur des directives précises sur la manière de gérer le contenu de la page, afin d'améliorer la sécurité du site web.

Les en-têtes de sécurité jouent un rôle crucial dans la protection des sites web contre une variété d'attaques ou de fuites de données, y compris par exemple :

  • XSS (Cross-Site Scripting) : injection de code malveillant dans une page web pour voler des données ou détourner les actions de l'utilisateur ;
  • Clickjacking : une technique de phishing dans laquelle un élément cliquable est caché sous un autre élément afin d'inciter l'utilisateur à effectuer une action indésirable ;
  • Injection de code : introduction de code malveillant dans une application pour modifier son comportement.

L'en-tête Referrer-Policy

Referrer-policy est un en-tête encore sous-utilisé, même s'il protège la vie privée de l'utilisateur en limitant la quantité d'informations de référent envoyées avec les requêtes HTTP. Cela peut aider à prévenir la fuite de données plus ou moins sensibles, telles que les URL des pages visitées.

Pourquoi est-ce important ? Lorsque le visiteur d'un site web clique sur un lien, un en-tête de requête Referer est envoyé avec la requête, et il contient l'URL de la page d'où provient le visiteur. Ainsi, le site web de destination peut connaître précisément l'URL de la page web d'où l'utilisateur provient, ce qui peut fournir des informations personnelles.

Ces informations, traditionnellement envoyées dans l'en-tête Referer, révèlent l'origine d'une requête, exposant potentiellement des données sensibles de l'utilisateur.

Pour atténuer cette préoccupation en matière de confidentialité, la Referrer Policy permet aux propriétaires de sites web de restreindre le niveau de détail partagé. En définissant cet en-tête, vous pouvez spécifier si aucune information de référent ne doit être envoyée, seule l'origine (domaine et chemin), ou l'URL complète.

Voici un exemple de la syntaxe de l'en-tête Referrer-Policy :

Referrer-Policy: no-referrer

Vous voyez ? C'est assez simple et plutôt direct. En configurant soigneusement Referrer-Policy, vous pouvez améliorer la confidentialité et la sécurité des utilisateurs sur votre site web.

redirection.io a une recette pour cela !

Nous proposons une recette pour configurer l'en-tête Referer-Policy sur votre site web en seulement quelques clics. Elle vous permet de choisir la valeur appropriée à configurer :

L'interface d'installation de la recette Referrer Policy dans redirection.io

La page de recette Referer-Policy donne des indications détaillées sur la valeur à choisir pour cet en-tête.

L'en-tête Strict-Transport-Security (HSTS)

HTTP Strict Transport Security (HSTS) est un mécanisme de sécurité qui indique aux navigateurs de ne communiquer avec un site web qu'en HTTPS, même si l'utilisateur tente d'y accéder via HTTP. Cela aide à protéger contre les attaques de l'homme du milieu, lorsqu'un attaquant intercepte la communication entre l'utilisateur et le serveur.

Comment fonctionne l'en-tête HSTS ?

  1. Le serveur envoie l'en-tête HSTS : Lorsqu'un site web est accédé pour la première fois via HTTPS, le serveur envoie un en-tête HSTS avec la réponse. Cet en-tête demande au navigateur de :
  • Mémoriser le domaine pour une période spécifiée (par exemple, un an).
  • Rediriger automatiquement toutes les futures requêtes HTTP vers ce domaine vers HTTPS.
  1. Le navigateur stocke la politique : Le navigateur stocke cette politique localement, afin qu'elle puisse être appliquée à toutes les requêtes HTTP ultérieures.
  2. HTTPS forcé : Pour les visites ultérieures, le navigateur redirigera automatiquement toutes les requêtes HTTP vers HTTPS, même si l'utilisateur tape l'adresse HTTP ou clique sur un lien HTTP.

À ce jour, HSTS n'est plus une option et devrait être implémenté dans tous les sites web d'entreprise.

Quels sont les avantages de l'utilisation de HSTS sur votre site web ?

L'adoption de HSTS offre plusieurs avantages :

  • Sécurité renforcée : il protège votre site web contre les attaques de l'homme du milieu en forçant les connexions HTTPS.
  • Meilleure expérience utilisateur : il garantit que les utilisateurs se connectent toujours en toute sécurité, même s'ils tapent accidentellement la mauvaise URL.
  • Prévention des attaques par rétrogradation : il empêche les attaquants de forcer le navigateur à rétrograder vers une connexion HTTP moins sécurisée.

Comment implémenter HSTS ?

Pour implémenter HSTS, vous devez ajouter un en-tête Strict-Transport-Security aux réponses HTTP de votre site web. Cet en-tête inclut généralement deux directives :

  • max-age : Spécifie le nombre de secondes pendant lesquelles le navigateur doit appliquer la politique HSTS.
  • includeSubDomains : Indique si la politique doit s'appliquer à tous les sous-domaines du site web.

L'en-tête HSTS peut également inclure une directive preload, afin que les fournisseurs de navigateurs (Chrome, Firefox, Safari etc.) sachent directement que les requêtes effectuées vers votre domaine doivent toujours utiliser HTTPS.

Voici un exemple d'en-tête HSTS :

Strict-Transport-Security: max-age=31536000;  includeSubDomains

La configuration de HSTS est vraiment une bonne pratique, et nous vous encourageons fortement à le faire ! Avec redirection.io, l'installation de la recette prend quelques clics :

L'interface d'installation de la recette HSTS dans redirection.io

En savoir plus sur la recette HSTS dans notre documentation.

L'en-tête Permissions-Policy

Il est important de se souvenir qu'aujourd'hui, les navigateurs font bien plus que simplement exposer des pages web : les fonctionnalités exposées par les navigateurs sont de plus en plus nombreuses, et de plus en plus sensibles en termes de données privées. Par exemple, une page web peut demander l'utilisation de la caméra, du microphone et de la géolocalisation. Elle peut déclencher des événements de paiement, ou même savoir si l'utilisateur est inactif ou utilise actuellement son ordinateur. De telles fonctionnalités sont puissantes et permettent de construire des applications web riches, mais doivent être contrôlées pour éviter les fuites de données personnelles - à grand pouvoir, grande responsabilité.

L'en-tête Permissions-Policy définit les permissions de nombreuses fonctions du navigateur, telles que la caméra, le microphone, le lecteur d'empreintes digitales, la géolocalisation, etc. Plus précisément, lorsqu'il est renvoyé avec une réponse, cet en-tête indique au navigateur d'autoriser ou de bloquer certaines fonctions dans cette page web.

En d'autres termes, la mise en place d'un en-tête de sécurité Permissions-Policy vous donne un meilleur contrôle sur l'utilisation de ces fonctions, et limite le risque de fuite de données.

Comment éviter les fuites de données avec Permissions-Policy ?

Pour illustrer cela, prenons un exemple très concret :

Imaginons le cas de "Mon Site Web", un site média qui intègre plusieurs scripts publicitaires pour monétiser son contenu. On imagine souvent que les scripts publicitaires se limitent à afficher des publicités sur l'écran de l'utilisateur, mais la réalité est que de nombreux scripts tiers cherchent à collecter autant de données que possible et opèrent souvent sous forme de scripts, qui peuvent eux-mêmes charger d'autres scripts, qui chargent d'autres scripts et ainsi de suite. Ouvrez l'inspecteur web sur un site web médiatique grand public, et vous serez étonné par le nombre de domaines qui chargent des scripts lors de la navigation sur ce site ! Il peut s'agir littéralement de centaines de domaines qui chargent des ressources JavaScript dans le navigateur de l'utilisateur.

Schématiquement, la hiérarchie de chargement des scripts ressemble souvent à ceci :

MON SITE WEB
  │
  ├── A script
  ├── B script
  ├─┬ C script
  │ ├── C1 script
  │ ├── C2 script
  │ └─┬ C3 script
  │   ├── C3.1 script
  │   └── C3.2 script
  ├─┬ D script
  │ ├── D1 script
  │ └── D2 script
  └── E script

On peut voir que le script C chargé par "MON SITE WEB" charge lui-même le script C3, qui à son tour charge les scripts C3.1 et C3.2, alors que "MON SITE WEB" n'a aucun lien direct avec le fournisseur du script C3.1.

Néanmoins, le script C3.1 pourra accéder aux fonctions du navigateur de votre utilisateur, telles que sa caméra ou sa géolocalisation.

Si l'un des fournisseurs de scripts de cette chaîne présente une faille de sécurité, ou a subi une attaque ayant modifié les scripts insérés, certaines fonctionnalités du navigateur de l'utilisateur peuvent être exposées au risque d'une utilisation malveillante.

Par exemple, si l'entreprise qui fournit le script C1.3 a été piratée, il est possible qu'un utilisateur de "MON SITE WEB" voie une demande d'accès à sa caméra déclenchée dans son navigateur. Le danger est double :

  • Un utilisateur bien informé sur les questions de confidentialité risque de développer une mauvaise image de "MON SITE WEB", qui serait perçu comme un site mal conçu, intrusif ou avec des failles de sécurité. C'est ce que l'on appelle une "expérience catastrophique".
  • Un utilisateur néophyte, en revanche, pourrait accepter et voir ses données privées divulguées.

De plus, "MON SITE WEB" serait alors obligé d'engager une communication de crise avec ses utilisateurs, ce qui pourrait réellement nuire à son trafic et à la confiance de ses visiteurs à long terme.

Oui, redirection.io a une recette pour Permissions-Policy

À partir de la liste exhaustive des fonctionnalités du navigateur, vous choisissez la configuration appropriée pour votre site web. C'est vraiment facile à installer !

L'interface d'installation de la recette Permissions-Policy dans redirection.io

En savoir plus dans notre documentation sur la recette Permission-Policy.

Bien que Permissions-Policy soit un mécanisme très efficace et robuste, il est encore trop peu utilisé. Les sites web d'entreprise devraient en faire une bonne pratique de sécurité standard.

L'en-tête X-Frame-Options

Avez-vous déjà entendu parler du clickjacking ?

Le clickjacking est une technique de piratage web qui consiste à inciter un utilisateur à cliquer sur un élément d'une page web sans qu'il s'en rende compte.

L'idée est de profiter du fait que de nombreux utilisateurs sont constamment connectés à des sites web populaires, tels que Facebook, Paypal, etc.

Un hacker crée une page attrayante (par exemple, un jeu ou une page de produit), et vous la visitez.

Sous la couche graphique de la page, le hacker a caché une autre page, qui n'est pas visible, contenant, par exemple, un iframe de votre réseau social préféré – c'est le site web qu'il veut attaquer.

Appâté par le super produit en vente sur cette page, vous cliquez sur le bouton pour ajouter le produit à votre panier, alors qu'en fait vous avez cliqué sur le bouton caché sous la page, dans l'iframe, ce qui vous fera, par exemple, poster un message sur votre réseau social sans le savoir.

X-Frame-Options vous aide à prévenir le clickjacking

En utilisant un en-tête X-Frame-Options, vous empêchez l'intégration de votre site web dans un iframe, ce qui est souvent la première étape d'une attaque de clickjacking.

Les différentes valeurs possibles pour l'en-tête X-Frame-Options sont :

  • DENY : C'est la valeur la plus restrictive. Elle interdit catégoriquement l'intégration de la page dans un iframe, quelle que soit l'origine de la requête.
  • SAMEORIGIN : La page ne peut être intégrée dans un iframe que si ce dernier se trouve sur le même domaine que la page elle-même. Cela empêche les attaques de clickjacking provenant d'autres sites, mais permet l'utilisation d'iframes au sein du même site.
  • ALLOW-FROM url : Cette valeur spécifie une liste d'URL autorisées à intégrer la page dans un iframe. Il est important de noter que cette option est moins sécurisée que les deux précédentes, car elle ouvre la porte à des attaques potentielles si la liste des URI n'est pas correctement configurée.

Et pour vous faciliter la vie, redirection.io propose une recette pour X-Frame-Options, qui s'installe en quelques secondes, donc vous devriez vraiment le faire, car cela change la donne.

L'interface d'installation de la recette X-Frame-Options dans redirection.io

L'en-tête Content Security Policy (CSP)

Lutter contre les injections de contenu malveillant

Content Security Policy (CSP) est un mécanisme de sécurité conçu pour protéger les sites web contre certaines attaques, telles que les attaques XSS. Plus précisément, CSP aide à renforcer la sécurité de votre site web en limitant les sources de contenu autorisées, rendant votre site web plus résistant aux attaques. Il contribue également à protéger la vie privée des utilisateurs en contrôlant les ressources qui peuvent être chargées, limitant la possibilité de suivi et de collecte de données par des tiers.

Ainsi, par exemple, je peux décider que sur "MON SITE WEB", je n'autorise les scripts que de mon domaine, et de Google Analytics. En conséquence, tout autre script ajouté à la page, par exemple par un hacker, ne sera même pas téléchargé par le navigateur.

Cet en-tête est donc l'outil idéal pour lutter contre le Cross-Site-Scripting, mais sa mise en œuvre peut être délicate... à moins que vous n'utilisiez redirection.io.

Comment implémenter Content-Security-Policy avec redirection.io ?

Eh bien... Malheureusement, nous n'avons pas encore de recette pour la mise en place d'un en-tête CSP, mais redirection.io peut tout de même vous aider.

Pour configurer un en-tête CSP, il vous suffit de créer une règle avec un déclencheur d'URL /[ANYTHING] et une "action d'en-tête HTTP personnalisé" pour ajouter l'en-tête CSP à toutes les réponses servies par votre site web. Si nécessaire, vous pouvez cibler un ensemble plus restreint de pages pour tester avant de déployer l'en-tête CSP sur toutes les pages.

L'en-tête X-Content-Type-Options, pour éviter le code sniffing

L'en-tête HTTP X-Content-Type-Options est un mécanisme de sécurité utilisé par les serveurs web pour indiquer aux navigateurs qu'ils ne doivent pas tenter de deviner (ou "sniffer") le type de contenu d'une ressource.

Le content sniffing signifie que le navigateur ne se fie pas à l'en-tête Content-Type envoyé par le serveur, mais détermine plutôt le type de fichier d'une ressource en analysant son contenu. Bien que cela puisse sembler pratique, il s'agit en fait d'une méthode exploitée par les hackers pour exécuter du code malveillant.

En envoyant l'en-tête X-Content-Type-Options avec la valeur nosniff, le serveur indique au navigateur qu'il doit strictement respecter le type de contenu spécifié dans l'en-tête Content-Type. Cela empêche le navigateur de tenter d'interpréter le contenu d'une manière différente, réduisant considérablement le risque d'attaques par injection de code.

X-Content-Type-Options: nosniff

En l'utilisant, vous indiquez clairement au navigateur qu'il doit faire confiance au type de contenu spécifié par le serveur, ce qui renforce la sécurité de votre application.

Veuillez utiliser les en-têtes de sécurité pour votre site web

Voilà, vous avez un aperçu complet des solutions que vous pouvez implémenter sur votre site web pour renforcer la sécurité et offrir de meilleures garanties à vos utilisateurs.

Chez redirection.io, nous sommes conscients de ces enjeux, et nous respectons la vie privée des utilisateurs. C'est pourquoi nous mettons tout en œuvre pour vous aider à implémenter facilement et de manière autonome ces solutions. redirection.io est bien plus qu'un simple gestionnaire de redirections, et il fournit tous les outils utiles pour tester, vérifier et déployer des améliorations de sécurité sur vos sites web.