Le « typosquatting » : la menace silencieuse de la commande

Accédez directement au résumé généré par l'IA de cet article de blog

Vous avez tapé npm install un millier de fois. Vous avez sans doute aussi fait au moins une fois une faute de frappe dans le nom d’un paquet, et vous avez eu de la chance. Ce n’est pas le cas de tout le monde. Les pirates comptent sur cette seule erreur – la confiance dans la mémoire musculaire, l’appui rapide sur la touche Entrée – et c’est précisément cet écosystème de paquets qui rend le développement JavaScript si rapide qui rend le typosquatting si efficace.

Cet article explique en détail ce qu’est le « typosquatting », comment le repérer et ce que vous pouvez concrètement faire pour protéger vos projets.

Qu'est-ce que le « typosquatting » ?

Le « typosquatting » désigne la pratique consistant à publier un paquet malveillant sous un nom qui ressemble fortement à un paquet légitime et populaire, dans l’espoir que les développeurs se trompent en tapant le nom, le lisent mal, le copient à partir d’une source non fiable ou omettent de le vérifier avant de l’installer.

Voici quelques exemples courants :

Erreurs de caractères, omissions ou fautes d'orthographe: lodash devient lodahs ou loadsh
Astuces pour les traits d'union: babel-core vs babelcore
Pluralisation: couleurs vs couleur
Astuces relatives à la portée et aux espaces de noms : @types/react (un véritable package avec portée) vs un faux package sans portée types-react
Homoglyphes: remplacement d’une lettre minuscule l par un I, ou en utilisant d’autres caractères qui s’y ressemblent

Une fois installés, ces paquets peuvent faire tout ce qu’un véritable paquet npm est capable de faire : lire les variables d’environnement, exfiltrer fichiers .env ou des clés SSH, installer des portes dérobées ou injecter discrètement du code malveillant dans le résultat de votre compilation. Comme les scripts du cycle de vie npm peuvent s’exécuter pendant l’installation, les dégâts peuvent se produire avant même que vous n’ayez eu l’occasion d’examiner le code.

Le typosquatting ne se limite pas aux paquets. On le retrouve également dans les URL. Prenons, par exemple, guthub.com. Si vous avez déjà voulu taper « github.com » et que vous vous êtes retrouvé sur « guthub.com » à la place, vous avez eu de la chance : ce domaine redirige vers le vrai site. Mais cette redirection est une courtoisie mise en place par quelqu’un, pas une garantie. Quiconque enregistre une faute d’orthographe courante contrôle la destination de ce domaine, et si celui-ci appartient à un acteur malveillant, une simple faute de frappe peut vous mener vers un site clone destiné à récupérer vos identifiants. Dans l’écosystème des paquets, le danger est encore plus direct, car ce type d’erreur peut introduire du code exécutable directement dans votre projet.

Pourquoi JavaScript en particulier ?

Ce phénomène n'est pas propre à JavaScript, mais l'écosystème npm constitue une cible particulièrement attractive. Le registre est gigantesque, de nombreux paquets sont gérés par de petites équipes ou des particuliers, et les arborescences de dépendances modernes peuvent compter des centaines, voire des milliers de paquets en profondeur en raison des dépendances transitives imbriquées. Si l'on ajoute à cela la facilité de publication et le caractère informel de l'installation des dépendances (qui se fait souvent à la va-vite, d'un simple coup d'œil), le typosquatting dispose d'un terrain propice à sa réussite.

Ce risque est le même quel que soit le gestionnaire de paquets utilisé. Seule la commande change :

yarn add nom_du_paquet
pnpm add nom_du_paquet
bun add nom_du_paquet

Que vous utilisiez du fil, pnpmou bun, la syntaxe diffère de celle de npm : ces trois outils utilisent add au lieu de install. Mais ils puisent tous dans la même source – le registre npm – ; ainsi, la commande change, mais le problème de confiance reste le même. Un paquet mal saisi ou injecté de manière malveillante peut s’introduire dans votre projet, quel que soit le gestionnaire que vous utilisez, même si vous ne tapez jamais vous-même « npm install ».

De plus, npm ne révoque pas l’accès à la publication d’un responsable simplement parce que son compte reste inactif, et l’attaque contre Mastra de juin 2026 a montré ce que cela permettait. Les attaquants ont pris le contrôle du compte d’un ancien contributeur de Mastra dont l’accès à l’espace @mastra n’avait jamais été révoqué, puis ont injecté easy-day-js — lui-même un typosquat de la célèbre bibliothèque dayjs — dans plus de 140 paquets Mastra. Un espace de confiance s’est ainsi transformé en vecteur de diffusion d’une dépendance malveillante ressemblant à s’y méprendre à l’originale.

Comment identifier un paquet victime d'un « typosquatting »

Les signaux d'alerte ne sont pas toujours évidents, mais quelques vérifications peuvent vous aider à repérer un colis suspect avant qu'il n'entre dans votre projet :

Consultez le nombre de téléchargements et l'historique des publications. Un paquet se présentant comme une bibliothèque « populaire », mais qui ne compte que quelques centaines de téléchargements et dont la date de publication remonte à la semaine dernière, est un signal d’alerte. Comparez-le aux statistiques du véritable paquet sur npmjs.com.

Vérifiez qui est le responsable du projet. Le compte de publication correspond-il aux responsables connus du véritable projet ? Un compte tout nouveau, un responsable inconnu ou un paquet sans historique de publication significatif mérite qu'on y jette un second coup d'œil.

Lisez attentivement le fichier package.json. Vérifiez l'URL du dépôt, la licence et la description. Les « typosquats » copient souvent ces champs directement depuis le package légitime, mais il arrive parfois que le lien vers le dépôt pointe vers une destination inattendue, voire qu'il soit tout simplement absent.

Vérifiez les scripts d'installation avant leur exécution. Vérifiez les scripts d'installation avant leur exécution. préinstallation, installet postinstall du fichier package.json méritent une attention particulière, car ils peuvent exécuter du code pendant l’installation. Si une simple bibliothèque utilitaire intègre un script « postinstall » obfusqué qui accède à une URL distante, considérez cela comme un signal d’alerte sérieux : c’est exactement ainsi que la dépendance « easy-day-js » a fonctionné lors de l’attaque Mastra, en récupérant et en exécutant une charge utile de deuxième étape.

Utilisez la fonction officielle de recherche dans le registre, ne vous fiez pas à une supposition. Rechercher npmjs.com, copiez la commande d'installation à partir de la documentation officielle du projet, ou fiez-vous à la fonction d'autocomplétion de votre IDE plutôt que de taper de mémoire des noms de paquets que vous ne connaissez pas. La mémoire musculaire est utile jusqu'à ce qu'elle vous fasse installer le mauvais paquet.

Soyez attentifs aux modifications de dernière minute concernant les dépendances. Si un fichier package-lock.json ou yarn.lock , ou pnpm-lock.yaml Si la commande `diff` révèle un changement de nom de dépendance auquel vous ne vous attendiez pas, arrêtez-vous et examinez la situation avant de fusionner. Il en va de même pour tout paquet nouvellement ajouté que personne au sein de l'équipe n'a introduit intentionnellement.

Des solutions pratiques pour votre projet

La vérification manuelle est utile, mais elle ne suffit pas à elle seule. La meilleure approche consiste à intégrer des mesures de protection structurelles dans la manière dont votre équipe installe, vérifie et met à niveau les dépendances :

Verrouillez vos dépendances. Validez votre fichier fichier package-lock.json ou yarn.lock et utilisez npm ci dans les pipelines CI/CD au lieu de npm install. Cela garantit que les builds utilisent exactement les versions que vous avez validées, et non celles qui sont disponibles au moment de l'installation.

Utilisez des outils d'analyse automatisés. npm audit, Snyk, Socket et GitHub Dependabot — regroupés sous le nom d’outils d’analyse de la composition logicielle (SCA) — peuvent signaler des vulnérabilités connues, des paquets malveillants et des scripts d’installation inattendus. Socket, en particulier, est spécialement conçu pour détecter les risques liés à la chaîne d’approvisionnement, tels que le typosquatting et les hooks post-installation malveillants. Aucun de ces outils ne détecte tout, mais ensemble, ils offrent à votre équipe de bien meilleures chances de repérer les risques avant qu’ils n’atteignent l’environnement de production.

Fixez les versions exactes des dépendances critiques. Évitez d'utiliser des plages SemVer trop larges (^ ou ~) pour les paquets impliqués dans des opérations sensibles, afin qu'une mise à jour automatique ne puisse pas introduire silencieusement une version compromise. Le verrouillage permet également de garantir la cohérence du comportement des paquets entre les équipes, les environnements et les pipelines CI/CD.

Désactivez les scripts par défaut lorsque cela s'avère judicieux.

Désactivez les scripts par défaut lorsque cela s'avère pertinent. Exécutez les installations avec l'option –ignore-scripts dans l’environnement de CI, puis en ajoutant explicitement à la liste blanche les paquets qui nécessitent légitimement des étapes de compilation, permet de limiter l’impact d’un hook post-installation malveillant. pnpm mérite également d’être pris en compte ici : depuis la version 10, il bloque par défaut les scripts liés au cycle de vie des dépendances et vous oblige à les approuver via une liste blanche.

Exécution npm install –ignore-scripts dans l’environnement de CI, puis d’ajouter explicitement à la liste blanche les paquets qui ont légitimement besoin de scripts d’installation, permet de limiter l’impact d’un hook post-installation malveillant. C’est un excellent cas d’utilisation pour pnpm. Pnpm ignore les scripts d’installation par défaut depuis la version 10. Vous pouvez utiliser l’option –ignore-scripts en ligne de commande, ou le fichier .npmrc et au niveau global.

Adoptez un registre privé ou un proxy. Des outils tels que Verdaccio, Sonatype Nexus, JFrog Artifactory ou les fonctionnalités de registre privé de npm permettent aux équipes de répliquer, d’approuver et de contrôler les paquets avant qu’ils ne soient mis à la disposition des développeurs. Cela vous offre un point de contrôle où les paquets suspects peuvent être bloqués avant même d’atteindre la machine d’un développeur.

Examinez les nouvelles dépendances dans le cadre de la révision du code. Considérez l’ajout d’un nouveau paquet comme vous le feriez pour l’arrivée d’un nouveau contributeur ayant accès à votre base de code, car d’un point de vue fonctionnel, cela revient pratiquement au même. Élaborez une politique de sécurité définissant les modalités d’approbation des nouveaux paquets, les éléments que les réviseurs doivent vérifier et les sources à partir desquelles votre équipe est autorisée à effectuer des installations. Des outils tels que SecureChain peuvent faciliter cette démarche en fournissant aux équipes une source sélectionnée de paquets open source validés.

Sensibilisez votre équipe. Une conversation de cinq minutes sur les techniques de typosquatting peut éviter un incident coûteux. Intégrez-la à la formation initiale de tout collaborateur dont les fonctions impliquent l’utilisation du fichier package.json. Élaborez une politique d'équipe, veillez à y inclure les contrôles de sécurité parmi les priorités absolues, et assurez-vous qu'elle soit respectée.

Une petite liste de contrôle mentale

Avant d'ajouter TOUTE nouvelle dépendance, demandez-vous :

Est-ce bien le nom que je voulais vraiment taper ?
Le nombre de téléchargements et l'historique des publications semblent-ils fiables ?
Le dépôt source correspond-il à un projet que je reconnais ou que je peux vérifier ?
Existe-t-il des scripts d'installation, et est-ce que je comprends leur fonctionnement, leur raison d'être et s'ils sont nécessaires ?
Mon outil d'analyse a-t-il détecté quelque chose ?

Réflexions finales

Le « typosquatting » est efficace car il exploite la confiance et la routine, deux éléments sur lesquels les développeurs s'appuient en permanence. La bonne nouvelle, c'est que pour réduire ce risque, il n'est pas nécessaire de revoir entièrement votre flux de travail.

Passer de la mémoire musculaire à l'utilisation de noms de paquets vérifiés, d'arborescences de dépendances verrouillées, d'analyses automatisées, de registres approuvés et à faire preuve d'un scepticisme salutaire avant chaque nouvelle installation permettra de réduire considérablement cette surface d'attaque.

Résumé