Scripts tiers

Votre page d'accueil charge des scripts que vous n'hébergez pas : un lecteur vidéo, un outil de mesure, une bibliothèque sur un CDN. Si l'un d'eux change chez son hébergeur, votre site sert du code que personne chez vous n'a relu — sans déploiement, sans erreur, avec un 200 partout. C'est le scénario de Polyfill.io en 2024, et les autres contrôles ne le voient pas : ils regardent ce que votre site fait, pas ce que ses fournisseurs lui font.

Ce que PostShip vérifie

PostShip lit le HTML de la page d'accueil du projet (jusqu'à 2 Mo, parce que les balises script d'une page marchande sont en bas) et en tire les balises script src chargées depuis une autre origine que la vôtre. Vos propres bundles ne sont pas relevés : ils changent à chaque déploiement, c'est leur rôle.

Pour chacun, PostShip télécharge le fichier complet et calcule deux empreintes :

• sha256 en hexadécimal, celle qu'on retrouve avec sha256sum ou dans l'onglet réseau du navigateur ;
• sha384 sous la forme exacte que l'attribut integrity attend, sha384-<base64>, pour qu'elle se colle sans transformation.

Un script qui répond autre chose que 200 ou qui dépasse 2 Mo est marqué « non lu » avec sa raison (« Le script répond 404. », « Plus de 2 Mo : empreinte non relevée. »). On ne juge pas ce qu'on n'a pas lu.

Jamais le contenu d'un script dans les résultats, seulement ses empreintes et sa taille.

Quand ça tourne

À chaque déploiement, comme les autres contrôles du site — et, à la différence des autres, une fois par jour sans déploiement, puisque c'est précisément un changement sans déploiement que ce contrôle cherche. Pas toutes les cinq minutes : ce sont des téléchargements de scripts entiers.

Le verdict

Au premier passage, tout est nouveau : PostShip mémorise et ne s'alarme pas. Ensuite :

• Modifié : connu, et l'empreinte n'est plus la même. C'est l'alerte.
• Nouveau : jamais vu sur ce projet. Mémorisé, sans alerte par défaut — c'est le plus souvent votre choix.
• Disparu : connu, absent du HTML de ce déploiement. Une information, pas une panne ; s'il revient, on saura s'il a changé entre-temps.

Le contrôle lui-même reste pass : un script qui change chez son hébergeur n'est pas une panne de votre site, c'est un fait à regarder. Il passe par le canal des modifications, comme le radar de mutation.

Régler

Projet → Santé → Contrôles du site → Scripts tiers. Le panneau liste chaque script avec son nom court, sa taille, le début de son sha256, et combien de fois il a été modifié.

• La balise avec integrity, prête à coller, pour chaque script lu. PostShip prévient après coup ; le navigateur, lui, empêche avant : avec l'attribut integrity, un script dont l'empreinte ne correspond plus n'est pas exécuté.
• C'était attendu : après une modification, ce bouton acquitte la dernière. La date et l'historique restent, seul l'écran change de ton.
• Me prévenir aussi quand un script tiers apparaît : une case à cocher, pour une agence qui livre un site fini et veut savoir qu'un script est apparu sans elle. Jamais au premier relevé.
• L'en-tête CSP suggéré : une directive script-src construite sur les origines réellement vues, plus 'self'. Elle complète l'attribut — integrity protège un fichier à la fois contre un CDN compromis, script-src contre un script injecté depuis ailleurs. Si la page a du script en ligne, le panneau ajoute 'unsafe-inline' et le dit.

<!-- La balise proposée par PostShip : integrity et crossorigin ensemble -->
  <script src="https://cdn.tiers.com/lib.js" integrity="sha384-…" crossorigin="anonymous"></script>

Ce qui déclenche une alerte

• 1 script tiers a changé chez son hébergeur : cdn.tiers.com/lib.js — ou, au pluriel, 3 scripts tiers ont changé chez leur hébergeur : … avec trois noms au plus, puis « et N autres ».
• Avec l'option cochée : 1 script tiers nouveau sur la page : cdn.x/w.js (deux noms au plus). Seulement si au moins un script de ce site est déjà connu.

Ce qui se tait : un script disparu, un script non lu, le premier relevé. L'alerte suit vos canaux et le réglage « Le contenu a changé après un déploiement » des notifications.

Limites et plans

Le contrôle tourne pour tout projet, hors quota d'URLs. Les alertes des contrôles du site font partie du plan Pro (voir les plans).

Dépannage

Pourquoi un script est-il marqué « non lu » ?

Il répond autre chose que 200, il dépasse 2 Mo, ou le délai du contrôle (12 s) est écoulé avant son tour. Le contrôle HTTP, lui, signale un script qui ne répond plus.

Pourquoi mon script a-t-il changé alors que rien n'a bougé chez moi ?

C'est le cas normal d'un CDN qui publie une nouvelle version sous la même URL (latest, une version majeure sans numéro de patch). Si c'est attendu, cliquez « C'était attendu » et épinglez la version dans l'URL, sinon la prochaine publication alertera encore.

Pourquoi la balise avec integrity casse-t-elle ma page ?

Soit crossorigin="anonymous" manque, soit le CDN sert un contenu différent selon le navigateur ou la région. Dans ce second cas, l'attribut ne peut pas fonctionner : gardez l'alerte PostShip, retirez l'attribut.