Une clé API apparaît sur votre site : suffit-il de l’effacer ?

Le nom de variable ne dit pas ses droits

Supposons qu’une page créée avec l’IA appelle un service d’e-mail depuis le navigateur. Son JavaScript contient API_KEY. Ce nom ne suffit pas à prouver une faille. Consultez la documentation : identifiant public, clé client restreinte ou secret autorisant des actions ? N’essayez pas un identifiant appartenant à un autre site. C’est un exemple, pas un incident rapporté.

Pour votre service, demandez au propriétaire du compte de vérifier type et droits dans la console. Notez l’URL du script et l’heure de découverte sans copier la valeur complète dans un e-mail, ticket ou échange avec une IA. Masquez-la aussi dans les captures.

Couper l’accès avant de nettoyer les copies

Si le secret est réellement exposé, organisez rapidement sa révocation ou son renouvellement avec son propriétaire. GitHub place également cette étape avant le nettoyage de l’historique. Reconstruire la page supprime un chemin de diffusion, sans empêcher l’usage d’une copie antérieure.

Le remplacement doit rester côté serveur, dans un stockage adapté, avec les opérations nécessitant ce secret. Vérifiez que le build ne l’insère pas à nouveau dans les fichiers publics : une variable d’environnement peut être intégrée au code client. Si la fonction ne peut pas fonctionner sûrement pendant le changement, convenez d’une suspension temporaire plutôt que d’exposer une nouvelle clé.

Une facture stable ne clôt pas l’enquête

Examinez les journaux d’usage et d’audit disponibles pour la période d’exposition possible. Distinguez ce que la clé autorisait de ce que les traces montrent. Une facture calme ne prouve pas l’absence d’accès aux données ; des logs manquants limitent la vérification. Transmettez les indices d’usage non autorisé au processus de réponse du propriétaire.

Inventoriez les copies contrôlées par l’équipe : scripts déployés, caches CDN, dépôts, builds et documents de dépannage partagés. Coordonnez le nettoyage de l’historique : le réécrire affecte les collègues et n’efface pas leurs clones. Restreignez et expurgez le dossier d’incident.

Vérifier après le changement

Avec votre propre compte autorisé, confirmez la révocation de l’ancien accès et les seuls droits nécessaires du nouveau. Vérifiez l’absence de secret dans les fichiers livrés au navigateur, puis le fonctionnement normal. Notez version et heure. Ne générez pas de frais tiers pour démontrer l’impact.

Un contrôle externe peut repérer un identifiant visible ; analyse des logs fournisseur, renouvellement, revue du code et réponse à incident sont des travaux distincts. Le forfait public Mingxi ne les inclut pas et ne certifie pas qu’une clé n’a jamais été utilisée. Gardez les points non vérifiés dans la transmission.

Liste pratique

• Confirmer le type de clé avec son fournisseur et propriétaire.
• Révoquer ou renouveler rapidement un secret exposé.
• Examiner les logs disponibles et masquer les preuves sensibles.
• Vérifier le déploiement et la fonction normale.

Question fréquente

Faut-il retirer toute clé visible dans JavaScript ?

Non. Des clés client sont publiques par conception. Respectez les exigences du fournisseur concernant droits et restrictions. Un identifiant publiable ne se traite pas comme un secret serveur.