Des bots automatisés scannent en permanence GitHub, npm et les magasins d'applications à la recherche de clés API, et ils agissent souvent en quelques minutes après une fuite. Pour une app React Native, une clé peut fuir de deux façons : commitée dans le dépôt Git, où les bots la trouvent presque instantanément, ou embarquée dans le bundle livré, où n'importe qui peut l'extraire. La règle est simple : toute clé qui a été exposée doit être considérée comme compromise, donc révoquée et régénérée immédiatement. La meilleure défense est de ne jamais la committer et de sortir les secrets du bundle.
Réponse rapide
Les attaquants font tourner des robots qui parcourent en continu les dépôts publics et les paquets pour extraire les clés grâce à des motifs et à l'analyse d'entropie. Selon le rapport State of Secrets Sprawl 2026 de GitGuardian, 28,65 millions de nouveaux secrets ont été ajoutés à des commits GitHub publics en 2025. Ces bots exploitent souvent une clé en quelques minutes, donc une clé exposée est une clé compromise. GitHub propose du secret scanning et la push protection pour bloquer un push contenant un secret. Si une clé a fuité, révoquez-la immédiatement ; ne vous contentez pas de la retirer de l'historique.
Comment fonctionnent les bots qui scannent les clés
Ces bots automatisent ce qu'un attaquant ferait à la main, mais à l'échelle de tout GitHub. Ils surveillent le flux public des commits en temps réel, appliquent des expressions régulières correspondant aux formats de clés connus, comme AWS, Google ou Stripe, et mesurent l'entropie des chaînes pour repérer des jetons aléatoires. Dès qu'une correspondance apparaît, la clé est collectée et testée automatiquement.
L'important est que ce processus est continu et instantané. Les bots ne « visitent » pas votre dépôt de temps en temps ; ils écoutent le flux d'événements public de GitHub, donc un commit avec une clé est vu presque au moment où il est poussé. Le même principe s'applique aux paquets npm publiés, aux images Docker et aux gists. Une visibilité publique, même brève, suffit largement.
À quelle vitesse une clé exposée est-elle exploitée ?
Très vite : l'exploitation se compte en minutes, pas en jours. Des expériences de type pot de miel, où des chercheurs publient volontairement des clés, montrent régulièrement des tentatives d'utilisation quelques minutes après le push. Le temps de vous rendre compte de l'erreur et de préparer un correctif, la clé a souvent déjà été testée, voire utilisée.
C'est pourquoi la vitesse de réaction prime sur tout le reste. Retirer le commit fautif ne sert à rien si la clé a déjà été collectée, car elle reste valide. La seule action qui compte réellement est de révoquer et régénérer la clé, ce qui invalide la copie que le bot a récupérée. Considérez chaque seconde d'exposition comme suffisante pour qu'une clé soit perdue.
Deux surfaces d'exposition : le dépôt Git et le bundle
Pour une app React Native, une clé peut fuir par deux surfaces bien distinctes, et il faut traiter les deux. La première est le dépôt Git : une clé écrite en dur, un fichier .env commité, ou un secret dans un script de CI. C'est la cible privilégiée des bots, car elle est lisible directement dans le code source public.
La seconde surface est le bundle livré. Même si votre dépôt est privé, une clé intégrée dans le bundle JavaScript se retrouve dans l'app distribuée, où n'importe qui peut l'extraire en décompilant l'APK ou l'IPA. Le tableau suivant compare les principales surfaces.
| Surface | Comment la clé fuit | Qui l'exploite |
|---|---|---|
| Dépôt Git public | Clé en dur, .env commité, secret de CI | Bots de scan de dépôts, en minutes |
| Historique Git | Clé retirée mais présente dans un ancien commit | Bots parcourant l'historique |
| Bundle de l'app | Variable intégrée en clair au moment du build | Toute personne décompilant l'APK ou l'IPA |
| Paquet npm publié | Secret inclus dans un paquet public | Bots scannant les registres publics |
Beaucoup d'équipes sécurisent une surface en oubliant l'autre. Un dépôt privé impeccable ne protège pas une clé gravée dans le bundle, et un bundle propre ne protège pas une clé oubliée dans l'historique Git.
L'ampleur du problème : ce que disent les chiffres
Le phénomène est massif et s'aggrave. Le rapport State of Secrets Sprawl 2026 de GitGuardian recense 28,65 millions de nouveaux secrets codés en dur ajoutés à des commits GitHub publics durant la seule année 2025, soit une hausse de 34 % sur un an. Ce n'est pas une série de cas isolés, mais un flux constant que les bots exploitent en temps réel.
Le rapport note aussi une flambée des fuites liées aux services d'IA, en hausse de 81 %, souvent parce que des clés sont collées dans des fichiers de configuration. Pour un développeur mobile, la leçon est double : les clés fuient à grande échelle, et les nouveaux outils de développement créent de nouvelles occasions de fuite. Supposer que « ça n'arrive qu'aux autres » est statistiquement faux.
Les défenses de GitHub : secret scanning et push protection
GitHub offre deux mécanismes utiles, et vous devriez activer les deux. Le secret scanning analyse votre dépôt à la recherche de formats de clés connus et vous alerte ; pour de nombreux fournisseurs partenaires, GitHub notifie directement le fournisseur, qui peut révoquer la clé automatiquement. La push protection va plus loin : elle bloque un push qui contient un secret détecté, avant même qu'il n'atteigne le dépôt.
La push protection est particulièrement précieuse, car elle empêche la fuite au lieu de la constater après coup. Selon la documentation de GitHub, le développeur reçoit un retour immédiat lorsqu'un secret est détecté pendant un push. Activez-la sur vos dépôts, et n'utilisez la possibilité de contournement qu'en connaissance de cause, car un contournement rouvre exactement le risque que la protection élimine.
Que faire si une clé a déjà fuité
Traitez-le comme une réponse à incident, dans l'ordre. La priorité absolue est de révoquer et régénérer la clé, car c'est la seule action qui invalide la copie déjà collectée. Ensuite seulement, retirez la clé du code et de l'historique, et vérifiez les journaux du fournisseur pour repérer un usage anormal.
| Étape | Action | Priorité |
|---|---|---|
| 1 | Révoquer et régénérer la clé chez le fournisseur | Immédiate |
| 2 | Vérifier les journaux du fournisseur pour un usage anormal | Haute |
| 3 | Retirer la clé du code et de l'historique Git | Haute |
| 4 | Activer le secret scanning et la push protection | Haute |
| 5 | Sortir le secret vers un backend, ou le restreindre | Moyenne |
| 6 | Scanner le build avant la prochaine publication | Continue |
La plus grande erreur est de croire qu'effacer le commit suffit. L'historique Git conserve les anciennes versions, et de toute façon la clé a probablement déjà été copiée. Sans révocation, tout le reste est cosmétique.
Prévenir : ne jamais committer, et sortir les secrets du bundle
La prévention repose sur deux habitudes. D'abord, ne jamais committer de secret : ajoutez vos fichiers .env au .gitignore, gardez les secrets dans le coffre de secrets de votre CI, et activez la push protection pour rattraper les oublis. Un secret qui n'entre jamais dans Git ne peut pas être collecté par un bot de dépôt.
Ensuite, sortez les secrets du bundle. Les clés secrètes doivent vivre sur un backend que l'app appelle, et non être intégrées dans le code client. Les clés qui doivent rester côté client, comme une clé de cartographie, doivent être restreintes chez le fournisseur, par identifiant d'app et par quota. Ces deux habitudes ferment les deux surfaces d'exposition en même temps.
Le cas React Native : clés dans le code et dans le bundle
React Native mérite une attention particulière, car il brouille la frontière entre code et secret. Les variables d'environnement référencées dans le code sont intégrées en clair dans le bundle au moment du build, si bien qu'un simple .env ne cache rien une fois l'app livrée. Une clé « planquée » dans une constante ou un module natif reste extractible.
En pratique, cela veut dire qu'un secret dans une app React Native est exposé même si votre dépôt est privé. La bonne architecture consiste à ne mettre dans le client que des valeurs publiques et restreintes, et à confier toute opération sensible à un backend. C'est la seule approche qui résiste à la fois aux bots de dépôt et à l'extraction depuis le bundle.
Scanner le build avant publication
Même avec de bonnes habitudes, une clé oubliée finit par se glisser dans un module natif, un fichier de configuration ou une dépendance, surtout à plusieurs. Une relecture humaine ne repère pas tout, et le bundle final est justement ce que les attaquants inspectent en premier.
Un scanner comme PTKD.com analyse votre .ipa ou votre .apk et renvoie des résultats classés par gravité et alignés sur l'OWASP MASVS, y compris les secrets embarqués et les configurations réseau risquées. Soyons clairs sur ses limites : un scanner ne remplace pas la push protection côté dépôt, ni le déplacement des secrets vers un backend, et il ne juge pas si une clé publique est correctement restreinte chez le fournisseur. Ce qu'il apporte, c'est un dernier filet avant que le build n'atteigne les magasins et, avec lui, les mains des attaquants.
Ce qu'il faut retenir
- Des bots scannent GitHub et les paquets en continu et exploitent souvent une clé en quelques minutes.
- Une app React Native expose des clés par deux surfaces : le dépôt Git et le bundle livré ; sécurisez les deux.
- Une clé qui a été exposée est compromise : révoquez et régénérez d'abord, retirez-la ensuite.
- Activez le secret scanning et la push protection de GitHub, et ne committez jamais de fichier .env.
- Sortez les secrets vers un backend et scannez chaque build avec PTKD.com avant publication.
