Dès que l’on met un site WordPress en ligne, on obtient rapidement deux choses: des visiteurs “normaux” et, souvent plus tôt que prévu, du trafic automatisé qui cherche une faille. Les tentatives de connexion, les scans de fichiers, les requêtes à des endpoints inexistants, tout cela n’a pas besoin d’un contenu malveillant pour causer des dégâts. La charge serveur augmente, les journaux se remplissent, et surtout, on finit par rater les vrais signaux parce que l’environnement devient du bruit.
La géolocalisation, utilisée correctement, est un outil parmi d’autres pour réduire ce bruit et limiter certaines attaques opportunistes. Elle ne “répare” pas une vulnérabilité, elle ne remplace pas une bonne hygiène de sécurité, mais elle peut faire une vraie différence sur des sites exposés, notamment quand le public réel du site est relativement limité géographiquement.
Ce que la géolocalisation peut (et ne peut pas) faire
La géolocalisation IP consiste à inférer un pays ou une région à partir de l’adresse IP entrante. En pratique, les bases de données ne sont pas parfaites. Des opérateurs utilisent des réseaux partagés, des VPN changent l’IP, des entreprises hébergent du trafic pour plusieurs régions. Une règle “bloquer le pays X” peut donc être efficace… ou produire des faux positifs, selon votre audience.
Sur le papier, l’idée paraît simple: si votre audience est majoritairement française et que les tentatives suspectes proviennent de manière répétée d’un autre pays, vous pouvez bloquer ce pays et réduire la surface. Sur un vrai site, j’ai constaté que le gain se voit surtout dans les logs et la charge. Les scans changent de rythme, parfois ils baissent d’un ordre de grandeur quand le trafic venait clairement d’un périmètre géographique concentré.
Mais il y a une limite fondamentale: les attaquants peuvent utiliser des VPN, des proxys, voire des infrastructures de cloud basées ailleurs. Autrement dit, la géolocalisation n’empêche pas une attaque déterminée. Elle sert à repousser le “massif” opportuniste et à vous donner de la respiration.
Je le formule autrement, parce que c’est une erreur classique: la géolocalisation ne sécurise pas WordPress au sens où elle corrige une faille. Elle sécurise l’exposition en réduisant le volume de trafic malveillant non ciblé.
Pourquoi le trafic malveillant se concentre parfois par pays
Beaucoup d’automates attaquent de la même manière partout. Ils balayent des URL connues, ils testent des mots de passe faibles, ils tentent des tentatives de connexion massives. Ces https://gardewp.fr/securite-wordpress/ bots sont souvent hébergés dans des réseaux de datacenters ou dans des zones où la disponibilité de certains services d’hébergement est moins chère ou plus simple à automatiser.
Résultat: sur certains sites, vous voyez des concentrations par pays. Par exemple, un pic de requêtes vers xmlrpc.php ou des vagues de tentatives sur wp-login.php peuvent se retrouver majoritairement sur quelques pays dans les journaux. Ce n’est pas garanti, mais quand c’est le cas, bloquer ces origines peut réduire nettement le bruit.
Autre point pratique: si votre site est en français, avec une offre locale et une audience stable, vous avez une base de référence. Une suractivité hors zone attire l’œil, et le ciblage géographique devient plus rationnel.
Avant de bloquer: clarifier votre audience et vos usages
Je conseille toujours de regarder deux choses avant d’appliquer une règle stricte:
- où vivent vos visiteurs “réels” à quelles fonctions sensibles accède votre trafic légitime
Votre audience peut sembler évidente, mais WordPress a des usages qui étendent la zone géographique: un développeur ou un client peut être en voyage, une équipe marketing peut utiliser des outils depuis l’étranger, et certaines plateformes de paiement ou de support peuvent générer des IP variées. Même si le contenu est local, les interactions techniques peuvent venir d’ailleurs.
Prenez aussi en compte la présence de services tiers. Par exemple, un CDN ou un pare-feu applicatif peut attribuer les IP de ses nœuds plutôt que celles des visiteurs. En fonction de votre configuration, la géolocalisation basée sur l’IP entrante peut refléter le réseau du proxy, pas celui de l’utilisateur final. Dans ce cas, bloquer des pays peut ne rien changer, ou pire, bloquer vos propres nœuds de distribution.
Enfin, il faut décider quel niveau vous visez. Sur WordPress, la géolocalisation s’applique souvent à la couche “accès au site” ou “accès à l’administration”. Bloquer l’ensemble du trafic d’un pays est plus agressif que de limiter l’accès à des endpoints sensibles. Mon expérience est que, pour commencer, le ciblage administratif est un bon compromis.
Une approche prudente: réduire d’abord, puis durcir
Si vous bloquez d’emblée des pays sans test, vous risquez de casser un accès légitime. Heureusement, l’écosystème WordPress permet de déployer des mesures graduelles: règles de “challenge” plutôt que blocage, whitelist d’adresses ou de plages, surveillance des journaux pendant quelques jours.
Une stratégie pragmatique consiste à:
1) observer pendant une fenêtre courte (quelques jours) 2) identifier les pays les plus actifs sur les événements suspects 3) appliquer une règle “sur les zones sensibles” plutôt que sur tout le site 4) surveiller les effets, ajuster, puis éventuellement étendre
Cette méthode réduit les risques d’auto-sabotage. Elle améliore aussi votre compréhension: si le blocage n’a aucun impact, c’est peut-être parce que le trafic “suspect” n’est pas vraiment géolocalisable à votre avantage, ou parce qu’un proxy redistribue les IP.
Mise en place sur WordPress: points d’attention concrets
WordPress n’est pas monolithique côté sécurité. Les solutions de sécurisation WordPress se basent souvent sur des plugins de pare-feu applicatif, sur des règles au niveau serveur, ou sur les deux. Avec la géolocalisation, vous aurez généralement trois options:
- filtrage au niveau du serveur (souvent via le pare-feu du fournisseur ou des règles web) filtrage via un reverse proxy ou un WAF (Cloudflare, équivalent, etc.) filtrage via un plugin (règles dans WordPress)
Le choix n’est pas seulement technique, il dépend de votre architecture. Si votre site est derrière un CDN et que les IP “visibles” sont celles du CDN, un filtrage dans WordPress peut être trompeur. À l’inverse, un filtrage côté CDN ou fournisseur peut être plus fiable, mais vous devez savoir quel champ d’IP est utilisé (par exemple le client réel via un en-tête spécifique, selon la configuration).
Régler l’impact sur l’accès à wp-admin et wp-login
C’est souvent le meilleur point de départ. Les bots qui attaquent WordPress visent rarement le contenu public de manière “humaine”. Ils concentrent leurs tentatives sur les pages d’identification, sur l’API et sur des points d’entrée classiques.
En pratique, vous pouvez appliquer la géolocalisation sur:
- l’accès à /wp-login.php l’accès à /wp-admin/ certains endpoints sensibles, par exemple xmlrpc.php (selon votre usage)
Si votre site n’utilise pas XML-RPC pour des raisons légitimes, la réduire ou la bloquer est souvent une mesure encore plus efficace que la géolocalisation. Mais si vous choisissez la géolocalisation, faites-le en ciblant ces zones pour limiter les faux positifs.
Ne confondez pas “pays” et “région utile”
Même quand la géolocalisation est correcte au niveau pays, vous pouvez avoir des clients légitimes provenant de “vos pays” voisins. Par exemple, un site français qui accepte des clients francophones dans plusieurs pays peut avoir besoin de ne pas bloquer largement. Le bon sens ici n’est pas une règle, c’est un arbitrage. Si vous vendez un service multilingue, ou si vous avez des visiteurs internationaux, il faut intégrer cette réalité.
J’ai déjà vu des administrateurs bloquer un pays “parce que c’était plein de bots”, puis découvrir une semaine plus tard que des demandes support légitimes venaient d’une région où l’on ne s’attendait pas. Rien de dramatique, mais le temps perdu à comprendre la cause m’avait rappelé que WordPress attire aussi des utilisateurs “occasionnels” (voyage, accès depuis un bureau, déplacement pro).
Exemples de règles réalistes (sans tomber dans l’aveugle)
En fonction de votre outil, vous allez configurer des règles du type “bloquer tel pays sur telle URL”. L’idée la plus raisonnable est de bloquer des pays qui montrent une activité vraiment anormale sur des endpoints sensibles, et de garder un chemin d’accès pour vous et pour vos opérations.
Voici un exemple de logique, que vous adapteriez avec vos données:
- vous définissez une base de pays “attendus” (votre audience réelle ou votre zone commerciale) vous bloquez en priorité l’accès à l’administration depuis les pays non attendus vous gardez une période de monitoring pendant laquelle vous observez les erreurs de blocage dans les journaux
Cette approche ressemble à un pare-feu “ciblé”. Elle ne supprime pas le risque d’une attaque depuis une IP légitime d’un pays autorisé, mais elle réduit ce qui est le plus facile, souvent la partie opportuniste.
Vérifier l’effet avec les logs (sinon vous pilotez à l’aveugle)
La géolocalisation devient intéressante quand elle est mesurée. Le piège, c’est de mettre une règle puis de ne jamais vérifier. Si vous bloquez trop vite ou trop large, vous le payez en heures de support.
Sur WordPress, les logs pertinents ne manquent pas, mais ils sont dispersés: logs du serveur web, logs applicatifs, logs du pare-feu ou du plugin. L’idée n’est pas de tout lire, c’est de repérer des indicateurs simples: nombre de requêtes vers wp-login.php, taux d’erreurs 403 ou 429, origine par pays, et volume total sur une période.
Voici un mini plan de vérification avant action, puis après:
- repérer 48 à 72 heures de trafic “suspect” dans les journaux, sans règle nouvelle compter les événements sur les URL sensibles (login, admin, XML-RPC si utilisé) mettre la règle sur un périmètre réduit (administration) surveiller la même durée, comparer les volumes ajuster la liste de pays ou étendre progressivement
Checklist pratique (démarrer sans casser l’accès)
Vérifier que vos règles s’appliquent bien aux bonnes URL (login, admin), pas uniquement à l’ensemble du site Confirmer si votre architecture expose l’IP “réelle” ou l’IP du proxy/CDN (selon le cas) Repérer vos pays légitimes récurrents dans la période d’observation Appliquer une restriction d’abord en mode “monitor” ou sur un sous-ensemble d’URL si votre outil le permet Prévoir une méthode de contournement pour votre propre IP (ou un accès de secours) avant de bloquerComment éviter de vous bloquer vous-même
La sécurité par géolocalisation a une faiblesse classique: vous pouvez bloquer votre propre IP si vous vous déplacez, si votre fournisseur change votre sortie internet, ou si un VPN d’entreprise achemine votre trafic depuis un autre pays.
Pour réduire ce risque, je recommande une approche “contrôle d’accès”:
- mettre une règle de whitelist sur vos IP stables (ou sur une plage, si votre environnement le permet) garder une procédure d’accès depuis un canal de secours (par exemple un accès via VPN de votre organisation, ou une adresse d’administration dédiée) éviter de basculer en mode “blocage total” trop vite
J’ai déjà vécu un cas simple: administration WordPress depuis un hôtel, IP d’un pays inattendu, blocage immédiat. Le site n’était pas “cassé”, mais l’accès admin l’était. On oublie vite à quel point l’IP peut bouger, surtout avec les réseaux mobiles. Cette leçon vaut pour n’importe quelle règle géographique.
Les faux positifs: ce qui doit vous alerter
Bloquer des pays peut produire des symptômes faciles à confondre. Par exemple:
- des utilisateurs légitimes voient des pages “interdites” (403) des pages passent par votre pare-feu et déclenchent des challenges répétés des formulaires ne fonctionnent plus, parce que les requêtes AJAX sont filtrées
Sur un WordPress, ces effets se manifestent souvent par une hausse des erreurs côté navigateur ou des tickets support. Le point clé est de regarder si les erreurs se concentrent sur certains pays. Si oui, la règle de géolocalisation est en cause. Si non, le problème vient d’autre part.
Autre cas: un service de paiement ou une étape de redirection peut passer par un pays que vous n’aviez pas anticipé. Même si votre audience est locale, des systèmes tiers peuvent avoir des sorties différentes. La règle la plus “propre” est souvent de filtrer l’accès admin et certains endpoints, pas tout le front public.
Tests rapides à faire après activation
- Vérifier l’accès admin depuis un réseau “différent” du vôtre habituel (en restant en whitelist si nécessaire) Contrôler les requêtes vers wp-login.php et wp-admin/ en vérifiant que les 403 viennent bien de pays bloqués Tester les formulaires publics ou l’authentification front si vous en avez, pour détecter une règle trop large
Trade-offs: sécurité, expérience utilisateur, charge serveur
On résume souvent la géolocalisation à “bloquer des pays = sécurité”. En réalité, c’est un compromis entre trois axes.
Le premier axe, c’est l’efficacité. Si votre trafic malveillant est largement concentré hors zone, vous réduisez rapidement la charge et les tentatives de login. Le deuxième axe, c’est l’expérience utilisateur. Plus vous bloquez, plus vous augmentez le risque de gêner des visiteurs légitimes, même une poignée.
Le troisième axe, c’est la performance. Selon l’endroit où la règle est appliquée, le coût peut varier. Filtrer au niveau pare-feu ou CDN coupe la requête plus tôt. Filtrer dans WordPress peut signifier que la requête arrive quand même, puis est bloquée plus tard. Dans ce dernier cas, le bénéfice principal est la réduction de logique applicative, pas la réduction de charge brute.
C’est aussi pour cela que je préfère généralement démarrer par le ciblage admin. C’est souvent là que le gain est le plus net, sans toucher l’expérience de lecture et de navigation.
Que faire si la géolocalisation ne bouge presque rien
Il arrive que les règles géographiques semblent inefficaces. Deux raisons fréquentes:
1) le trafic malveillant est distribué mondialement, donc bloquer quelques pays ne change pas le total 2) votre architecture masque l’IP client réel, donc la géolocalisation se base sur l’IP du proxy, pas sur celle de l’attaquant
Dans ces cas, la géolocalisation n’est pas inutile, mais elle devient secondaire. Vous pouvez combiner avec d’autres mesures pour réduire la surface réelle:
- durcir l’authentification, par exemple en limitant le nombre de tentatives désactiver ou contrôler l’accès à XML-RPC si vous n’en avez pas l’usage vérifier la liste des plugins, thèmes, et rôles appliquer des mises à jour régulières, surtout sur WordPress core et les dépendances
La géolocalisation ne remplace pas ces étapes. Elle complète.
Gérer les cas particuliers: VPN, travailleurs à distance, mobilité
Vous pouvez vouloir bloquer certains pays, mais votre propre équipe peut être en mobilité. Un développeur qui travaille depuis l’étranger, un admin qui passe une semaine à l’étranger, tout cela doit être anticipé.
Le bon réflexe consiste à penser “accès opérationnel” plutôt que “pays en général”. Vous autorisez des accès sensibles pour vos personnes et vos outils, et vous bloquez le reste. La géolocalisation devient alors une couche de tri, pas une décision unique.
J’ai aussi vu des environnements où l’équipe marketing utilise un CRM ou un outil d’automatisation qui génère des requêtes depuis des IP de datacenters. Si ces datacenters sont géolocalisés dans des pays non attendus, une règle trop stricte casse l’intégration. Dans ce cas, la whitelist sur des adresses ou des plages est plus efficace que l’interdiction globale.
Un exemple de déploiement progressif (sur plusieurs jours)
Sans imposer un calendrier universel, voici une façon de procéder qui a bien fonctionné sur des sites “semblables” au fil de mes interventions.
Jour 1: observation et base de référence. Vous récupérez dans vos journaux les pays les plus associés aux événements de login, aux 404 massifs, ou aux erreurs sur des endpoints souvent ciblés. Vous identifiez aussi vos pays “stables” liés aux visiteurs réels.
Jour 2: restriction ciblée. Vous activez la géolocalisation uniquement sur /wp-login.php et /wp-admin/, avec une liste de pays bloqués basée sur vos constats, et une whitelist pour vos IP.
Jour 3 et Jour 4: monitoring. Vous comparez le volume des requêtes suspectes et la proportion d’erreurs. Vous regardez si des erreurs 403 apparaissent côté front de manière inattendue.
Jour 5: ajustement. Si tout se passe bien, vous affinez la liste de pays. Si au contraire vous observez des blocages légitimes, vous réduisez le périmètre ou vous ajoutez des exceptions.
Cette approche évite la “sécurité à l’instinct” et vous donne des données plutôt que des impressions.
Géolocalisation et conformité: rester pragmatique
Un point souvent négligé: la géolocalisation peut impliquer des traitements liés aux données IP. Selon votre contexte, vous devez vérifier si votre politique de confidentialité et vos obligations locales couvrent ces traitements. Je ne peux pas trancher pour votre cas précis, mais je recommande de rester aligné avec votre cadre légal et vos exigences internes, surtout si vous logguez des informations liées à l’IP et aux pays.
Sur le plan opérationnel, vous n’avez pas besoin de stocker plus que nécessaire. Réduire la rétention des logs “riches” peut limiter la sensibilité des données, tout en gardant la capacité de diagnostiquer.
Garder la géolocalisation comme une couche, pas comme un bouclier unique
La meilleure façon de tirer parti de la géolocalisation, c’est de la traiter comme un filtre de flux. Elle diminue le volume, elle met en avant le trafic réellement intéressant, et elle peut ralentir certains scénarios automatisés.
Mais une sécurisation WordPress solide repose sur un ensemble de gestes: mises à jour, plugins propres, durcissement de l’authentification, limitation des vecteurs connus, et surveillance régulière. Quand on combine ces pratiques, la géolocalisation devient un accélérateur. Quand on la considère comme la solution principale, on se donne un faux sentiment de contrôle.
Si vous voulez un test simple pour vous-même: si vous supprimez la géolocalisation, votre WordPress devrait rester raisonnablement protégé grâce aux autres couches. Sinon, vous avez un plan incomplet.
Ce que je ferais en priorité sur un site WordPress “standard”
Si je devais donner une recommandation concrète et prudente, sans connaître votre architecture exacte, je commencerais par:
- restreindre l’accès à wp-login et wp-admin par pays ajouter une whitelist pour l’accès admin de l’équipe surveiller la baisse des tentatives et l’évolution des erreurs seulement ensuite, décider s’il faut élargir au front ou à des endpoints spécifiques
La géolocalisation est un levier, pas un mode magique. Bien utilisée, elle réduit le bruit et vous aide à vous concentrer sur ce qui compte vraiment, les vulnérabilités réelles, les comptes à risque, et les comportements suspects qui ne se “masquent” pas derrière une origine géographique trompeuse.