Clés API et secrets : les erreurs qui exposent le site d'une PME sans qu'elle s'en rende compte

Un site qui utilise un CRM, un service de paiement, une API de cartographie ou un outil d'envoi d'emails manipule presque toujours des clés d'accès, aussi appelées secrets, qui permettent à ces services externes d'identifier et d'autoriser les requêtes envoyées depuis le site. Ces clés fonctionnent comme des mots de passe, avec une différence importante : elles sont souvent copiées, partagées, et intégrées dans du code sans que personne ne s'interroge sur leur niveau de protection réel.

L'erreur la plus fréquente : la clé écrite en dur dans le code

Sur un développement PHP sur mesure, il reste courant de trouver une clé API directement écrite dans un fichier de configuration versionné avec le reste du code source. Le problème survient dès que ce code est partagé, que ce soit via un dépôt Git privé accessible à un prestataire externe, un export vers un nouveau développeur, ou pire, un dépôt qui devient accidentellement public. Une fois qu'une clé a circulé dans un historique de versions, la supprimer du code actuel ne suffit pas : elle reste consultable dans les versions précédentes tant qu'elle n'a pas été révoquée et remplacée par une nouvelle.

La bonne pratique de base : les variables d'environnement

La solution standard consiste à sortir les clés du code source et à les stocker dans des variables d'environnement, généralement via un fichier nommé .env, qui n'est jamais inclus dans le dépôt de code grâce à un fichier .gitignore qui l'exclut explicitement. Le code applicatif lit alors la clé depuis cette variable au moment de l'exécution, sans jamais l'écrire en clair dans un fichier suivi par le contrôle de version. Cette approche reste appropriée pour un développement local ou un site de taille modeste, à condition de ne jamais transmettre ce fichier par email ou messagerie instantanée, canaux qui laissent des traces difficiles à effacer complètement.

Ce que ce fichier ne protège pas

Un fichier .env correctement exclu du dépôt de code reste néanmoins présent en clair sur le serveur de production, ce qui signifie qu'un accès non autorisé au serveur, par exemple via une faille dans une extension WordPress ou un mot de passe FTP compromis, expose directement l'ensemble des clés qu'il contient. Pour un site avec des exigences de sécurité plus élevées, notamment lorsque plusieurs personnes ou prestataires interviennent sur l'infrastructure, un gestionnaire de secrets dédié, comme ceux proposés par les grands fournisseurs cloud, permet un stockage chiffré avec un contrôle précis de qui peut consulter quelle clé, ce qui dépasse ce qu'un simple fichier local peut offrir.

Le piège du frontend et du code visible par le navigateur

Une clé intégrée dans du code JavaScript exécuté côté navigateur, même dans un fichier compilé ou minifié, reste techniquement accessible à quiconque inspecte le code source de la page. C'est une erreur fréquente lorsqu'une intégration tierce est ajoutée rapidement sans faire transiter la requête par le serveur du site. La solution consiste à faire passer ces appels par un point d'entrée côté serveur, qui conserve la clé secrète et ne transmet au navigateur que le résultat nécessaire, jamais la clé elle même.

Restreindre chaque clé à son strict usage

La plupart des services proposent de limiter une clé API à un domaine précis, une plage d'adresses IP, ou un ensemble d'actions autorisées, une fonctionnalité souvent ignorée par simplicité au moment de la création de la clé. Cette restriction ne coûte rien à mettre en place et réduit fortement l'impact d'une fuite éventuelle, puisqu'une clé limitée à nikaia.net ne peut pas être réutilisée depuis un autre domaine même si elle est découverte.

Renouveler les clés, pas seulement les protéger

Une clé créée au lancement d'un projet et jamais renouvelée depuis reste un risque qui s'accumule avec le temps, en particulier lorsque plusieurs prestataires ou employés y ont eu accès au fil des années sans que la liste des personnes concernées soit tenue à jour. Un renouvellement périodique, même simple, limite la fenêtre d'exploitation d'une clé qui aurait fuité sans que personne ne s'en aperçoive.

Points à vérifier avant publication : confirmer que la description du fonctionnement des fichiers .env et de leur exclusion via .gitignore reste conforme aux pratiques standards de développement PHP à la date de publication, et vérifier que les exemples de gestionnaires de secrets cités restent des solutions couramment utilisées sur le marché.