Sur WordPress, on pense souvent aux formulaires classiques, aux pages publiques, aux plugins “bouton magique”. Pourtant, une partie du risque se joue ailleurs, dans des points d’accès que beaucoup négligent car ils paraissent techniques. Wp-admin/admin-ajax.php en fait partie.
Ce fichier sert de https://gardewp.fr/securite-wordpress/ passerelle AJAX pour des milliers d’actions côté thème et côté plugins. Un site qui fonctionne “normalement” peut quand même être exposé si une action mal conçue est accessible à des visiteurs non authentifiés, si des vérifications de nonce sont absentes, si des paramètres ne sont pas contrôlés, ou si la même action déclenche des requêtes coûteuses de manière répétée. En matière de sécurité WordPress, c’est un sujet pratique parce que les correctifs sont souvent concrets, même quand l’architecture du site est ancienne.
Je vais détailler ce qui rend admin-ajax.php sensible, les scénarios d’attaque les plus courants, et une méthode de durcissement qui s’adapte à votre réalité (taille du site, contraintes de performance, stack hébergement).
Pourquoi admin-ajax.php attire les problèmes
Admin-ajax.php est l’endpoint utilisé par l’API AJAX historique de WordPress. Les requêtes prennent généralement la forme suivante :
- côté thème, script en JavaScript appelle un fichier via admin_url('admin-ajax.php') des paramètres action=... indiquent quel traitement côté PHP doit être exécuté selon le cas, l’action est exposée aux utilisateurs connectés, aux visiteurs non connectés, ou aux deux
La sensibilité vient de la combinaison de trois facteurs.
1) Il y a souvent beaucoup d’actions enregistrées
Chaque plugin qui expose une fonctionnalité en front ajoute potentiellement ses propres handlers via add_action('wp_ajax_...', ...) et parfois wp_ajax_nopriv_.... Plus il y a d’actions, plus l’attaque “par hasard” a des chances de tomber sur une branche mal vérifiée.2) Les paramètres sont faciles à fabriquer
Un attaquant ne fait pas appel aux scripts du site. Il envoie directement des POST, en modifiant action et les arguments. Si le code PHP s’appuie sur des suppositions (“ce paramètre est toujours présent”, “le nonce est toujours vérifié”), ces suppositions peuvent s’effondrer.3) Les protections sont souvent incomplètes
Le nonce WordPress est une bonne barrière, mais elle est fréquente mal appliquée : parfois oublié, parfois vérifié dans la mauvaise fonction, parfois contournable via une action “privilege-escalation” en chaîne. Et même quand le nonce existe, il ne résout pas tout ce qui concerne la logique applicative (droits, validation de capacité, contrôle de l’entrée, limitations de fréquence).Une fois qu’on regarde admin-ajax.php comme une surface d’API, les réflexes deviennent ceux de la sécurité applicative. Pas besoin d’être parano, mais il faut être méthodique.
Comprendre les “modes” : connecté, non connecté, et action inconnue
La première question à se poser est simple, mais décisive : quelles actions sont exposées à wp_ajax_nopriv_ ?
WordPress propose deux familles de hooks :
- wp_ajax_action : action accessible aux utilisateurs authentifiés wp_ajax_nopriv_action : action accessible aux visiteurs non authentifiés
Si vous avez des actions utiles uniquement pour le front utilisateur, il arrive qu’elles soient mises dans le mauvais camp, ou laissées en nopriv pour “simplifier”. Sur un site à trafic modéré, la différence ne se voit pas toujours. Sur un site ciblé, elle change tout.
Autre point souvent mal compris : que se passe-t-il quand action ne correspond à rien ?
Beaucoup d’implémentations ne renvoient pas une réponse uniforme, et certains plugins laissent passer des chemins de code “par défaut” (par exemple, un die() absent, ou un fallback qui appelle une fonction plus large). Le résultat, c’est parfois des erreurs loggées, parfois des comportements indirects, parfois juste une surface d’énumération. Même si l’attaquant ne gagne rien au premier essai, il apprend.C’est aussi pour cela que la journalisation est utile. Un site qui logge les erreurs PHP ou les accès suspects peut vous alerter sur des patterns répétitifs côté admin-ajax.php.
Les scénarios d’attaque les plus crédibles
Sans tomber dans la liste “hacker 101”, il y a quelques scénarios qui reviennent régulièrement en audit WordPress. Ils ne sont pas des théories, on les voit quand on passe du temps sur des bases réelles.
1) Absence ou mauvaise vérification de nonce
Le nonce, quand il est correctement vérifié, protège contre la plupart des requêtes forgées. Mais sur WordPress, beaucoup d’implémentations font l’une des erreurs suivantes :
- vérification de nonce faite après des opérations sensibles (donc trop tard) nonce vérifié mais sans vérifier les droits applicatifs (capabilities) nonce vérifié sur une action, mais une autre action liée à la même fonctionnalité ne le fait pas nonce “noyé” dans le front, alors que la route PHP accepte les paramètres sans exiger l’état attendu
Un signe classique : vous voyez dans le code des appels à check_ajax_referer quelque part, mais pas au même niveau que la logique principale.
2) Confusion entre “authentifié” et “autorisé”
WordPress distingue l’authentification et l’autorisation. Un plugin peut exécuter l’action seulement si l’utilisateur est connecté, mais oublier de vérifier la capacité à agir.
Exemple typique : une action qui met à jour un élément ou interroge des données. Le développeur pense “seulement les utilisateurs connectés peuvent”, mais l’action pourrait être appelée par n’importe quel compte connecté, y compris un compte bas niveau.
La bonne approche consiste à vérifier des current_user_can(...) sur chaque opération réellement sensible. Ce n’est pas “plus de code pour le plaisir”, c’est ce qui empêche un compte éditor, subscriber ou même un compte compromis de faire n’importe quoi.
3) Validation insuffisante des paramètres
Admin-ajax.php reçoit des paramètres dans $_POST. Si votre handler fait confiance aux valeurs, vous ouvrez des risques de type :
- injection SQL indirecte via requêtes mal préparées inclusion de fichiers via paramètres non filtrés (plus rare aujourd’hui, mais toujours possible selon le code) traversée d’identifiants (ID d’objets) sans contrôle de propriété surcharge CPU/mémoire via paramètres déclenchant des requêtes lourdes
Ce point est très concret : si une action accepte page=... ou id=... et qu’elle ne vérifie pas que l’utilisateur a le droit sur cet objet, la “sécurité WordPress” devient surtout une question d’accès aux ressources.
4) Déni de service applicatif via requêtes répétées
Même sans vulnérabilité “classique”, admin-ajax.php peut subir un déni de service applicatif. Les raisons sont simples :
- des actions déclenchent des requêtes externes ou des calculs lourds l’endpoint est accessible et facile à appeler à haute fréquence côté serveur, il n’y a pas de rate limiting, ou trop peu
J’ai vu des sites où une action AJAX censée “actualiser un petit widget” finissait par provoquer des requêtes répétées vers la base et générait des pics CPU. Quand le trafic augmente, même des requêtes “faibles” peuvent saturer.
En durcissement, vous cherchez donc aussi la maîtrise du rythme et du coût.
5) Vulnérabilités dans des plugins qui exposent trop
C’est la réalité terrain : admin-ajax.php est un hub, et les bugs viennent souvent du code des plugins ou des thèmes. Votre sécurité dépend alors de la combinaison :
- version du plugin qualité de la validation dans les handlers exposition via nopriv présence de nonce et vérification à l’endroit correct
Il arrive qu’un plugin soit “globalement sain”, mais qu’une action AJAX spécifique ait une faille. D’où l’intérêt de cartographier vos actions réellement utilisées, au lieu de faire un durcissement générique qui casse le site.
Cartographier vos actions AJAX avant de “bloquer”
Avant de mettre des règles pare-feu, ou de désactiver des endpoints, j’insiste sur une étape de cartographie. Elle évite la catastrophe la plus fréquente : casser une recherche en front, un formulaire, un compte client, ou des éléments de cache.
Concrètement, vous voulez répondre à ces questions :
- quelles actions sont appelées par le front de vos pages lesquelles sont exposées à des visiteurs non authentifiés quelles actions déclenchent des effets sensibles (modification, envoi, génération, requêtes externes) quels plugins ou thèmes enregistrent ces handlers
Une méthode pratique consiste à observer le trafic réseau sur le front (Chrome DevTools, onglet Réseau) et à relever les paramètres action. Vous pouvez aussi consulter le code pour trouver wp_ajax_ et wp_ajax_nopriv_, mais l’observation côté navigateur donne une vérité opérationnelle : ce que vos visiteurs appellent réellement.
Ensuite, vous pouvez aligner la stratégie de durcissement sur ce périmètre.
Durcir sans casser : une stratégie par couches
La sécurité de admin-ajax.php ne se résume pas à un seul réglage. Le plus efficace est une approche en couches, avec des garde-fous techniques, des contrôles applicatifs, et une protection de bord.
Côté application : nonce, capacité, validation
Le premier levier, c’est dans le code des handlers. Même si vous n’écrivez pas tout à la main, vous pouvez au moins vérifier ce qui existe.
Sur les actions exposées, vous cherchez surtout :
- un contrôle de nonce systématique quand l’action a un effet “rejouable” depuis le front une vérification des droits (capabilities) avant toute écriture ou accès à des données privées une validation stricte des paramètres attendus, avec cast et bornes
Une règle d’expérience : pour un endpoint AJAX, traitez chaque paramètre comme hostile. Si un champ s’attend à un entier, vous convertissez et vous refusez le reste. Si une action attend une liste, vous filtrez la forme.
Et si l’action est destinée uniquement aux utilisateurs connectés, vous ne laissez pas la porte nopriv ouverte.
Côté serveur : limiter le rythme et réduire le coût
Ensuite, il faut protéger le serveur contre les rafales. Vous avez plusieurs options, selon vos outils.
- Si vous utilisez un reverse proxy ou un WAF, il peut mettre des limites de fréquence par IP ou par empreinte. Si vous avez accès à la configuration web (Nginx/Apache), vous pouvez ajouter des limites sur le chemin /wp-admin/admin-ajax.php. Sur WordPress lui-même, un plugin de rate limiting ou un blocage basé sur des règles applicatives peut aider.
Le trade-off est réel : un rate limit trop agressif peut nuire à des fonctionnalités légitimes, surtout sur mobile, ou si vous avez des utilisateurs derrière des NAT d’entreprise. L’ajustement se fait sur des mesures, via logs.
Côté logique : répondre proprement et fermer les inconnus
Un autre levier sous-estimé : que renvoie votre site quand l’action demandée n’existe pas, ou quand les paramètres sont incohérents ?
Une réponse standard, sans détail interne, réduit l’utile pour l’attaquant. Côté WordPress, certaines actions finissent par déclencher des erreurs ou renvoyer des traces dans le HTML ou le JSON. Si vous contrôlez les handlers, vous pouvez renvoyer un statut d’erreur propre, et surtout arrêter immédiatement (wp_die avec un code adapté) après un échec de validation.
C’est une question de discipline, pas de panique.
Le noyau du sujet : protéger les actions exposées via wp ajaxnopriv
Le cœur du risque, dans beaucoup de sites, ce sont les actions accessibles sans authentification. Elles attirent le bruit, puis parfois des attaques ciblées.
La stratégie la plus saine consiste à :
- supprimer ou réduire les handlers en nopriv si leur usage n’est pas nécessaire exiger un nonce pour les actions qui peuvent être déclenchées depuis des formulaires ou des boutons vérifier systématiquement les permissions, même pour un “simple” endpoint de lecture, dès qu’il touche des données user
Voici un point pratique, que j’utilise en audit : je classe les actions par impact et par exposition.
Mini checklist de durcissement (actions AJAX)
- Vérifier chaque handler : nonce, et position de la vérification avant toute opération sensible Mettre une vérification current_user_can(...) avant toute écriture, et avant tout accès à une ressource privée Contrôler les paramètres reçus, cast et bornes inclus, refuser les formats inattendus Réduire au maximum les actions nopriv, ou les limiter à de la lecture non sensible si c’est justifié Ajouter une limitation de fréquence, via WAF, reverse proxy, ou mécanisme applicatif mesuré
Si vous n’appliquez que ces cinq points, dans beaucoup de cas, vous éliminez la majorité des risques “réalistes” sur admin-ajax.php.
Et si on veut bloquer carrément admin-ajax.php ?
On entend parfois une idée simple : “si admin-ajax.php est dangereux, autant le bloquer”. En théorie, on peut, mais dans la pratique c’est rarement tenable.
Pourquoi ? Parce que WordPress et ses plugins utilisent massivement admin-ajax.php pour des choses qui ne sont pas optionnelles : formulaires, statistiques, chargement dynamique, recherches, checkout, intégrations.
Bloquer au niveau du serveur a donc un effet secondaire : l’interface casse de manière partielle et parfois silencieuse. Les erreurs peuvent être seulement visibles dans la console navigateur, et vous ne savez pas immédiatement quel plugin est en cause.
À la place, je recommande souvent de protéger les actions plutôt que l’endpoint entier. Si votre infra le permet, vous créez des règles qui filtrent par paramètres, ou par patterns d’actions. Selon les outils, c’est faisable, mais demande de la prudence.
Autre compromis possible : utiliser un mécanisme qui accepte admin-ajax.php uniquement depuis les pages de votre domaine et seulement quand un nonce attendu est présent. C’est une approche plus proche de l’“intelligence applicative” que du blocage brut. Elle nécessite une bonne compréhension du comportement front, sinon vous risquez des faux positifs.
Contrôle des erreurs et des logs : repérer ce qui ne va pas
Quand vous sécurisez admin-ajax.php, vous voulez aussi des signaux. Sinon, vous appliquez des garde-fous à l’aveugle.
Un bon dispositif de logs comprend :
- logs applicatifs PHP (erreurs) journaux applicatifs WordPress si votre stack les expose logs de bord web (Nginx/Apache) pour voir fréquence, codes HTTP, latence éventuellement logs WAF (si utilisé)
L’objectif n’est pas de créer une usine à gaz. C’est de repérer les patterns.
Par exemple, si vous voyez des centaines de requêtes par minute sur admin-ajax.php avec des action aléatoires, il y a souvent un élément exposé ou une absence de réponse uniforme. Si au contraire vous voyez des requêtes volumineuses avec des paramètres identiques, ça peut être une attaque par surcharge, ou un script mal conçu en boucle côté front.
Je préfère traiter la cause plutôt que juste augmenter le cache. Et sans logs, vous traitez au feeling.
Cas concrets que j’ai rencontrés (et ce qu’on a fait)
Le “petit formulaire” qui ouvrait trop large
Sur un site vitrine avec une brique de prise de rendez-vous, le plugin ajoutait une action AJAX côté front. Le formulaire semblait fonctionner. En audit, on a découvert une action wp_ajax_nopriv_... pour laquelle la vérification de nonce n’était pas systématique. Résultat : l’action acceptait des paramètres et déclenchait une requête vers un service interne.
Ce n’était pas une exécution “administrateur”, mais ça permettait des appels non désirés et du bruit. La correction a consisté à supprimer l’exposition nopriv pour cette action, renforcer la validation des entrées, et revalider les droits côté serveur.
Le handler qui ne vérifiait pas la capacité
Sur une plateforme avec plusieurs rôles, une action AJAX permettait de mettre à jour un état. Elle était accessible aux utilisateurs connectés, mais sans vérifier que l’utilisateur était autorisé pour l’objet concerné. Un compte avec un accès limité pouvait modifier des objets qui ne lui appartenaient pas.
La correction a été double : vérifier current_user_can pour le type d’objet et contrôler la propriété ou l’association avec l’utilisateur. On a aussi ajouté un message d’erreur JSON cohérent quand le contrôle échoue.
Le risque “performance” après un pic
Sur un e-commerce, une action AJAX servait au rafraîchissement d’un filtre. Pendant une campagne promo, la requête était appelée en boucle, et chaque requête déclenchait une requête coûteuse. Les logs côté serveur montraient une montée CPU, pas une faille au sens strict.
La protection a été une combinaison de rate limiting et d’ajustement applicatif : réduire la granularité des requêtes, mettre en cache ce qui pouvait l’être, et limiter le nombre de refresh consécutifs côté logique serveur.
Ces cas sont importants parce qu’ils montrent que la sécurité WordPress sur admin-ajax.php ne touche pas seulement les vulnérabilités “exploitables”, elle touche aussi la stabilité.
Comment vérifier concrètement que vos protections fonctionnent
Après modifications (code, règles, rate limiting), il faut valider sans casser. L’approche qui marche bien :
- Utiliser le navigateur et vérifier les fonctionnalités liées à l’AJAX (boutons, filtres, formulaires) sans erreurs console. Tester depuis une session non authentifiée là où vous l’autorisez, et depuis une session authentifiée là où c’est censé. Vérifier que les requêtes échouent de manière propre quand les paramètres sont faux, ou quand le nonce est manquant.
Si vous faites des changements côté serveur, je conseille de surveiller simultanément : Le taux de codes 4xx sur admin-ajax.php, La latence moyenne, Et les logs erreurs PHP.
Quand tout va bien, vous observez généralement une baisse des requêtes “inutiles” ou un comportement constant. Quand ça va mal, vous voyez vite des erreurs répétées dans la console, ou des endpoints légitimes bloqués.
Pièges fréquents dans la sécurisation de admin-ajax.php
Il y a quelques erreurs de “bonne intention” qu’on voit souvent.
Premièrement, activer une règle de sécurité globale qui bloque certaines requêtes, sans comprendre quels plugins l’utilisent. Le site semble fonctionner “sur mobile” mais pas “sur desktop”, ou inversement, parce que des scripts conditionnels chargent différemment.
Deuxièmement, faire une vérification nonce, mais oublier que l’action peut aussi être appelée autrement. Exemple : un plugin peut exposer la même logique via plusieurs actions, et seule une branche a été protégée.
Troisièmement, renforcer les checks sans corriger la validation des paramètres. On ajoute une vérification de capacité, mais si le paramètre sert à construire une requête dangereuse, la faille peut rester.
Enfin, on surestime parfois les protections “externes”. Un WAF peut réduire le bruit, mais il ne remplace pas un handler qui refuse les mauvais formats et qui contrôle les droits.
Mettre ça en place sur un site existant : ordre d’action réaliste
Pour éviter de faire une “sécurité au hasard”, je propose un ordre pragmatique, compatible avec des sites réels.
D’abord, identifiez les actions réellement utilisées par le front et repérez lesquelles sont en nopriv. Ensuite, assurez que celles à effet sensible ont nonce et vérification de droits, et que les paramètres sont validés. Ensuite seulement, ajoutez un rate limiting et une protection au bord (WAF ou reverse proxy), en ajustant selon les logs.
Si vous faites dans le sens inverse, vous bloquez ou ralentissez peut-être des requêtes légitimes, puis vous passez du temps à réparer. À l’inverse, si vous commencez par l’application, vous stabilisez la base de sécurité, puis vous “durcissez” l’infrastructure.
Réduction de surface : privilégier ce qui est maintenable
Un dernier angle, souvent négligé, c’est la maintenabilité.
Chaque action AJAX que vous laissez exposée, surtout en nopriv, ajoute un coût de maintenance. Les plugins évoluent, des développeurs changent des paramètres, le front se met à appeler un autre endpoint. Si votre politique est de réduire l’exposition et de standardiser la validation, vous diminuez le risque de régression.
Si vous avez un thème ou des plugins maison, vous pouvez adopter des patterns stables : Nonce vérifié tôt, Droits vérifiés avant toute opération, Validation stricte, Et réponse JSON uniforme.
C’est moins “spectaculaire” qu’un gadget sécurité, mais c’est ce qui tient dans le temps. En sécurité WordPress, le long terme est souvent plus important que l’enthousiasme du moment.
Une protection efficace se voit dans les métriques
Quand admin-ajax.php est bien protégé, vous ne le ressentez pas seulement comme un “sentiment de sécurité”. Vous voyez des choses :
- moins de requêtes avec des action aléatoires moins de pics CPU lors de périodes de trafic des erreurs contrôlées, sans traces internes inutiles des fonctionnalités AJAX qui continuent à marcher sans contorsion
Ce sont des signaux concrets. Et ils justifient le temps passé à cartographier les actions, à corriger les validations et à mettre des garde-fous adaptés.
Protéger wp-admin/admin-ajax.php, c’est traiter WordPress comme une application avec des points d’entrée. Pas comme un simple CMS. C’est précisément là que la sécurité WordPress gagne en efficacité, sans ruiner l’expérience utilisateur.