# Comprendre les portées d’une clé API avant de la coller dans wp-config > Lecture, écriture, administration : une portée de clé API n'est jamais un détail technique secondaire. Voici comment la lire correctement avant de l'intégrer. - Auteur : WordPress Développement - Publié le : 2020-01-25 - Mis à jour le : 2020-01-25 - Catégorie : Sécurité - URL : https://www.wpmoderne.fr/securite/portees-cle-api-wp-config/ ## L’essentiel - Une portée large choisie par défaut n'est jamais un hasard commercial - Lire la documentation des scopes avant de générer une clé - Documenter la portée choisie à côté de la clé elle-même « Quelle portée souhaitez-vous accorder à cette clé ? » : cette question, posée par la plupart des tableaux de bord d'API modernes au moment de générer une nouvelle clé, est souvent traitée comme une formalité. Elle ne l'est pas. C'est le moment précis où se décide ce qu'un attaquant pourra faire si cette clé fuit un jour, que ce soit via un dépôt Git public, un fichier de configuration mal protégé ou un message d'erreur trop verbeux. Comprendre ce que recouvre réellement une portée de clé API, au-delà du nom parfois flou qui lui est donné, permet d'éviter l'erreur la plus répandue en intégration WordPress : copier la clé la plus large disponible parce qu'elle « fonctionne à coup sûr », sans se demander ce qu'elle autorise en plus de ce qui est réellement nécessaire. ## Trois niveaux de portée, trois niveaux de risque La plupart des API tierces utilisées dans un projet WordPress distinguent au moins trois familles de portées, sous des noms qui varient d'un service à l'autre. La **lecture seule** permet de récupérer des données existantes sans jamais les modifier : une clé de recherche Algolia, une clé de lecture Stripe. L'**écriture restreinte** autorise la création ou la modification de ressources précises, sans droit sur la configuration globale du compte : créer un paiement, ajouter un contact à une liste. L'**administration**, enfin, donne un accès complet : modifier les paramètres du compte, créer ou révoquer d'autres clés, accéder à la facturation. Le piège classique consiste à confondre le fait qu'une clé « fonctionne » pour un usage donné avec le fait qu'elle est appropriée à cet usage. Une clé d'administration Stripe permet de créer un paiement, exactement comme une clé restreinte à cet effet ; la différence n'apparaît que si la clé fuit, ou si un bug applicatif exécute par erreur un appel non prévu. ## Pourquoi la portée large est souvent proposée en premier Dans de nombreuses interfaces, la clé la plus permissive est celle générée par défaut ou mise en avant dans les exemples de démarrage rapide, car elle garantit que le premier test de l'intégration fonctionnera sans erreur de permission. Cette facilité initiale a un coût différé : une fois l'intégration en place et fonctionnelle, personne ne revient generalement réduire la portée de la clé, par manque de temps ou par crainte de casser quelque chose qui fonctionne. > L'essentiel à retenir : Une portée large choisie par défaut n'est jamais un hasard commercial ; Lire la documentation des scopes avant de générer une clé ; Documenter la portée choisie à côté de la clé elle-même ## Lire une documentation de scopes correctement La documentation d'un service sérieux liste ses portées disponibles avec, pour chacune, les actions précises qu'elle autorise. Il vaut mieux consacrer dix minutes à cette lecture avant de générer une clé que de découvrir après coup, en cas d'incident, ce qu'elle permettait réellement. Quelques questions simples aident à choisir la bonne portée : cette intégration a-t-elle besoin d'écrire, ou seulement de lire ? A-t-elle besoin d'agir sur toutes les ressources du compte, ou sur un sous-ensemble identifiable (un index, une liste de contacts, un webhook précis) ? Cette clé sera-t-elle exposée côté navigateur, ou reste-t-elle strictement côté serveur ? Cette dernière question change tout : une clé destinée à rester dans `wp-config.php` ou dans une variable d'environnement serveur peut légitimement porter des droits plus larges qu'une clé injectée dans un script JavaScript, visible par n'importe quel visiteur via les outils de développement du navigateur. ## Ce que révèle une revue de portées sur un projet existant Sur un projet WordPress typique cumulant cinq à dix intégrations tierces, une revue systématique des portées accordées révèle presque toujours au moins une clé plus permissive que nécessaire : un jeton HubSpot avec accès à la facturation pour un simple formulaire de contact, une clé Stripe complète pour un module qui ne fait que créer des paiements, une clé Algolia d'administration collée dans un fichier de test jamais nettoyé. Ces découvertes ne signalent pas nécessairement une négligence individuelle, mais plutôt l'absence d'un réflexe systématique : vérifier la portée d'une clé au moment de l'intégrer, puis la revérifier périodiquement, au même titre qu'on revérifie une dépendance logicielle obsolète. ## En résumé Une portée de clé API n'est pas un détail administratif à valider rapidement pour passer à l'étape suivante de l'intégration : c'est la limite exacte de ce qu'un incident pourra coûter. La règle la plus simple reste aussi la plus efficace : choisir la portée la plus étroite qui permette de faire fonctionner l'intégration prévue, jamais la plus large disponible par confort ou par habitude.