Restreindre wp-admin par IP ou authentification HTTP sans casser admin-ajax

Restreindre l’accès à l’espace d’administration de WordPress à une poignée d’adresses IP ou derrière une authentification supplémentaire réduit considérablement la surface d’attaque : un robot qui ne peut même pas atteindre wp-login.php ne peut pas tenter de force brute dessus. Le piège classique, que nous avons vu casser plus d’un site en production, consiste à restreindre wp-admin dans son ensemble sans exclure admin-ajax.php, un fichier techniquement situé dans ce dossier mais sollicité en permanence par la partie publique du site.

Ce fichier gère les appels asynchrones utilisés par de nombreuses extensions et thèmes pour des fonctionnalités visibles de tous les visiteurs : formulaires de contact, filtres de panier, compteurs, commentaires en direct. Le bloquer casse ces fonctionnalités sans qu’aucun message d’erreur explicite n’oriente vers la cause réelle.

Restriction par adresse IP sous nginx

Pour une équipe travaillant depuis des adresses IP fixes ou un VPN d’entreprise, la restriction par IP reste la solution la plus simple :

location /wp-admin/ {
    satisfy any;
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny all;

    location = /wp-admin/admin-ajax.php {
        allow all;
    }

    try_files $uri $uri/ /index.php?$args;
}

Le bloc interne dédié à admin-ajax.php doit être déclaré après le bloc général pour que nginx l’applique en priorité sur cette ressource précise, tout en conservant la restriction pour le reste du dossier.

Restriction par adresse IP sous Apache

La même logique s’exprime, sous Apache 2.4 et versions ultérieures, via un fichier .htaccess déposé dans wp-admin :

<RequireAny>
    Require ip 203.0.113.10
    Require ip 198.51.100.0/24
</RequireAny>

<Files "admin-ajax.php">
    Require all granted
</Files>

Authentification HTTP basique pour les équipes nomades

Quand l’équipe travaille depuis des adresses IP changeantes (télétravail, déplacements, connexions 4G), la restriction par IP devient vite contraignante. Une authentification HTTP basique, qui demande un identifiant et un mot de passe supplémentaires avant même d’atteindre l’écran de connexion WordPress, offre une alternative pratique :

<Files "admin-ajax.php">
    Require all granted
</Files>

AuthType Basic
AuthName "Zone restreinte"
AuthUserFile /chemin/hors/webroot/.htpasswd
Require valid-user

Le fichier .htpasswd se génère avec l’utilitaire htpasswd fourni par Apache, et doit impérativement être stocké en dehors du dossier accessible publiquement par le serveur web :

htpasswd -c /chemin/hors/webroot/.htpasswd nom-utilisateur

Sous nginx, l’équivalent s’appuie sur la directive auth_basic combinée à un fichier généré avec htpasswd ou l’utilitaire openssl passwd.

Vérifier que rien n’est cassé après la mise en place

• Tester un formulaire de contact ou tout élément dynamique du site public qui appelle habituellement admin-ajax.php.
• Vérifier que l’éditeur de blocs, qui effectue des sauvegardes automatiques via des requêtes vers l’API REST ou admin-ajax.php selon les extensions installées, continue de fonctionner normalement pour les rédacteurs.
• Contrôler que les webhooks entrants d’éventuelles extensions de paiement ou de formulaire, qui passent parfois eux aussi par admin-ajax.php, ne sont pas bloqués par erreur.

Les limites de cette protection

Restreindre l’accès à wp-admin ferme une porte côté réseau, mais ne remplace jamais un mot de passe solide pour les comptes qui franchissent malgré tout cette première barrière.

Cette restriction ne protège que l’espace d’administration classique : elle ne couvre pas les points d’entrée de l’API REST situés hors de wp-admin, ni une éventuelle faille dans le site public lui-même. Elle reste une couche de défense supplémentaire, particulièrement efficace contre les tentatives automatisées, et non une solution complète à elle seule.

En résumé

Restreindre wp-admin par IP ou par authentification HTTP réduit fortement l’exposition aux tentatives de connexion automatisées, à condition de toujours exclure explicitement admin-ajax.php de la restriction. Le choix entre IP fixe et authentification supplémentaire dépend avant tout de la mobilité de l’équipe qui administre le site au quotidien.