Clés API et secrets en dur dans le code
Une clé API, un token, ou un mot de passe écrit directement dans un fichier .tsx ou .js plutôt que dans une variable d'environnement finit dans le JavaScript public dès que ce fichier fait partie du bundle client.
Le cas particulier des clés AWS
Une clé d'accès AWS (préfixe AKIA ou ASIA) exposée peut donner accès à des buckets S3, des bases de données, ou toute autre ressource selon les permissions IAM associées — un scan automatisé la traite toujours comme critique, quel que soit le contexte.
Le correctif
Déplace toute clé secrète vers une variable d'environnement côté serveur — jamais préfixée NEXT_PUBLIC_ (ou VITE_), qui indique explicitement au bundler de l'inclure dans le code client.
// Mauvais — finit dans le bundle client
const apiKey = "sk-abc123...";
// Bon — variable serveur uniquement
const apiKey = process.env.SOME_SECRET_KEY;Pour les clés AWS spécifiquement, préfère des identités temporaires (STS) avec permissions minimales plutôt que des clés d'accès statiques, même côté serveur.
Ce qui ne compte pas comme une fuite
Certaines valeurs ressemblent à des secrets mais sont publiques par design : la clé anon Supabase, la clé publique Stripe (pk_live_), et la config apiKey de Firebase — leur sécurité repose sur des règles côté serveur (RLS, Security Rules), pas sur le secret de la valeur elle-même.
Vérifie si ton site est concerné par cette faille.
Scanner mon app