Sécuriser WordPress : filtrer les requêtes à risque

WordPress attire parce que c’est flexible, facile à installer et accessible. Justement, cette combinaison en fait aussi une cible pratique pour les attaques automatiques: tentatives de connexion, exploration de plugins, appels à des endpoints connus, probes qui cherchent une version vulnérable, et parfois des tentatives d’injection plus opportunistes. La majorité de ces assauts ne “cassent” pas WordPress au sens technique, ils le fatiguent. Ils consomment du CPU, saturent les logs, provoquent des blocages applicatifs, et finissent par donner l’impression que “tout est lent” ou “ça ne répond plus”.

Quand on parle de filtrer les requêtes à risque, l’idée n’est pas de tout bloquer. Elle est plus subtile: réduire la surface d’attaque en amont, refuser ce qui n’a aucune raison d’être légitime, et ralentir ce qui ressemble à du bruit automatisé. Le bénéfice se voit vite, sur les taux de requêtes anormales, sur la stabilité, et sur l’efficacité du monitoring.

Ce que “requête à risque” veut dire, concrètement

Une requête à risque n’est pas seulement une requête qui “attaque”. C’est aussi une requête qui révèle une intention suspecte ou une absence de contexte normal.

Sur WordPress, les signaux les plus fréquents sont liés aux URLs et au modèle de trafic:

• tentatives répétées sur wp-login.php avec des combinaisons de mots de passe, souvent avec un rythme trop régulier
• accès à wp-admin/ et à des scripts dont les robots n’ont aucune raison d’avoir besoin en dehors d’un navigateur humain
• appels à des chemins sensibles, par exemple des fichiers ou des scripts dont l’existence ne devrait pas être accessible publiquement
• sondages d’endpoint XML-RPC ou d’API dont l’activation ne correspond pas à votre configuration
• demandes de ressources qui semblent aléatoires, avec des patterns typiques de scanners

Dans une logique de sécurisation WordPress, filtrer les requêtes à risque consiste à faire un tri entre: ce qui correspond à un usage normal (même si c’est un peu brut), et ce qui ressemble à une activité de découverte automatisée ou d’attaque.

Ce tri peut se faire à plusieurs endroits: au niveau réseau (pare-feu, WAF), au niveau serveur HTTP (nginx ou Apache), au niveau de la couche applicative (WordPress), et parfois même avant d’arriver à l’hébergement (CDN). Le bon choix dépend de votre architecture et de votre tolérance aux faux positifs.

Pourquoi filtrer tôt: moins de charge, moins d’erreurs, meilleurs logs

Le premier avantage du filtrage en amont, c’est qu’il évite de traiter inutilement des requêtes. Plus une requête monte dans la pile (DNS, acceptation TCP, TLS, parsing HTTP, routage, bootstrap WordPress), plus elle coûte. Si vous jetez une partie du trafic avant que WordPress ne s’en occupe, vous diminuez:

• la charge CPU liée au bootstrap PHP
• l’occupation des worker HTTP
• les risques de timeouts pendant des pics
• la difficulté à distinguer le “vrai incident” du bruit

Je me suis déjà retrouvé sur un site où les tentatives sur wp-login.php n’étaient pas “bloquantes” en soi, mais elles polluaient tellement les logs et consommaient la mémoire en phase de spikes, que la détection d’un autre problème passait inaperçue. En ajoutant un filtrage HTTP en amont, on a réduit le bruit, et surtout on a rendu le monitoring lisible.

Autre point, plus discret: quand WordPress reçoit des requêtes tordues, vous pouvez obtenir des comportements inattendus, même si le contenu final n’est pas exécutable. Filtrer avant réduit la variabilité.

Les grandes familles de filtrage utiles pour WordPress

On peut regrouper les approches en trois familles. Elles se complètent souvent.

Filtrage réseau et WAF

Un pare-feu ou un WAF examine la requête à un niveau plus proche du réseau. Vous pouvez y mettre des règles basées sur la géographie, les taux (rate limiting), la réputation d’IP, ou certains patterns d’URL et de méthodes HTTP. L’avantage est la performance. Le risque est le faux positif si vous jouez trop fin.

Avec un WAF, vous pouvez aussi faire des “challenges” (captcha ou vérification) quand le trafic ressemble à un bot. Sur des sites à faible volume, c’est parfois efficace. Sur des sites très sollicités, ça peut dégrader l’expérience de certains utilisateurs.

Filtrage HTTP au niveau serveur

C’est souvent la couche la plus accessible et la plus configurable. Selon votre serveur (nginx ou Apache) et votre méthode de déploiement (direct sur le serveur, conteneurs, hébergement mutualisé), vous pouvez:

• bloquer certaines combinaisons d’URL et de méthode
• refuser des patterns évidents (par exemple des requêtes qui tentent d’accéder à des chemins non publics)
• appliquer des limites sur la fréquence par IP
• ajouter des contrôles sur les en-têtes (par exemple User-Agent) de manière prudente

Ici, le jugement est clé. Bloquer un User-Agent en bloc est tentant, mais les navigateurs légitimes peuvent se déguiser ou se présenter différemment selon les outils d’accessibilité, les bots de cache, ou les tests internes.

Filtrage applicatif (au sein de WordPress)

WordPress peut réagir au besoin, via des plugins de sécurité ou des règles spécifiques. L’avantage est la granularité: vous pouvez traiter différemment les tentatives de connexion, les accès au XML-RPC, ou certains paramètres d’API. L’inconvénient, c’est le coût. Une requête qui déclenche déjà WordPress pour décider qu’elle doit être rejetée a déjà consommé des ressources.

Le filtrage applicatif est particulièrement utile quand vous avez des règles “métier” ou des logs applicatifs bien exploitables. Il faut juste éviter que la couche applicative devienne un goulet.

Construire votre stratégie sans aveuglement

Avant de poser des règles, prenez dix minutes pour identifier vos contraintes. Filtrer une URL générique peut casser une intégration, filtrer trop agressivement une méthode HTTP peut casser des outils de maintenance, et bloquer des plages d’IP peut gêner des partenaires.

Un exemple classique: vous mettez un filtre strict sur l’accès au panneau d’administration, mais vous avez une surveillance externe ou un service d’authentification qui passe par une IP fixe, différente de ce que vous aviez prévu. Le résultat est un accès cassé, pas une “attaque”.

Une autre situation fréquente: un site a un flux vers un service tiers (webhook) ou un mécanisme d’import. Si vous filtrez des endpoints “par principe” parce qu’ils ressemblent à une surface d’attaque, vous pouvez interrompre un traitement légitime.

Votre stratégie de sécurisation WordPress doit donc être structurée, mais pragmatique: d’abord réduire les risques faciles, ensuite affiner avec des mesures.

Le cœur du sujet: filtrer les requêtes à risque sur WordPress

Le filtrage le plus utile se concentre sur quelques zones qui souffrent presque toujours:

• la page de connexion et les tentatives d’authentification
• les accès à l’administration
• XML-RPC, quand il n’est pas nécessaire
• des chemins connus de scanners
• le trafic anormal en volume

Le fil conducteur est simple: si une requête n’a aucune chance d’être légitime dans votre contexte, rejetez-la tôt. Si une requête peut être légitime mais seulement dans certaines conditions, exigez ce contexte, plutôt que d’interdire en général.

Connexion et tentatives d’authentification

Même si vous n’avez qu’un site vitrine, les tentatives de mot de passe finissent par arriver. Là, le filtrage à risque a deux objectifs: ralentir et réduire la surface.

Sur la couche serveur, vous pouvez par exemple limiter le nombre de requêtes sur wp-login.php et sur les routes d’authentification connexes. Sur la couche applicative, vous pouvez mettre en place un mécanisme de lock ou de temporisation après plusieurs tentatives infructueuses.

Attention au piège des faux positifs: si votre site est accessible depuis un réseau d’entreprise avec des passerelles qui partagent une IP, une limitation stricte par IP peut empêcher plusieurs personnes. Dans ce cas, un contrôle par session ou par identité applicative peut être préférable, mais il est plus complexe.

Accès à wp-admin

L’administration est un endroit où l’on peut filtrer intelligemment. Si vous gérez le site depuis un réseau connu, un filtrage par IP source pour l’accès au back office est une réduction de risque très efficace.

Si vous devez y accéder depuis partout, vous pouvez quand même réduire le bruit en combinant deux choses: un challenge ou une limitation sur les tentatives, plus une vérification d’authentification forte (par exemple l’usage de clés, ou au minimum un mécanisme renforçant la connexion).

XML-RPC: désactiver quand ce n’est pas nécessaire

XML-RPC a longtemps été une surface d’attaque pratique. Beaucoup de sites n’en ont pas besoin. Si vous n’utilisez ni certains outils de publication distante, ni certaines intégrations qui en dépendent, le mieux est de le désactiver au niveau WordPress ou via des règles serveur.

Le point important est de ne pas désactiver “au hasard”. Vérifiez l’usage. Si vous avez des scripts d’import, des plugins qui publient automatiquement, ou des intégrations, ils peuvent en dépendre. Si vous coupez sans vérifier, vous vous créez un incident fonctionnel, ce qui est plus coûteux qu’une protection “un peu moins idéale”.

Réduction des probes basiques

Les scanners cherchent souvent les mêmes indices. Ils testent des URLs et des paramètres qui révèlent la technologie, la version ou des chemins internes. Vous pouvez filtrer des patterns manifestement non légitimes.

Ici, la prudence est de mise. Une règle trop large peut bloquer des requêtes de services légitimes. Le bon compromis consiste souvent à filtrer des patterns très spécifiques, et à observer les effets avant d’élargir.

Je recommande de mettre en place des règles en mode observation d’abord, quand c’est possible. Ensuite seulement, passez à un rejet.

Une méthode simple pour avancer, sans casser votre site

Plutôt que d’installer dix règles et d’espérer que ça marche, utilisez une progression logique. Je vous propose une méthode en cinq étapes.

• Commencez par mesurer: identifiez les endpoints les plus touchés (par exemple wp-login.php, wp-admin/, XML-RPC) et le volume par IP, si vous avez les logs.
• Ajoutez des règles “faciles” qui ont peu de chances de faux positifs, comme la désactivation XML-RPC si vous n’en avez pas besoin, ou une limitation simple de fréquence.
• Activez le rejet progressif, pas le blocage total. Commencez par ralentir ou répondre avec un code adapté, puis durcissez.
• Vérifiez l’impact fonctionnel: connexion admin, formulaires, webhooks, et intégrations tiers. Testez avec au moins un utilisateur réel.
• Surveillez après changement: comparez le volume des requêtes à risque, les erreurs HTTP, et la charge serveur sur 24 à 72 heures.

Cette démarche évite le piège du “ça a l’air mieux tout de suite”. Un filtrage trop agressif peut être indétectable pendant quelques heures, puis devenir visible lors d’une action plus rare: un plugin de sauvegarde, une synchro cron, ou un import mensuel.

Codes de réponse et comportement: rejeter oui, mais bien

Quand vous filtrez une requête, le code HTTP et la manière de répondre comptent. Un “404” peut masquer la surface et réduire les infos. Un “403” indique que l’accès est interdit. Un “429” informe qu’il y a une limitation.

En pratique, selon l’objectif, vous pouvez préférer:

• 403 pour des routes clairement interdites
• 404 pour des probes répétées où vous ne voulez pas “révéler” l’existence
• 429 si vous mettez un rate limiting et que vous voulez un signal explicite

Évitez de répondre de façon trop verbose. Le but est de minimiser les indices. Mais évitez aussi les réponses qui pourraient casser des clients légitimes qui interprètent mal certains codes.

Rate limiting: la protection qui marche, mais avec des garde-fous

Limiter la fréquence est souvent l’une des meilleures idées, parce que beaucoup de robots en font trop. Sur WordPress, un rate limit sur wp-login.php et sur certaines routes d’administration peut réduire énormément la charge.

Le problème, ce sont les cas limites:

• une personne qui rencontre un souci de réseau et retente la connexion
• plusieurs utilisateurs derrière une même sortie NAT
• un test de monitoring qui hit un endpoint à un rythme prévisible
• des outils d’intégration qui font des appels en boucle

La bonne approche consiste à appliquer le rate limit sur des endpoints spécifiques et à utiliser une fenêtre temporelle raisonnable. Une fenêtre très courte peut pénaliser une connexion légitime qui prend plus de temps. Une fenêtre trop longue réduit l’impact.

Sans données de charge, il vaut mieux commencer modéré, puis ajuster.

Intégrer le filtrage aux logs et à l’observabilité

Un filtre “fonctionne” seulement si vous pouvez le constater. Sinon, vous avez juste une modification de configuration.

Cherchez à répondre à trois questions après chaque changement:

• Le volume des requêtes à risque a-t-il baissé sur les endpoints ciblés ?
• Les erreurs HTTP ont-elles augmenté de manière inhabituelle sur des routes légitimes ?
• La charge serveur a-t-elle diminué, ou au moins s’est-elle stabilisée ?

Dans les logs, surveillez aussi le ratio de requêtes qui aboutissent à une action applicative. Si votre filtre est bien en amont, WordPress devrait être touché moins souvent.

Un détail pratique: gardez un échantillon d’IPs bloquées ou rejetées, et réévaluez périodiquement. Parfois, vous réalisez que vous avez bloqué des plages d’IP d’un fournisseur de VPN ou d’un outil d’automatisation interne.

Exemples de règles de filtrage qui apportent un vrai gain

Je ne vais pas vous donner une “recette universelle” de configuration, parce que les chemins exacts et les comportements varient selon votre stack. En revanche, je peux décrire des stratégies typiques, utiles en environnement réel.

Bloquer les méthodes et chemins manifestement non pertinents

Sur certaines routes, une méthode HTTP n’a aucune raison d’être utilisée. Si vous voyez des POST ou des GET sur des chemins où vous ne servez rien, c’est un signal. Vous pouvez réduire la surface en refusant certains combinaisons.

Réduire l’exposition des fichiers sensibles

Les scanners tentent aussi des requêtes sur des fichiers qui ne devraient pas être publics. Selon votre serveur, vous pouvez refuser certaines extensions ou certains chemins. Là aussi, la spécificité est la clé: mieux vaut cibler précisément que refuser “trop large”.

Protéger l’administration sans pénaliser le reste

Vous pouvez rendre wp-admin moins accessible aux requêtes non authentifiées en combinant accès par IP source (quand c’est possible), limites de fréquence sur les tentatives, et verrouillage applicatif. Le résultat est souvent immédiat, parce que l’attaque massive touche surtout l’authentification.

Choisir où appliquer les règles: WAF, serveur, ou WordPress

Quand on commence à filtrer, une question revient: où mettre la règle la plus importante ?

Voici une grille de décision simple, orientée pratique.

| Où placer la règle | Ce que ça fait bien | Limite fréquente | |---|---|---| | WAF/CDN | Réduction de volume en amont, protection de base contre patterns | Faux positifs si règles trop larges, complexité si vous gérez beaucoup d’exceptions | | nginx/Apache | Contrôle fin sur endpoints, rate limiting par route, gestion directe du code réponse | Nécessite une bonne connaissance du serveur, impact possible sur des clients inattendus | | WordPress (plugins ou hooks) | Granularité sur l’authentification et le contexte applicatif | Coût plus élevé, la requête atteint déjà PHP avant d’être rejetée |

Dans la plupart des cas qui tournent bien, on combine au moins deux couches. Par exemple: WAF pour le bruit général, serveur pour quelques protections immédiates, WordPress pour l’auth et les comportements de connexion.

Cas particuliers et pièges classiques

Il y a des cas où le filtrage “simple” se retourne contre vous.

Plugins qui utilisent des endpoints sensibles

Certains plugins appellent des routes que vous auriez tendance à considérer comme “risquées”. Par exemple, des connecteurs d’intégration peuvent utiliser des mécanismes proches d’API ou de méthodes spécifiques. Avant de désactiver ou de bloquer, vérifiez dans le plugin ce qu’il utilise.

Monitoring, tests, et outils d’uptime

Les systèmes d’uptime n’ont pas toujours un comportement identique à un navigateur. Si votre filtrage repose sur une analyse de User-Agent, vous risquez de faire du faux positif. Préférez des règles basées sur endpoints et fréquence, plutôt que sur un identifiant unique.

Multi-tenant, NAT, et IP partagées

Sur un hébergement partagé ou derrière un NAT d’entreprise, votre “filtrage par IP” peut être moins efficace qu’attendu. Si vous bloquez par IP source sans tenir compte de l’environnement, vous risquez de bloquer des utilisateurs légitimes. Dans ces cas, combinez un contrôle par endpoint et une limite de fréquence moins agressive.

Une mini stratégie de durcissement réaliste

Si vous voulez un point de départ concret, sans vous lancer dans un projet de sécurité trop ambitieux dès le premier jour, voici une approche de durcissement progressif. L’objectif est de faire baisser immédiatement les requêtes à risque, puis d’affiner.

Commencez par filtrer ce qui est le plus attaqué: la connexion et les routes d’administration. Ensuite, traitez XML-RPC si vous n’en avez pas besoin. Enfin, mettez un rate limiting ciblé pour éviter la saturation.

Une fois que vous voyez une baisse dans les logs, élargissez seulement si vous avez identifié de nouveaux motifs récurrents. C’est souvent là que les “requêtes à risque” évoluent: après une première série de blocages, les scanners testent autre chose, et vous pouvez réagir en observant, pas en devinant.

Ce que vous gagnerez, au-delà de la sécurité

Le filtrage des requêtes à risque ne sert pas uniquement à “éviter d’être hacké”. Il améliore aussi la qualité d’exploitation.

• Vous réduisez les pics de charge causés par des robots.
• Vous gagnez du temps dans l’analyse des incidents, parce que vos logs sont plus propres.
• Vous rendez les alertes plus fiables, moins noyées par le bruit.
• Vous diminuez le temps de réponse perçu lors des périodes de scan.

Et surtout, vous évitez l’effet “sécurité par accumulation de plugins” sans base technique. La sécurité devient une routine d’exploitation, pas un empilement.

Vérifier après déploiement: ce que je surveille toujours

Après avoir modifié des règles de filtrage, je fais un contrôle simple sur trois axes. C’est parfois plus instructif qu’un audit complet.

D’abord, je regarde les endpoints qui recevaient l’essentiel des requêtes à risque. S’ils ne bougent pas, c’est que le filtre n’atteint pas l’endroit où il faut, ou que les robots contournent déjà.

Ensuite, je surveille les erreurs applicatives. Une hausse des 404 ou 403 sur des routes légitimes peut indiquer que la règle est trop large, ou que vous avez des clients particuliers.

Enfin, je https://gardewp.fr/securite-wordpress/ contrôle la latence pendant 24 à 72 heures. Même si vous ne “bloquez” pas toutes les attaques, réduire le volume et la charge se traduit souvent par une sensation de stabilité.

La bonne sécurisation WordPress, c’est moins une question de “tout bloquer” qu’une question de choix et de discipline: filtrer ce qui est risqué, au bon endroit, avec assez de mesure pour ne pas casser le site.

Recommandation finale: faire du filtrage un processus

La menace évolue, mais votre approche peut rester stable. Gardez une logique d’observation, d’ajustement et de validation. Un filtre efficace n’est pas celui qui est le plus dur. C’est celui qui réduit réellement les requêtes à risque, sans pénaliser vos utilisateurs ni vos intégrations.

Si vous commencez petit, que vous mesurez, puis que vous durcissez graduellement, vous obtiendrez un gain tangible. Et ce gain est souvent double: moins de tentatives visibles, et un site plus robuste face aux pics de trafic automatiques.