Code source visible, clé copiée, tout compromis

Un chercheur en sécurité s'est rendu sur clickup.com. Il a ouvert le code source de la page. Il y a trouvé une clé d'API écrite en dur dans le JavaScript. Il l'a copiée. Il a envoyé une seule requête GET.

En retour : 959 adresses e-mail et 3 165 feature flags internes. Des employés de Home Depot. Fortinet. Autodesk. Tenable. Rakuten. Mayo Clinic.

Une chaîne de caractères. Une requête. Tout.

Comment cela se produit

Quelqu'un avait besoin que le frontend appelle une API. L'API exigeait une authentification. Alors il a placé la clé dans le JavaScript. On livre, on passe à la suite, sprint suivant.

Il ne s'agit pas d'une attaque sophistiquée. Pas d'exploit, pas de zero-day, pas d'ingénierie sociale. Juste view-source: et curl. Un navigateur et un terminal. Le genre de chose qu'un stagiaire curieux fait le premier jour.

La clé n'avait pas de périmètre — elle pouvait accéder à tout ce que l'API exposait. Pas de limite de débit — une seule requête a tout renvoyé. Pas de date d'expiration — la clé fonctionnait jusqu'à ce que quelqu'un s'en aperçoive. Pas de second facteur — la possession de la chaîne était la seule barrière.

L'angle financier

On parle de fuite de données. Parlons de la valeur de ces données.

959 adresses e-mail professionnelles issues de sociétés du Fortune 500. C'est une liste de cibles de spear-phishing que des acteurs malveillants paient. Des noms, des fonctions, et le fait que ces entreprises utilisent ClickUp — c'est le contexte d'ingénierie sociale qui fait fonctionner le phishing.

3 165 feature flags internes. C'est une feuille de route. Elle indique aux concurrents ce que ClickUp construit, ce qu'il teste, ce qui se trouve derrière une barrière. Elle indique aux attaquantes et attaquants quelles fonctionnalités sont à moitié construites et donc probablement vulnérables.

Il ne s'agit pas d'un incident de confidentialité. C'est une fuite de renseignement économique.

Pourquoi cela se répète

C'est le quatrième incident d'identifiant présent dans le code source que nous couvrons ce mois-ci. Les identifiants de la CLI de Bitwarden ont pu être collectés parce qu'ils figuraient dans des fichiers en clair. Les variables d'environnement de Vercel étaient déchiffrables parce que l'indicateur « sensitive » n'était pas activé par défaut. Un développeur a perdu 634 mots de passe Chrome parce que la clé de déchiffrement se trouvait sur le même disque.

Le motif est toujours le même : un identifiant existe sous forme de chaîne — dans un fichier, dans une variable, dans le code source d'une page — et quelque chose le lit. Ce « quelque chose » change. Le motif, lui, ne change pas.

Les clés d'API dans le JavaScript sont la version la plus flagrante, car aucune attaque n'est nécessaire. La clé est publiée. Elle est servie à chaque visiteur. Le navigateur la télécharge, l'affiche et la montre à quiconque fait un clic droit.

Ce qui aurait dû être différent

L'appel API n'aurait jamais dû être authentifié avec une clé statique côté client. Les options :

• Proxy backend. Le frontend appelle votre propre backend, qui conserve la clé côté serveur et transmet l'appel API. La clé n'atteint jamais le navigateur.
• Jetons limités à la session. Après authentification, le frontend obtient un jeton de courte durée et à périmètre étroit. Il expire. Il ne peut faire que ce que l'utilisateur authentifié est autorisé à faire. Ce n'est pas une clé maîtresse.
• Aucune clé. Si les données sont publiques, servez-les sans authentification. Sinon, ne les servez pas à du JavaScript non authentifié.

Écrire une clé d'API en dur dans du code côté client, c'est mettre la clé de sa maison sous le paillasson et publier son adresse.

Le problème du cycle de vie des identifiants

Cette clé ClickUp a probablement été créée une fois, collée dans un fichier JavaScript, validée dans un déploiement, envoyée en production, puis plus jamais réexaminée. Personne ne l'a renouvelée. Personne ne lui a fixé de périmètre. Personne n'a défini de date d'expiration. Personne n'a surveillé ce à quoi elle donnait accès.

C'est le cycle de vie de la plupart des clés d'API dans la plupart des organisations. Créées dans la précipitation, collées là où elles sont nécessaires, puis oubliées. Elles s'accumulent dans les bases de code, les fichiers de configuration, les chaînes CI/CD, et apparemment dans le code source des pages — chacune étant une porte qui ne se ferme jamais à clé.

La question n'est pas de savoir si votre organisation possède une clé de ce type. La question est de savoir combien vous en avez, et si vous sauriez si quelqu'un en copiait une aujourd'hui.