On a vu des hébergeurs mutualisés où la latence du premier octet est passée de 300 ms à plus de 7 secondes en l’espace d’une heure. Pas à cause d’un plugin foireux ni d’une boucle de requêtes SQL. Juste un flux constant de requêtes POST sur /wp-login.php envoyé par un botnet de plusieurs dizaines de milliers de machines. Avril 2013. L’attaque WordPress la plus massive jamais orchestrée à l’époque. Et un révélateur brutal : la sécurité d’une installation WordPress n’est pas qu’un problème d’accès aux données. C’est un problème de performance, d’indexation et de crawl budget.
Ce qui s’est réellement passé en avril 2013
L’attaque a ciblé n’importe quel site propulsé par WordPress, sans distinction de version ou de hébergeur. Le principe : un botnet tentait des connexions par force brute sur /wp-login.php en utilisant des listes de mots de passe courants, avec le nom d’utilisateur “admin” ou d’autres logins fréquents. Pas de faille zero-day, pas de ransomware. Une attaque frontale, simple, automatisée.
À l’échelle d’un serveur mutualisé hébergeant 200 ou 300 sites, l’effet a été immédiat. Chaque tentative de connexion déclenchait une exécution PHP complète, sollicitait la base de données MySQL, et consommait du CPU. Multiplié par plusieurs centaines de milliers de requêtes par heure, le serveur s’effondrait. Le temps de réponse moyen grimpait en flèche, la mémoire disponible fondait, et certains hébergeurs ont mis hors ligne les sites les plus ciblés pour protéger le reste du parc.
Pour Googlebot, qui passait à ce moment-là pour crawler les pages, le constat était simple : le serveur ne répondait pas, ou renvoyait des timeouts. Résultat : des URLs désindexées, une chute du crawl quotidien, et pour les e-commerces, des pans entiers de catalogue qui disparaissaient des résultats.
Quand la charge CPU détruit le TTFB et le crawl budget
Ici, le signal de classement n’était pas la qualité du contenu, mais la capacité de la page à être servie en moins de 2 secondes. En 2013, le TTFB n’était pas encore une métrique officielle des Core Web Vitals, mais les ingénieurs Google alertaient déjà sur l’impact des temps de réponse serveur sur le crawl. Un serveur lent, c’est un robot qui ralentit sa cadence pour ne pas le surcharger. Et quand le robot ralentit, les nouvelles pages mettent plus de temps à être découvertes, les mises à jour sont repoussées, le site perd en fraîcheur.
Pendant l’attaque d’avril, le TTFB moyen d’un site WordPress sur un mutualisé de milieu de gamme pouvait atteindre 8 à 12 secondes, dans le meilleur des cas. Dans le pire, l’erreur 502 ou 504 remplaçait la page d’accueil. Googlebot recevait une série de codes HTTP 5xx et en déduisait une instabilité suffisante pour réduire la fréquence de visite. Des référenceurs ont vu le nombre de pages “crawlées par jour” divisé par trois en une semaine. Ceux qui ont mis plusieurs jours à réagir ont mis des mois à retrouver leur indexation complète.
C’est ce lien direct entre disponibilité serveur et optimisation core web vitals qui reste la leçon principale de cet événement. On a tendance à dissocier sécurité et SEO, mais un serveur sous attaque peut briser tous les efforts d’optimisation de LCP ou d’INP. Une page qui ne se charge pas, c’est un signal de classement qui n’existe tout simplement pas.
Le piège des plugins de sécurité et des .htaccess bricolés
La réaction immédiate de beaucoup de propriétaires de sites a été d’installer un plugin de limitation de connexions ou d’ajouter des règles manuelles dans le fichier .htaccess pour bloquer les IP malveillantes. Problème : un botnet de cette taille change d’IP en permanence. Bloquer les adresses une par une n’arrêtait rien, et les plugins qui tentent de le faire côté PHP ajoutaient eux-mêmes une charge supplémentaire à chaque requête.
On a vu des sites où le plugin Wordfence ou Limit Login Attempts alourdissait l’exécution PHP de 200 ms par tentative, juste pour vérifier une base de données d’IP bannies. La parade aggravait le symptôme. Le serveur finissait par passer plus de temps à exécuter le code de sécurité qu’à servir la page demandée. La bonne approche, déjà à l’époque, consistait à placer le blocage en amont de PHP. Un simple rate limiting au niveau du reverse proxy, ou une règle de pare-feu applicatif (WAF) capable de détecter une rafale de POST sur /wp-login.php sans réveiller le backend.
La réponse moderne : edge functions et rate limiting
Douze ans plus tard, la surface d’attaque est restée identique. /wp-login.php existe toujours, et les tentatives de force brute n’ont jamais cessé. Ce qui a changé, c’est que déployer une règle de rate limiting sur un edge n’est plus réservé aux gros comptes Cloudflare Entreprise. Les plateformes d’hébergement modernes et les CDN proposent des edge functions capables d’intercepter une requête avant qu’elle n’atteigne le serveur d’origine.
En 2026, une protection efficace repose sur trois couches :
- Un WAF qui bloque les patterns de force brute, avec une règle spécifique pour l’URL de login et une limite de tentatives par IP sur une fenêtre glissante.
- Un cache agressif des pages publiques, pour que le trafic légitime ne sollicite pas PHP pendant une attaque.
- Une surveillance continue du TTFB et du ratio de requêtes POST sur
/wp-login.php, avec alertes.
Cette approche ne nécessite aucun plugin. Une configuration Cloudflare Workers ou un middleware Fastly permet de rédiger la règle en quelques dizaines de lignes de JavaScript. Et si vous avez l’habitude d’utiliser un IDE comme Cursor ou un assistant type Claude Code pour générer du code, écrire ce middleware prend moins de 15 minutes.
Pourquoi la sécurité est un facteur SEO direct
Les algorithmes de classement n’analysent pas votre politique de mot de passe. Mais ils mesurent la disponibilité et la vitesse de réponse. Un site régulièrement down ou qui renvoie des erreurs 5xx verra son crawl budget réduit, ses signaux d’utilisateur se dégrader, et ses pages fraîchement publiées mises en file d’attente. Le SEO technique intègre désormais la résilience aux attaques comme une composante à part entière.
Quand on audite un site qui a perdu 30 % de ses pages indexées sans explication apparente, on consulte d’abord les logs serveur pour vérifier la part de requêtes anormales. Une attaque par force brute discrète, qui génère un taux d’erreur 403 ou 429 sans saturer complètement le serveur, peut quand même user le budget de crawl alloué au domaine. Googlebot n’a pas vocation à passer son temps à recevoir des pages d’erreur, même si elles sont techniquement 4xx.
C’est aussi une question de stabilité dans le temps. Une page qui passe de 200 à 403 puis à 200 au fil des heures envoie un signal d’indécision. À force, Google peut retarder la prise en compte des modifications de contenu ou ignorer temporairement une section du site. L’attaque d’avril 2013 a montré que même les gros volumes de contenu bien optimisé ne servent à rien si l’infrastructure ne tient pas.
Auditer son exposition aujourd’hui
L’exercice est rapide. Ouvrez les logs d’accès des dernières 24 heures et isolez les requêtes sur /wp-login.php avec un code 200 ou 403. Si le volume dépasse quelques centaines par heure sur un site modeste, il y a un problème. Regardez aussi la courbe du TTFB sur la même période : une corrélation entre les pics de tentatives de login et une dégradation du TTFB indique que le serveur commence à souffrir.
La parade immédiate consiste à déplacer la gestion du login derrière une règle qui n’atteindra jamais PHP. Sur Apache, cela signifie utiliser mod_security ou un proxy externe. Sur Nginx, un simple limit_req sur la location /wp-login.php suffit à absorber une rafale modérée. Et si vous hébergez encore sur du mutualisé sans accès à la configuration serveur, passer à un VPS ou à un service managé avec WAF intégré devient une priorité, pas un confort.
Pour les équipes qui gèrent plusieurs sites, monitorer ces métriques avec un tableau de bord maison est un projet d’une journée. Une stack React avec Zustand pour l’état local, des appels à l’API de votre CDN, et vous visualisez en temps réel les tentatives échouées par site. Pas besoin d’une usine à gaz pour corréler sécurité et performance.
Questions fréquentes
L’attaque d’avril 2013 visait-elle aussi les sites en HTTPS ? En 2013, le HTTPS était encore minoritaire sur les sites WordPress. L’attaque visait principalement le port 80, mais les connexions sécurisées n’auraient pas changé grand-chose : le botnet envoyait des requêtes POST valides, le chiffrement ne bloque pas ce type de tentative. Le passage au HTTPS protège la confidentialité des échanges, pas la disponibilité du serveur.
Faut-il renommer le fichier wp-login.php ? Techniquement possible avec certaines solutions, mais déconseillé à grande échelle. Cela casse les mises à jour automatiques et complique la compatibilité avec des plugins qui font référence à l’URL standard. Un rate limiting bien configuré et une authentification forte (double facteur, mots de passe complexes) sont plus maintenables sur la durée.
Les attaques par force brute existent-elles encore en 2026 ? Elles n’ont jamais disparu, et les hébergeurs mutualisés restent les cibles de choix. La différence, c’est que la plupart des sites passent désormais par un CDN qui filtre ce trafic en amont. Un wp-login.php non protégé reçoit en moyenne plusieurs milliers de tentatives par mois, même sur un petit blog.
