Quand on parle de durcissement WordPress, on pense souvent à des plugins de sécurité, à des règles de pare-feu, à des mises à jour rapides et à des mots de passe solides. C’est logique. Pourtant, dans beaucoup de projets, un levier revient dès qu’un site commence à recevoir du bruit: la géobloquage. Bloquer des pays entiers semble simple, immédiat, et ça donne souvent un effet visible en quelques heures.
Le problème, c’est que la sécurité géobloquée a des limites structurelles. Elle peut réduire la surface d’attaque, mais elle ne remplace ni la correction des vulnérabilités, ni une hygiène applicative sérieuse, ni une configuration réseau propre. Et dans certains cas, elle crée de nouveaux angles morts, ou pire, elle pénalise des utilisateurs légitimes sans apporter de vraie garantie.
Je vais poser les bases du durcissement orienté géoblocage, expliquer pourquoi ça marche parfois, puis détailler les limites concrètes que j’ai vues sur des sites réels, des e-commerces aux blogs multi-auteurs.
La promesse du géobloquage, et ce que ça réduit réellement
La géoblock est une règle qui filtre l’accès en fonction de la localisation supposée de l’adresse IP. Selon le fournisseur, cette localisation peut être basée sur des bases de données publiques ou commerciales, et donc être approximative. La plupart des protections géographiques se branchent au niveau du CDN, d’un pare-feu applicatif, ou du serveur.
Quand ça “marche”, c’est souvent pour une raison simple: une grande partie du trafic malveillant (ou du bruit automatisé) provient de régions où vous n’avez pas d’audience. Couper une grosse portion des IP réduit mécaniquement le nombre de tentatives contre votre interface publique.
Sur un site qui subissait des attaques de type brute force sur wp-login.php, j’ai déjà vu une baisse spectaculaire du volume d’accès après un géoblocage. Les logs affichaient moins de requêtes, les CPU et la bande passante se calmaient, et les tentatives de connexion se raréfiaient. Ça donne un sentiment de contrôle.
Mais cette amélioration est rarement une preuve que le site est “sûr”. C’est surtout une réduction de bruit. Le risque principal reste entier: si une faiblesse existe dans WordPress, dans un thème, dans un plugin, ou dans la façon dont l’application gère certains flux, la règle géographique ne la supprime pas. Elle ne fait que déplacer le problème vers les IP restantes, qui peuvent encore être attaquées.
Ce que le géobloquage ne fait pas
Il y a plusieurs choses qu’un géoblocage ne fait pas, même s’il est très bien configuré:
Il ne corrige pas une vulnérabilité applicative. Une faille dans un plugin exposé à des requêtes forgées restera exploitable depuis n’importe quelle IP autorisée.
Il ne stoppe pas les attaques provenant de VPN ou de proxys. Beaucoup d’acteurs malveillants utilisent des sorties réseau dans des pays “autorisés”, ou bien changent de localisation au fil des tentatives.
Il n’empêche pas les fuites d’authentification. Si un formulaire d’identification est accessible, un attaquant peut tenter des attaques par mot de passe, de la validation de mots de passe, ou des techniques d’énumération d’utilisateurs, et tout ça peut se produire depuis des zones autorisées.
Il ne garantit pas l’exactitude géographique. Les bases IP-to-geo se trompent parfois. L’erreur peut être de quelques centaines de kilomètres, ou plus rarement de manière significative, ce qui fait que vous bloquez un utilisateur légitime ou vous laissez passer une partie du trafic que vous vouliez réduire.
Sur les projets internationaux, la probabilité d’impacts légitimes augmente. Sur certains sites, des clients ou des collaborateurs voyagent, utilisent des connexions d’entreprise, ou se connectent depuis des pays inattendus. Le géoblocage finit alors par devenir un coût opérationnel.
Où le géobloquage a du sens (et où il est risqué)
Le géoblocage est le plus “rentable” quand votre audience est majoritairement concentrée dans quelques pays et que l’interface est simple. Un exemple typique: un site vitrine en langue locale, avec un trafic majoritairement national, et sans flux sensible à l’international.
Dans ces conditions, on peut réduire la quantité de bruit et gagner du temps sur l’analyse. Les tentatives sur wp-login et les scans automatiques diminuent souvent, et vos alertes deviennent plus pertinentes.
À l’inverse, il est plus risqué quand:
Votre site sert des visiteurs internationaux ou des équipes distribuées. Vous avez des utilisateurs qui se connectent depuis des réseaux d’entreprise, des universités, des VPN de conformité, ou des connexions mobiles dont la géolocalisation peut fluctuer. Vous opérez un site e-commerce où la conversion dépend de la confiance, donc chaque blocage “injuste” se voit.
J’ai aussi vu une autre situation: des équipes qui géobloquent “au hasard” après quelques tentatives suspectes, sans analyser d’où venaient les attaques de façon détaillée. Résultat, elles bloquent des pays qui n’attaquent pas, tout en laissant ouverts ceux qui attaquent réellement via des proxys.
Le bon usage ressemble plus à une stratégie de réduction du bruit qu’à un verrouillage total.
Une approche de durcissement WordPress qui intègre le géobloquage
Le durcissement WordPress devrait commencer par ce qui diminue le risque à la racine, puis seulement ensuite utiliser des barrières externes comme le géoblocage.
Concrètement, je raisonne souvent en trois couches. D’abord, l’application et son hygiène: mises à jour, réduction de l’exposition, plugins limités et maîtrisés. Ensuite, l’accès: durcir l’authentification, limiter les tentatives, surveiller les erreurs, protéger l’administration. Enfin, le périmètre réseau: pare-feu, rate limiting, géobloquage si pertinent, règles qui filtrent les comportements clairement automatisés.
Le géobloquage est dans la troisième couche. S’il est bien utilisé, il agit comme un “tampon” en amont. Si le reste est faible, il ne tient pas lieu de sécurité.
Détails opérationnels: ce que les logs vous racontent
Le point qui change tout, c’est l’examen des logs avant de créer une règle large. Sur WordPress, la plupart du temps, vous ne voulez pas partir d’une hypothèse de “pays = attaquants”. Vous voulez partir de données.
Quelques indicateurs utiles, sans chercher à tout analyser à la main:
Le ratio entre trafic normal (pages vues) et tentatives d’endpoints sensibles (wp-login, xmlrpc, wp-admin, récupération de fichiers inexistants). La récurrence d’une même séquence d’URL, ce qui ressemble à un robot. Le rythme moyen par IP et par tranche de temps, qui indique souvent du brute force ou du scanning. La part des erreurs 401, 403, 404 répétées, qui signale soit un mauvais paramétrage, soit des probes.
Si vous voyez que l’essentiel du bruit vient de certains pays, le géoblocage peut vous aider. Si au contraire, le bruit est réparti et que les tentatives viennent aussi de pays que vous autorisez, la règle ne fera qu’ajouter un risque de faux positifs.
Même quand vous choisissez de géobloquer, je conseille de conserver un mécanisme d’exception pour votre équipe, vos prestataires, et éventuellement un canal d’accès de secours. Le pire moment pour se tromper n’est pas quand vous observez le trafic, c’est quand vous devez dépanner à 2 heures du matin.
Les limites techniques qu’on sous-estime souvent
Le “bypass” par proxy et la mobilité des IP
Un attaquant peut passer par des infrastructures qui sortent dans des pays “autorisés”. Le géoblocage devient alors une barrière décorative. Vous pouvez réduire un flux, mais pas éliminer la menace.
L’erreur de géolocalisation
Les bases IP-to-geo ne sont pas des horloges suisses. Elles peuvent classer une IP de manière inattendue. Pour un utilisateur légitime, le résultat est immédiat: erreurs 403, pages indisponibles, ou formulaires qui n’aboutissent pas.
Dans un site multilingue, même si la majorité du trafic est local, vous aurez toujours des cas particuliers. Un client en déplacement, une connexion via un réseau d’entreprise, un partenaire qui teste depuis un autre pays. https://gardewp.fr/securite-wordpress/ Une règle “bloque tout sauf…” finit souvent par produire des plaintes.
Les conséquences sur les SEO et l’accessibilité
Le géoblocage en soi ne devrait pas impacter le référencement si les moteurs n’essayent pas de visiter depuis des zones bloquées. Mais dans la pratique, certains outils de monitoring et certaines adresses “crawler” ou prestataires peuvent venir de pays non attendus. Et surtout, pour les utilisateurs, tout blocage est un trou dans l’expérience.
Si votre site doit rester joignable pendant toute la période d’attaque, vous ne voulez pas que la sécurité réseau se transforme en panne partielle.
Le “shadow IT” côté hébergement
Selon que vous êtes derrière un CDN, sur un WAF, ou directement sur votre serveur, la configuration peut être fragmentée. On a parfois une règle géographique au niveau du reverse proxy, puis une autre au niveau du WAF, puis une autre côté serveur. Résultat: confusion, règles qui se contredisent, et difficulté à reproduire un incident.
Je privilégie une source unique de vérité, au moins pour la partie géographique. Tout ce qui est “multi endroits” augmente le risque d’oublis et le temps de diagnostic.
Comment décider: un cadre de jugement simple
Le durcissement WordPress via géobloquage n’a pas une réponse universelle. En revanche, vous pouvez appliquer un cadre de décision basé sur votre réalité.
D’abord, posez une question: “Nos visiteurs légitimes se trouvent-ils majoritairement dans X pays, et avons-nous des raisons d’attendre une audience hors X?” Si la réponse est non, géobloquer peut être utile.
Ensuite, regardez votre exposition: un site vitrine avec peu de formulaires de connexion n’a pas le même risque qu’un site avec espace membre, identifiants, formulaires de contact publics, ou capacité de soumettre du contenu.
Puis, considérez le coût de l’erreur. Si une règle trop agressive coupe votre accès à un administrateur qui voyage, ou empêche un test de staging, vous risquez de perdre plus de temps que le géobloquage ne vous fera gagner en réduction d’attaques.
Enfin, testez et mesurez. Une règle géographique devrait être évaluée sur au moins une fenêtre de temps significative, en observant l’évolution des requêtes bloquées et l’absence d’impact sur vos utilisateurs réels (transactions, connexion, pages clés).
Mise en pratique: règles typiques et garde-fous
Le géobloquage ne doit pas être le seul levier. L’approche la plus saine consiste à combiner plusieurs contrôles, par exemple:
Limiter l’accès à wp-admin et wp-login à des plages cohérentes, éventuellement en ajoutant des restrictions sur IP pour les comptes administrateurs. Désactiver ou restreindre xmlrpc si vous n’en avez pas besoin, car c’est une surface fréquente pour les attaques. Appliquer un rate limiting sur les tentatives de connexion. Utiliser une politique de mises à jour ferme sur WordPress, thèmes, et plugins, en évitant les “plugins fantômes”.
Je vous donne un repère concret issu d’observations en production: même quand un site a des plugins de sécurité, une partie des attaques continue, car tout n’est pas bloqué au bon endroit, ou les protections sont “passives”. Le géoblocage, lui, agit au niveau d’entrée, ce qui peut calmer le flux, mais la véritable baisse des risques vient quand l’authentification et les surfaces sensibles sont mieux contrôlées.
Voici deux garde-fous que je recommande, parce qu’ils évitent les situations délicates:
- Conserver une voie d’accès pour votre équipe, par exemple via une plage IP fixe de bureau ou un compte de secours hors règle stricte. Commencer avec une liste de pays autorisés plus large que ce que vous pensez “au début”, puis resserrer après mesure.
Un cas réel (sans détails sensibles)
Sur un site WordPress d’une petite structure, les logs montraient une hausse de requêtes sur des endpoints d’administration. Le support interne proposait le géobloquage complet des pays “non ciblés”. Le premier réflexe était compréhensible, mais l’équipe travaillait avec un prestataire situé à l’étranger, et les administrateurs utilisaient parfois un VPN.
Ils ont fini par mettre une règle assez large, en bloquant d’abord quelques régions très bruyantes, puis en vérifiant l’impact sur les accès distants. En parallèle, ils ont:
Réduit le nombre de plugins actifs, Corrigé une extension qui traînait une version dépassée, Et appliqué un rate limiting sur les tentatives de connexion.
Après deux semaines, les alertes de sécurité se sont calmées et les faux positifs ont été quasi nuls. Ce qui est important, c’est que le géoblocage n’a pas remplacé la correction applicative, il a réduit la charge pendant que les vraies causes étaient traitées.
Où le géobloquage devient un piège
Le piège le plus courant, c’est le sentiment de fausse sécurité. Quand le flux diminue, on ralentit la maintenance. On reporte des mises à jour. On conserve des plugins non essentiels, “puisque ça ne scanne plus autant”.
Or un acteur malveillant peut changer de stratégie. Il suffit parfois d’un changement d’IP sources ou d’une rotation de proxys. Sans durcissement WordPress de fond, vous retombez sur des problèmes identiques, mais avec des heures de maintenance en retard.
Un autre piège est la granularité. Certains acteurs bloquent “les pays” alors que la menace est plus corrélée à des comportements: rafales de tentatives, patterns d’URL, user-agent répétitifs, ou absence de navigation cohérente.
Si vous avez un WAF capable de distinguer ces comportements, il est souvent plus efficace de combiner une règle comportementale et une règle géographique légère, plutôt que de compter uniquement sur la localisation.
Durcissement WordPress: points à travailler avant de bloquer au maximum
Sans entrer dans une checklist interminable, il y a des priorités qui reviennent presque toujours quand on parle de sécurité WordPress:
Renforcer l’authentification, car les attaques réussissent souvent par tentative de mot de passe ou par abus de sessions. Réduire les plugins, car chaque plugin est une surface. Deux plugins “inutiles” peuvent faire plus de dégâts qu’un géoblocage. Mettre à jour, car un retard de quelques versions peut suffire à exposer un vecteur connu. Protéger xmlrpc et l’administration, car ce sont des aimants à scans.
Le géoblocage peut ensuite réduire l’intensité des attaques, mais la base doit être solide.
Comment mesurer le résultat, sans se tromper de métrique
Il y a une métrique séduisante, et trompeuse: “nombre de requêtes bloquées”. On peut bloquer énormément et se sentir gagnant, tout en laissant une faille exploitable.
Je recommande de regarder au moins deux familles d’indicateurs:
La diminution du bruit sur les endpoints sensibles (wp-login, xmlrpc, pages d’erreurs). L’absence d’incidents côté application, par exemple pas d’augmentation d’échecs d’authentification côté utilisateurs légitimes, pas de blocage d’accès administrateur, pas d’impact sur les flux essentiels (inscription, achat, formulaires).
Si vous bloquez des pays, surveillez aussi les plaintes, les logs d’accès des comptes admins, et les taux d’erreur des pages clés. Un géoblocage “réussi” est celui qui réduit le risque sans dégrader l’accès.
Une stratégie réaliste: commencer léger, puis durcir
Si vous êtes tenté de faire un géoblocage strict, un parcours progressif donne souvent de meilleurs résultats. L’idée n’est pas de “tomber dans la prudence”, c’est de garder du contrôle pendant que vous apprenez.
Voici une séquence courte qui marche bien dans la pratique, surtout sur des sites qui ne sont pas encore parfaitement durcis:
- Observer les logs pendant quelques jours, identifier les pays et patterns les plus bruyants. Mettre un géoblocage partiel ou ciblé, en gardant des exceptions pour l’équipe et les prestataires. Renforcer l’authentification et le contrôle des tentatives, plutôt que de compter sur la localisation. Surveiller l’impact sur les utilisateurs et ajuster les exceptions avant de resserrer. Documenter la configuration, pour que le prochain dépannage ne soit pas un jeu de devinette.
Cette approche conserve l’intérêt du géoblocage, sans l’utiliser comme un remplacement de la sécurité applicative.
L’essentiel à retenir sur la sécurité géobloquée
Le durcissement WordPress par géoblocage est une mesure utile quand votre audience est clairement localisée et quand vous pouvez mesurer l’impact. Elle réduit souvent le volume d’attaques automatisées et vous aide à concentrer vos efforts.
Mais elle reste une barrière externe, contournable par des proxys, imparfaite à cause des erreurs de géolocalisation, et fragile si vous manquez de protections applicatives de base. Le bon réflexe, c’est de considérer le géoblocage comme un filtre de bruit, pas comme un verrou final.
Si vous me demandez une recommandation pragmatique, elle tient en une phrase: durcissez WordPress sur l’authentification, la surface d’exposition et la maintenance, puis utilisez la géographie comme couche supplémentaire, avec exceptions maîtrisées et surveillance régulière.
Et surtout, gardez en tête que la sécurité n’est pas un état, c’est une habitude. Une règle géographique change, un attaquant s’adapte, et votre organisation doit pouvoir suivre. C’est là que le géobloquage, bien cadré, devient un allié, plutôt qu’un pansement qui retarde la vraie réparation.