Ces dernières années, les attaques sur les sites et applications web ont augmenté de manière importante. La cybersécurité est l'affaire de tous et nous vous présentons ici des outils pour vous aider à sécuriser vos applicatifs.
Les entêtes HTTP sont envoyées par le serveur web à votre navigateur. Ils contiennent des informations sur la réponse, telles que le type de contenu, la taille du fichier et les directives de mise en cache. Ils peuvent également être utilisés pour améliorer la sécurité de votre application web. Nous allons explorer dans cet article les entêtes HTTP de sécurité les plus importants, et comment les mettre en place dans votre application ou site web.
Content-Security-Policy (CSP)
Ce header permet de contrôler les sources à partir desquelles le navigateur peut charger du contenu, tel que des scripts, des styles et des images. Cela permet de prévenir les attaques de cross-site scripting (XSS) et de clickjacking. Il fonctionne comme une liste blanche, définissant les sources fiables à partir desquelles le navigateur peut charger des ressources.
Le CSP est implémenté via un en-tête HTTP Content-Security-Policy envoyé par le serveur web au navigateur. Cet en-tête contient des directives qui spécifient les sources autorisées pour différents types de contenu. Pour notre site web, nous avons implémenté la directive suivante :
Content-Security-Policy "default-src 'self'; style-src https: 'unsafe-inline'; script-src https: 'unsafe-inline'; font-src 'self' fonts.gstatic.com; img-src 'self' data: tr-rc.lfeeder.com track-eu1.hubspot.com forms-eu1.hsforms.com *.clarity.ms *.bing.com; form-action 'self'; connect-src 'self' client.axept.io api.axept.io api-eu1.hubspot.com forms-eu1.hscollectedforms.net *.clarity.ms; frame-ancestors 'none'; frame-src app-eu1.hubspot.com;"Comme vous pouvez le voir, nous donnons une liste blanche de valeurs pour chaque type de ressources. Prenons comme exemple les polices d'écriture : font-src 'self' fonts.gstatic.com. Cette directive signifie que le navigateur peut charger les polices depuis le même domaine ('self') et depuis fonts.gstatic.com (Google Fonts).
Il faut donc bien entendu adapter cette directive à votre site/application et aux ressources qu'il utilise. Si vous avez des ressources tierces chargées, il faut bien autoriser ces domaines dans votre CSP.
Pour éviter toute catastrophe, il est possible de tester vos modifications avant de les déployer avec la directive Content-Security-Policy-Report-Only, qui va demander au navigateur de remonter les problèmes sans pour autant bloquer le chargement des ressources incriminées. Une fois que tout est en place, vous pouvez basculer sur la directive finale Content-Security-Policy et déployer vos modifications.
Il est important de noter que la CSP de notre exemple n'est pas parfaite et pourrait être améliorée en supprimant 'unsafe-inline' et en limitant davantage les sources autorisées, mais nous utilisons le CMS Drupal et son éditeur de texte CKEditor qui nécessite de garder une certaine ouverture. Il est crucial de la mettre à jour régulièrement en fonction des besoins de votre site web et des nouvelles menaces de sécurité.
Permissions-Policy
Ce header permet de spécifier les fonctionnalités du navigateur (comme la géolocalisation, la caméra, le microphone, etc.) auxquelles la page web a accès. Cela permet de limiter les risques liés à l'utilisation abusive de ces fonctionnalités.
Pour notre site web, nous avons implémenté la directive suivante :
Permissions-Policy "interest-cohort=(), accelerometer=(self), ambient-light-sensor=(self), autoplay=(self), battery=(self), camera=(self), cross-origin-isolated=(self), display-capture=(self), document-domain=(self), encrypted-media=(self), execution-while-not-rendered=(self), execution-while-out-of-viewport=(self), fullscreen=(self), geolocation=(self), gyroscope=(self), keyboard-map=(self), magnetometer=(self), microphone=(self), midi=(self), navigation-override=(self), payment=(self), picture-in-picture=(self), publickey-credentials-get=(self), screen-wake-lock=(self), sync-xhr=(self), usb=(self), web-share=(self), xr-spatial-tracking=(self)"Par exemple, camera=(self) signifie que seule la page web actuelle a accès à la fonctionnalité en question, l'accès à la caméra. Les iframes intégrées au site, même provenant du même domaine, n'y auront pas accès.
En limitant l'accès aux fonctionnalités sensibles, Permissions-Policy contribue à renforcer la sécurité, mais aussi à protéger la vie privée des utilisateurs en limitant l'accès à des fonctionnalités qui pourraient être utilisées pour collecter des données sensibles, comme la géolocalisation, la caméra ou le microphone.
Referrer-Policy
Referrer-Policy est une en-tête HTTP qui permet aux développeurs web de contrôler les informations envoyées dans l'en-tête Referer lors d'une navigation web. Cet en-tête indique au site web de destination d'où provient l'utilisateur, elle peut contenir des informations sensibles, comme l'URL complète de la page précédente, y compris les paramètres de requête qui peuvent contenir des données personnelles ou des identifiants de session. En contrôlant l'en-tête Referer, vous pouvez protéger la vie privée de vos utilisateurs et améliorer la sécurité de votre site web. Referrer-Policy vous permet de spécifier comment l'en-tête doit être envoyé, voire s'il doit être envoyé du tout.
Pour notre site web, nous avons implémenté la directive suivante :
Referrer-Policy "strict-origin-when-cross-origin"Si votre site web contient des informations confidentielles, vous pouvez utiliser cette même valeur pour limiter les informations envoyées lors de navigations sur des sites ou applications externes. Cela peut vous aider à respecter le Règlement général sur la protection des données (RGPD) en limitant la divulgation d'informations personnelles via l'en-tête Referer.
Strict-Transport-Security (HSTS)
C'est un mécanisme de sécurité crucial pour les sites web qui utilisent HTTPS. Il permet de s'assurer que le navigateur d'un utilisateur se connecte toujours au site via HTTPS, même si l'utilisateur a saisi l'adresse avec HTTP ou a cliqué sur un lien non sécurisé.
Lorsqu'un navigateur visite un site web qui utilise HSTS, le serveur web envoie un en-tête HTTP spécial appelé Strict-Transport-Security. Cet en-tête contient des directives qui indiquent au navigateur comment se comporter à l'avenir, en spécifiant la durée (en secondes) pendant laquelle le navigateur doit se souvenir que le site est accessible uniquement via HTTPS et en indiquant si la règle HSTS s'applique également à tous les sous-domaines du site web.
HSTS empêche les attaquants d'intercepter les communications entre le navigateur et le serveur web et de rediriger l'utilisateur vers une version non sécurisée du site. Si un utilisateur accède à un site web avec un certificat SSL/TLS invalide, HSTS l'empêche de se connecter et l'avertit du danger.
De plus, cette directive permet d'éviter les redirections inutiles de HTTP vers HTTPS, ce qui peut améliorer les performances du site web. Au niveau du référencement, Google favorise les sites web qui utilisent HTTPS et HSTS, c'est donc une directive très importante et très facile à mettre en place.
Pour notre site web, nous avons activé cette fonctionnalité avec le header suivant :
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options
X-Content-Type-Options est un en-tête de sécurité HTTP qui aide à protéger votre site web contre les attaques dites de "MIME sniffing" : un comportement des navigateurs web qui consiste à essayer de deviner le type de contenu d'une ressource (par exemple, une image, un script, une feuille de style) en analysant son contenu, plutôt que de se fier uniquement à l'en-tête Content-Type envoyé par le serveur.
Cette technique peut permettre à des attaquants d'exploiter des failles de sécurité en envoyant du code malveillant déguisé en un type de contenu inoffensif. Par exemple, un attaquant pourrait envoyer un script JavaScript déguisé en image. Si le navigateur "sniffe" le contenu et l'interprète comme un script, le code malveillant sera exécuté.
L'en-tête X-Content-Type-Options permet de désactiver le MIME sniffing dans le navigateur. Lorsqu'il est défini sur nosniff, le navigateur est forcé de respecter le type de contenu spécifié dans l'en-tête Content-Type et de ne pas essayer de le deviner.
Il suffit d'ajouter l'en-tête suivant à vos réponses HTTP :
X-Content-Type-Options "nosniff"
X-Frame-Options
X-Frame-Options est une en-tête HTTP de sécurité qui permet aux propriétaires de sites web de contrôler comment leurs pages peuvent être intégrées dans des frames (cadres) ou iframes sur d'autres sites. C'est une mesure de protection importante contre les attaques de type "clickjacking". Le clickjacking est une technique malveillante qui consiste à tromper les utilisateurs en leur faisant cliquer sur quelque chose de différent de ce qu'ils pensent cliquer.
Imaginez une page web malveillante qui intègre votre site dans un iframe invisible. L'attaquant peut ensuite superposer des éléments sur cet iframe, de sorte que lorsque l'utilisateur clique sur ce qu'il pense être un bouton inoffensif, il clique en réalité sur un élément de votre site web intégré dans l'iframe. Cela peut avoir des conséquences graves, comme le vol d'informations sensibles ou la modification non autorisée de données.
Pour notre site web, nous avons autorisé l'affichage de la page dans un iframe uniquement si le site web d'origine est le même que celui de la page, avec le header suivant :
X-Frame-Options "SAMEORIGIN"Il existe une valeur DENY qui empêche complètement l'affichage de la page dans un frame ou un iframe, quel que soit le site web d'origine.
Conclusion
Les headers de sécurité sont un outil important pour protéger votre site ou application contre les attaques. Les différents serveurs web du marchés et les mesures de sécurité liées aux protocoles de communication tels que HTTP sont en constante évolutions, il est donc primordial de rester en veille sur ces sujets techniques relevant de la cybersécurité. Les headers de sécurité doivent être régulièrement mis à jour pour suivre les nouvelles menaces.
La configuration peut être faite dans le fichier de configuration de votre serveur web ou dans le code de votre application. Comme nous l'avons vu, ces configurations peuvent aider à prévenir de nombreuses attaques courantes, telles que le cross-site scripting (XSS), le clickjacking et le phishing. Certains headers de sécurité sont même requis par les réglementations, telles que le RGPD.
Pour vérifier la bonne application de vos directives de sécurité, vous pouvez utiliser le site https://securityheaders.com qui vous donne toutes les informations en un clin d’œil. Après optimisations, notre site web remonte un score de sécurité A : https://securityheaders.com/?q=https%3A%2F%2Fwww.saas-production.com%2F&followRedirects=on
