Sécuriser WordPress : protéger le dossier wp-admin et wp-login

Si votre site tourne sous WordPress, vous avez probablement remarqué un détail assez simple: une grande partie des tentatives de connexion automatiques finit, tôt ou tard, par viser wp-login.php et le répertoire wp-admin. Ce n’est pas une rumeur, c’est un schéma observé dans les journaux: la majorité des bots connaissent ces chemins, ils testent des combinaisons de mots de passe, et ils enchaînent sans relâche. Résultat, même un site bien entretenu peut se retrouver avec des charges inutiles, des sessions suspectes, et, dans le pire des cas, une tentative de prise de contrôle.

Protéger wp-admin et wp-login.php ne veut pas dire “faire disparaître WordPress”. Cela veut dire réduire la surface d’attaque, ralentir l’assaillant, augmenter l’effort requis pour réussir, et surtout rendre vos défenses plus robustes face aux erreurs humaines. L’approche la plus efficace est presque toujours un empilement raisonnable: contrôle d’accès, durcissement technique, réduction du bruit (et donc des risques), et surveillance.

Comprendre ce que vous protégez vraiment

wp-login.php est la porte d’entrée. wp-admin est la zone d’administration, avec des endpoints variés, des scripts, et des appels internes. Quand un bot tente d’attaquer, il ne vise pas seulement la connexion. Il peut chercher des erreurs d’exécution, des pages mal exposées, des plugins oubliés, ou des routes connues.

Ce qui rend wp-admin et wp-login.php particulièrement attirants, c’est leur prévisibilité. Un attaquant n’a pas besoin de “scanner” au sens classique du terme pour commencer à tenter sa chance. Il suffit de frapper les URL attendues. C’est pour cela que les mesures de protection “universelles” (même si elles sont importantes) ne suffisent pas toujours. Vous devez vous assurer que ces deux zones ne sont pas simplement “plus difficiles”, mais aussi “mieux cadrées”.

Les trois axes qui font la différence

Quand je sécurise ce type d’installation, je cherche d’abord à répondre à trois questions.

La première, c’est: qui peut atteindre wp-login.php et wp-admin depuis l’extérieur. La deuxième: que se passe-t-il quand quelqu’un tente de se connecter ou d’obtenir une ressource. La troisième: comment vous détectez rapidement ce qui ne devrait pas arriver.

Ces axes se traduisent en pratique par des actions concrètes.

Limiter l’accès par réseau ou par authentification supplémentaire. Renforcer les protections côté serveur contre le brute force et limiter l’impact des tentatives. Mettre en place une surveillance exploitable (journaux cohérents, alertes pertinentes, vérifications simples).

Renforcer l’accès: le plus rentable, quand c’est faisable

La mesure la plus efficace, et souvent la plus sous-estimée, consiste à réduire le nombre de visiteurs capables de toucher ces URLs. Il y a deux méthodes très courantes, et elles ont des avantages différents.

Restriction par IP ou géolocalisation (simple, mais à manier avec soin)

Bloquer ou restreindre wp-login.php et wp-admin à certaines plages IP, par exemple celles de votre bureau, votre VPN, ou vos serveurs d’hébergement, réduit drastiquement le bruit. C’est redoutable contre les bots de masse.

Le piège, c’est la vie réelle: vous vous connectez depuis chez vous, en déplacement, ou via une connexion mobile qui change. Si vous verrouillez trop, vous finissez par bloquer vos propres accès, et la sécurité devient une source de frustration plutôt qu’un avantage.

Mon conseil: faites une liste d’exceptions réaliste. Par exemple, si vous utilisez un VPN fixe, vous pouvez autoriser l’IP du VPN et laisser le reste sous contrainte. Si vous travaillez depuis des réseaux qui changent, limitez au maximum les restrictions strictes, et privilégiez plutôt l’authentification forte au niveau de la porte.

Authentification additionnelle via HTTP Basic (efficace, mais pas magique)

Une autre technique consiste à ajouter une authentification HTTP (Basic Auth) pour /wp-login.php et parfois pour /wp-admin. L’idée est simple: même si un bot connaît l’URL, il se heurte à une seconde barrière.

C’est utile, mais cela demande une gestion prudente des identifiants, et surtout une compatibilité avec votre navigateur et vos accès automatisés. Certains outils d’administration, ou certains reverse proxies, peuvent avoir besoin de configuration. Sur un site standard, ça passe généralement bien.

On peut aussi limiter la zone protégée. Par exemple, vous pouvez exiger Basic Auth sur /wp-login.php uniquement, et laisser wp-admin derrière la couche WordPress, en jouant sur d’autres protections pour réduire le brute force.

Si votre site tourne sur Apache, le fichier .htaccess dans le répertoire racine est un endroit classique pour appliquer des règles. Les règles les plus intéressantes ne sont pas “trop longues”, elles sont ciblées.

Vous pouvez, par exemple:

empêcher l’accès direct à certains fichiers, forcer un filtrage des requêtes, appliquer des limitations à wp-login.php et wp-admin.

Voici un principe pratique qui m’a déjà évité des soucis: plutôt que de réécrire et multiplier les règles, commencez par quelques règles très nettes et testez. Une règle mal ciblée peut casser l’administration ou déclencher des erreurs 403 inattendues.

Si vous utilisez Nginx, la logique se transpose, mais elle passe par la configuration du serveur. L’idée reste la même: interposer une couche entre “Internet” et “vos endpoints WordPress”.

Protéger contre le brute force: le duo limitation et intelligence

Même avec une restriction d’accès, vous aurez toujours des tentatives qui passent. Votre objectif est alors de réduire la vitesse et la portée des attaques répétitives.

La bonne approche consiste à combiner:

une limitation de taux (rate limiting) au niveau serveur ou via un composant, une logique de bannissement temporaire (par exemple via fail2ban), et des garde-fous côté WordPress (limitation de tentatives de connexion, verrous, etc.).

Sur beaucoup d’hébergeurs, il existe déjà une brique de “défense” (WAF, protections applicatives, règles basiques). Attention toutefois: ces protections peuvent ne pas couvrir toutes les variations d’URL ou tous les chemins utilisés par des scripts automatisés. Il faut donc vérifier dans vos logs.

Le piège fréquent: croire que “tout est bloqué” alors que seul l’écran l’est

Une erreur classique est de voir que le navigateur n’affiche pas l’erreur attendue, et d’en conclure que le bot est bloqué. Or un bot peut être ralenti mais pas stoppé, ou il peut déclencher d’autres comportements (par exemple, des réponses différents qui consomment du CPU).

Le bon réflexe: regardez dans les journaux (ou dans l’interface du reverse proxy) si la charge baisse, si le nombre de requêtes sur wp-login.php diminue, et si les échecs répétés deviennent plus rares.

Mots de passe, rôles, et 2FA: la vraie ligne de défense

Si on parle de sécurité sérieuse, aucun verrou d’accès ne remplace l’hygiène des comptes. Il y a une raison simple: un attaquant peut parfois contourner une barrière (vol d’identifiants, réutilisation, fuite, ou session déjà active). Dans ce cas, ce qui protège réellement, ce sont vos mécanismes d’authentification.

Quelques points qui font une différence immédiate:

utilisez des mots de passe uniques, longs, et impossibles à deviner, limitez le nombre de comptes administrateurs, appliquez des rôles précis et retirez les droits inutiles, activez la double authentification (idéalement une application TOTP ou une clé physique).

Côté WordPress, le fait de forcer la 2FA pour les comptes ayant accès à wp-admin est souvent un excellent compromis. Oui, cela ajoute une étape pour vous, mais c’est précisément ce qui évite le scénario “mot de passe compromis, compte pris”.

Sécuriser l’environnement WordPress qui entoure wp-admin

On se concentre souvent sur l’URL, alors que WordPress offre aussi d’autres vecteurs. Votre objectif est de réduire les “chemins” qui peuvent mener à un accès admin même si la porte d’entrée est plus difficile.

Quelques actions utiles, surtout si vous constatez dans les logs des tentatives d’exécution, d’accès à des fichiers sensibles, ou des scans:

mettez à jour WordPress, thèmes, et plugins. Les versions obsolètes restent une cible, retirez les plugins inutiles et désactivez ceux qui ne servent plus, surveillez les fichiers récemment modifiés côté serveur, évitez d’exposer des fichiers de sauvegarde, logs, ou dumps dans des répertoires accessibles.

Même si cela ne “protège” pas directement wp-admin, cela augmente vos chances de ne pas tomber sur une faille exploitable.

Réduire les surfaces associées à la connexion

Le login n’est pas que wp-login.php. Selon votre configuration, des endpoints liés à l’authentification peuvent être utilisés en attaque. Par ailleurs, certaines fonctionnalités peuvent contribuer à augmenter le bruit, par exemple l’API XML-RPC si elle est active.

Je reste prudent sur les décisions globales, parce que certaines installations en dépendent (clients tiers, outils de publication). Mais si vous n’utilisez pas ces fonctionnalités, limiter ou désactiver ce qui n’est pas requis est une stratégie cohérente: moins de chemins, moins d’occasions pour un attaquant de trouver une faille.

Une mise en place progressive: commencer par ce que vous pouvez maintenir

Les meilleures sécurisations sont celles que vous maintenez. J’ai vu des sites “durcis” avec beaucoup d’enthousiasme au départ, puis abandonnés, avec des règles obsolètes et des accès bloqués. Ce n’est pas catastrophique si vous avez un plan de reprise, mais ça devient vite pénible.

Pour éviter ça, je recommande une progression par paliers.

Checklist de durcissement ciblé (sans tout casser)

Activez une protection anti-brute force (au niveau serveur, WAF, ou plugin, mais vérifiez que wp-login.php est réellement couvert). Restreignez l’accès à /wp-login.php et, si possible, à /wp-admin via IP si vous avez un VPN ou des réseaux fixes. Ajoutez une authentification supplémentaire (HTTP Basic) sur /wp-login.php si vous ne pouvez pas restreindre par IP. Vérifiez que la double authentification est activée pour les comptes administrateurs. Assurez-vous que WordPress, thèmes, et plugins sont à jour, et supprimez ceux qui ne servent plus.

L’ordre compte. Si vous commencez par déplacer des éléments ou par modifier des règles complexes, vous compliquez le diagnostic. Si vous commencez par verrouiller le login et renforcer l’authentification, vous gagnez du temps et de la visibilité.

Comment configurer concrètement, selon votre hébergement

Je ne peux pas vous donner une configuration unique valable pour tous les serveurs, parce que l’environnement change beaucoup: Apache ou Nginx, présence d’un reverse proxy type Cloudflare ou équivalent, règles WAF déjà en place, et disponibilité d’outils comme fail2ban.

Mais je peux vous donner une méthode de décision.

Si vous êtes sur un hébergement qui gère déjà un WAF ou du rate limiting, vous pouvez d’abord renforcer votre couche WordPress (2FA, mises à jour, suppression des plugins inutiles) et ajouter une règle ciblée sur wp-login.php. Si vous avez la main sur la configuration serveur, privilégiez un contrôle propre au niveau web server (authentification, restriction IP, limitations). Si vous n’avez pas accès au serveur, concentrez-vous sur le reverse proxy et sur des protections applicatives (taux de tentatives, limitation login, règles de blocage).

Dans tous les cas, l’objectif est de réduire les tentatives de connexion à l’origine, et de rendre la réussite beaucoup plus coûteuse.

Travailler avec un reverse proxy ou un WAF: ce qu’il faut vérifier

Quand un WAF est en place, on peut être tenté de “relâcher” la vigilance. Je recommande plutôt de vérifier deux choses dans vos journaux ou via l’interface du fournisseur.

La première, c’est si les requêtes sur wp-login.php et wp-admin sont classées en blocages explicites ou seulement en ralentissement. Si c’est seulement du ralentissement, les tentatives peuvent continuer à générer une charge significative.

La deuxième, c’est la cohérence des statuts HTTP. Un blocage net se traduit souvent par des codes de rejet constants, alors qu’un simple filtrage peut produire des variations. Ce n’est pas un verdict à lui seul, mais c’est un signal.

Tester sans se piéger: quelques contrôles indispensables

Après chaque modification, testez. Pas en “cliquant sur le back-office”, mais en contrôlant le comportement. Le but n’est pas de vérifier que “ça marche chez vous”, c’est de vérifier que vous ne bloquez pas une voie légitime et que vous réduisez le bruit.

Vérifications rapides après durcissement

Essayez la connexion depuis un réseau autorisé, puis depuis un réseau non autorisé, pour confirmer la règle. Contrôlez dans les journaux que les tentatives sur wp-login.php diminuent en nombre et en régularité. Vérifiez que les pages d’administration chargent sans erreur (403 ou boucles d’auth) depuis le bon contexte. Testez la récupération de mot de passe et la gestion des sessions, car les règles trop agressives peuvent compliquer ces parcours.

Ce sont des tests simples, mais ils évitent le scénario où une protection “réussit” à bloquer tout le monde, y compris vous, au moment le plus gênant.

Cas particuliers: multisites, staging, et connexions nomades

WordPress en multisite a ses propres particularités. wp-login.php peut fonctionner différemment selon votre configuration, et l’accès à l’administration peut impliquer d’autres endpoints. Le principe reste identique, mais les règles doivent être adaptées.

Pour un site de staging, je conseille souvent de traiter le staging comme un produit exposé, même s’il n’est pas public. Si votre staging est accessible depuis Internet, les bots le trouveront aussi. À minima, appliquez la protection de base sur wp-login.php et renforcez les comptes.

Quant aux connexions nomades, elles imposent un compromis. Si vous travaillez depuis plusieurs réseaux, l’approche “restriction stricte par IP” peut devenir trop fragile. Dans ce cas, l’authentification additionnelle et la 2FA prennent plus de poids.

Ce que je déconseille, même si c’est tenté

Il y a quelques pratiques que je vois souvent et qui peuvent donner un faux sentiment de sécurité.

Chasser wp-login.php en “le renommant” ou en rendant les chemins moins évidents peut marcher contre les bots les plus basiques, mais ce n’est pas une stratégie de défense complète. Les attaquants peuvent toujours arriver à leurs fins via d’autres routes, via des fuites, ou via des scripts qui suivent les liens.

De plus, les modifications de chemin peuvent compliquer l’assistance, la maintenance, et parfois les mises à jour. Si vous choisissez ce type de changement, traitez-le comme une couche secondaire, jamais comme la colonne vertébrale.

Je déconseille aussi les règles “trop génériques” dans .htaccess qui bloquent des requêtes essentielles à WordPress, parce que vous passerez votre temps à diagnostiquer des erreurs 500 ou des pages d’administration incomplètes.

Un dernier point: les journaux, votre meilleure arme

Après plusieurs attaques répétées, on a parfois tendance à se calmer et à arrêter de regarder les logs. C’est une erreur. Les journaux sont votre retour d’information concret. Ils vous disent:

si les tentatives se déplacent vers d’autres endpoints, si les protections réduisent réellement le bruit, si un plugin ou une règle déclenche des erreurs.

Si vous n’avez pas encore d’outil centralisé, commencez simplement: assurez-vous que vos https://gardewp.fr/securite-wordpress/ logs de serveur (au moins l’accès) conservent assez longtemps les entrées liées à wp-login.php et wp-admin. Même une observation régulière, sur une semaine ou deux après modification, peut révéler si la sécurité progresse ou si vous n’avez fait que changer la forme du problème.

Résumé pratique

Protéger wp-admin et wp-login.php, ce n’est pas une question de “magie”, c’est une question de réduction de surface, de durcissement d’accès, et d’authentification solide. La meilleure combinaison, celle que je vois fonctionner le plus souvent, associe une barrière d’accès (restriction IP ou authentification additionnelle), une limitation contre le brute force, et des comptes correctement protégés avec 2FA.

Si vous ne deviez retenir que l’idée principale, ce serait celle-ci: votre objectif n’est pas de “rendre l’attaque impossible”, c’est de rendre la tentative coûteuse, et de garder le contrôle quand quelque chose tourne mal. WordPress est robuste, mais il n’est pas invulnérable, et ce sont vos couches autour du login qui font la différence au quotidien.