Bibliothèques JavaScript obsolètes : la faille que personne ne regarde

Un site peut avoir un serveur à jour, un certificat valide et tous les bons en-têtes de sécurité, et rester vulnérable à cause d'un fichier chargé depuis des années sans que personne n'y pense : une vieille version de jQuery, un plugin de carrousel abandonné, une bibliothèque de graphiques copiée depuis un tutoriel.

Ces fichiers ne cassent rien, alors ils restent. Et c'est justement le problème.

Pourquoi c'est un vrai risque#

Les failles des bibliothèques populaires sont publiques. Quand une vulnérabilité est découverte, elle est recensée dans des bases comme celle des CVE, avec la liste des versions touchées. Il suffit alors à un attaquant de repérer le numéro de version chargé par votre site, souvent visible dans le nom du fichier ou dans son en-tête, pour savoir exactement quelle attaque tenter.

Les failles les plus courantes dans ces bibliothèques sont des failles XSS : elles permettent d'exécuter du code dans le navigateur de vos visiteurs, par exemple pour voler une session ou modifier un formulaire de paiement.

Faire l'inventaire#

Première étape : savoir ce que votre site charge réellement. Dans les outils de développement du navigateur, onglet Réseau, filtrez sur « JS » et rechargez la page. Pour chaque fichier, notez la bibliothèque et sa version.

Si votre projet utilise npm, la commande suivante liste les dépendances qui ont des vulnérabilités connues :

npm audit

Et celle-ci, les paquets qui ont une version plus récente disponible :

npm outdated

Mettre à jour sans tout casser#

La crainte d'une régression est la principale raison pour laquelle on repousse les mises à jour. Quelques habitudes la réduisent beaucoup :

• mettre à jour souvent, par petites étapes : passer d'une version mineure à la suivante est rarement douloureux, rattraper cinq ans de retard l'est presque toujours ;
• lire les notes de version avant une mise à jour majeure, qui signalent les changements incompatibles ;
• tester les parcours critiques après chaque mise à jour : formulaire de contact, panier, paiement, connexion ;
• automatiser la veille avec un outil comme Dependabot ou Renovate, qui ouvre une demande de mise à jour dès qu'une nouvelle version sort.

Le cas des fichiers chargés depuis un CDN#

Charger une bibliothèque depuis un CDN public est pratique, mais vous faites alors confiance à un serveur tiers. S'il était compromis, le fichier servi à vos visiteurs pourrait être modifié. L'attribut integrity protège contre ce scénario : le navigateur vérifie l'empreinte du fichier et refuse de l'exécuter si elle ne correspond pas.

<script
  src="https://cdn.jsdelivr.net/npm/exemple@2.4.1/dist/exemple.min.js"
  integrity="sha384-…empreinte fournie par le CDN…"
  crossorigin="anonymous"></script>

Indiquez toujours une version précise dans l'adresse. Une URL qui pointe vers « la dernière version » peut changer de contenu du jour au lendemain, et l'empreinte ne correspondrait plus.

Supprimer ce qui ne sert plus#

La mise à jour la plus sûre reste la suppression. Un slider retiré de la page d'accueil il y a deux ans dont le script est toujours chargé, une bibliothèque d'animations utilisée pour un seul effet : chaque fichier en moins est une surface d'attaque en moins, et une page plus rapide.

Codanalyst détecte les bibliothèques JavaScript chargées par vos pages, identifie leur version et signale celles qui ont des vulnérabilités connues. Vérifiez votre site en une minute.