Guide sur la sécurisation des appels API dans un environnement WordPress

Introduction : deux directions, deux problèmes distincts

On parle de « sécurité de l'API » comme s'il s'agissait d'un seul sujet. Il y en a deux, et les confondre est la cause de la plupart des erreurs :

ENTRANT : ce que le monde peut demander à votre WordPress   → API REST, webhooks
SORTANT : ce que votre WordPress demande au monde           → clés, prestataires, IA

L'entrant est un problème de permissions : qui peut demander quoi. Le sortant est un problème de secrets : où vit la clé et qui peut la lire. Cet article traite les deux, en commençant par celui qu'on néglige le plus.

1. Sortant — où vit la clé

C'est le point qui annule tout le reste si on le rate.

Jamais dans un fichier versionné. Une clé dans un dépôt reste dans l'historique même si on l'efface ensuite. La révocation est la seule solution réelle : changer le fichier ne suffit pas.

Jamais dans le code d'un thème. Un thème se copie, se partage, se déploie en préproduction, s'envoie à un prestataire.

Jamais dans du JavaScript côté client. Une clé qui arrive dans le navigateur est une clé publique. Cette erreur est plus fréquente qu'il n'y paraît parce qu'elle « fonctionne » parfaitement.

Dans une variable d'environnement du serveur, ou dans le coffre à secrets de votre hébergement. Et avec une règle organisationnelle qui vaut autant que la technique : une clé par client et par usage. Une clé partagée rend toute imputation impossible, et un dépassement devient anonyme.

Ce dernier point est aussi ce qui rend le budget lisible — le raisonnement complet est dans optimiser le budget de votre agence avec une clé API personnelle.

2. Sortant — ce qu'il faut vérifier à chaque appel

• Un délai d'attente explicite. Sans lui, un prestataire lent bloque votre page. C'est la cause la plus courante de « le site est tombé » alors qu'il attendait une réponse.
• Un plafond de dépense chez le prestataire, par clé. C'est une garantie structurelle : elle tient même si un traitement automatique part en boucle. Aucun engagement contractuel ne donne cela, parce qu'il agit après coup.
• Une limite de fréquence de votre côté, pour qu'une boucle mal fermée coûte un incident et non un mois de budget.
• Aucune donnée inutile envoyée. La mieux protégée est celle qui n'est pas sortie : si le traitement n'a besoin que du texte d'un produit, il n'a pas besoin du nom du client. C'est le principe développé dans pourquoi la confidentialité des données est votre meilleure alliée.
• Aucun secret dans les journaux. Un message d'erreur qui recopie la requête complète écrit votre clé dans un fichier qui se conserve et s'envoie parfois à un tiers.

3. Entrant — l'API REST, et ce qu'elle expose par défaut

WordPress expose une API REST active par défaut. Ce n'est pas un défaut, mais il faut savoir trois choses :

1. Certaines routes sont publiques par conception, et quelques-unes révèlent la liste des auteurs du site, c'est-à-dire des noms de compte utilisables pour une attaque de mot de passe. Restreindre cette route coûte quelques lignes.
2. Chaque extension peut ajouter ses propres routes. Votre surface entrante grandit à chaque installation, sans que personne ne la regarde. C'est un argument de plus pour auditer ses extensions.
3. Une route personnalisée sans vérification de capacités est ouverte à tout le monde. C'est l'erreur classique de l'extension écrite sur mesure : on contrôle le nonce, on oublie la capacité. Le nonce prouve l'origine de la requête, pas le droit de l'exécuter. Il faut les deux.

4. Entrant — les webhooks

Un webhook est une URL publique qui exécute du code. Trois règles, et aucune n'est facultative :

• vérifier la signature envoyée par l'émetteur, systématiquement. Sans vérification, quiconque connaît l'URL peut déclencher le traitement ;
• rendre le traitement idempotent : le même événement reçu deux fois ne doit pas produire deux effets. Les prestataires renvoient, c'est normal ;
• répondre vite et travailler ensuite. Un webhook qui exécute un traitement long avant de répondre provoque des renvois, et les renvois provoquent des doublons.

5. Les cinq erreurs qu'on trouve partout

1. La clé côté client — ça marche, et c'est public.
2. Le nonce sans la capacité — on contrôle l'origine, pas le droit.
3. La clé partagée entre clients — imputation impossible, révocation impossible sans affecter tout le monde.
4. Pas de délai d'attente — la panne du prestataire devient la vôtre.
5. Le secret dans les journaux — écrit une fois, conservé des mois.

6. Le protocole, en une page

• Aucune clé dans un dépôt versionné, dans un thème ou dans du JavaScript client
• Une clé par client et par usage, en variable d'environnement ou en coffre à secrets
• Plafond de dépense fixé chez le prestataire, par clé, avec une alerte intermédiaire
• Délai d'attente explicite sur chaque appel sortant
• Limite de fréquence sur les traitements automatiques
• Routes REST personnalisées : nonce et vérification de capacités, sans exception
• Webhooks : signature vérifiée, traitement idempotent, réponse rapide
• Journaux relus : aucun secret, aucune requête complète recopiée
• Procédure de révocation écrite — et testée une fois, pas supposée

Le dernier point est celui que personne ne fait et le seul qui compte le jour où il faut.

Conclusion

La sécurité des appels API ne repose pas sur un outil mais sur deux questions auxquelles il faut pouvoir répondre à tout moment : où vivent mes clés, et qui peut les lire ? et que peut me demander le monde sans s'identifier ?

La plupart des incidents ne viennent pas d'une attaque sophistiquée, mais d'une clé qui était là où il ne fallait pas et d'une route qui ne vérifiait pas ce qu'elle croyait vérifier.

Le test : si vous deviez révoquer toutes vos clés ce soir, sauriez-vous où elles sont et combien de temps cela prendrait ? Si vous ne pouvez pas répondre, c'est le travail à faire en premier.

Pour continuer : le durcissement avancé de WordPress, la protection proactive contre les menaces zero-day et l'approche RGPD+ et l'architecture à clé API personnelle. Nos extensions premium sont disponibles avec remboursement intégral sous 14 jours : voir le catalogue.