WordPress est-il sûr ? Pourquoi passer au sur mesure

WordPress fait tourner plus de 4 sites web sur 10 dans le monde. C'est justement pour ça qu'il est la cible préférée des attaques automatisées : une seule faille fonctionne contre des millions de sites. Avec l'intelligence artificielle, ces attaques arrivent de plus en plus vite. Voici ce qui se passe, pourquoi un site sur mesure avec sa propre administration est plus sûr, et comment je protège les sites que je développe.

Les chiffres de 2025

Le rapport annuel de Patchstack, spécialiste de la sécurité WordPress, est sans appel :

Le cœur de WordPress est plutôt solide (seulement 6 failles signalées en 2025). Le problème, c'est tout ce qu'on y ajoute : plugins de formulaires, carrousels, boutiques, constructeurs de pages… chacun écrit par un auteur différent, certains abandonnés depuis des années.

L'IA accélère les attaques

Avant, il se passait des jours entre la publication d'une faille et son exploitation. Aujourd'hui, ce sont des heures : avec l'IA, un attaquant compare la version corrigée à l'ancienne, comprend ce qui a été réparé et génère une attaque prête à être lancée contre des milliers de sites.

Le meilleur exemple est « wp2shell », en juillet 2026 : la première faille critique du cœur de WordPress exploitable sans mot de passe depuis près de dix ans, selon Wordfence. Elle a été découverte avec l'aide d'un modèle d'IA. Le correctif est sorti le 17 juillet et, en quelques heures, des attaques publiques circulaient déjà, avec des dizaines de milliers de tentatives et de faux comptes administrateur créés sur les sites non mis à jour (BleepingComputer).

Pourquoi le WordPress d'une PME est si exposé

• Beaucoup de plugins tiers, chacun avec son propre code et ses propres failles.
• Des mises à jour que personne ne fait : le site a été fait il y a des années et personne ne l'entretient.
• Des adresses connues de tous : /wp-admin, /wp-login.php, /xmlrpc.php. Les robots les testent sur tous les sites d'internet, toute la journée.
• Une même attaque vaut pour des millions de sites : c'est rentable pour l'attaquant.

Pourquoi un site sur mesure est plus sûr

• Moins de surface d'attaque : seul existe le code dont votre entreprise a besoin, sans plugins tiers.
• Pas d'attaque « en série » : une faille générique de WordPress ne sert à rien contre un système unique.
• Votre propre administration, à une adresse qui n'est pas celle de tout le monde, avec mots de passe robustes, blocage après plusieurs échecs et rôles (chaque utilisateur ne voit que ce qui le concerne).
• Une plateforme maintenue : .NET reçoit les correctifs de sécurité de Microsoft, et les requêtes à la base de données sont paramétrées, ce qui ferme la porte à l'injection SQL.

Attention : « sur mesure » ne veut pas dire automatiquement « sûr ». Un système sur mesure mal fait est vulnérable lui aussi. Ce qui compte, ce sont les bonnes pratiques, et voici les miennes.

Comment je protège les sites que je développe

1. Un filtre de sécurité dans l'application

• Il bloque les outils d'attaque connus (sqlmap, nikto, wpscan, nuclei…) par leur signature.
• Il bloque les chemins suspects : /wp-admin, /wp-login, .env, .git, phpmyadmin, web.config, appsettings.json. Le paradoxe : mes sites en .NET reçoivent chaque jour des tentatives d'attaque visant WordPress, coupées immédiatement.
• Il limite le nombre de requêtes par adresse IP et bloque temporairement les abus.
• Il détecte les tentatives d'injection SQL et de XSS avec des signatures précises, pas des règles grossières. J'ai appris qu'un filtre trop large fait plus de mal que de bien : une règle qui bloquait toute URL contenant « 0x » cassait au hasard certains fichiers du site.

2. Ne jamais bloquer Google (ni l'IA qui vous recommande)

Un filtre agressif qui renvoie « accès interdit » à Googlebot fait disparaître votre site de Google. Les moteurs de recherche et les assistants IA légitimes sont exemptés de la limite de requêtes, tandis que le robots.txt bloque les scrapers SEO qui ne font que consommer des ressources.

3. Des formulaires blindés

Validation côté serveur, protection anti-falsification, reCAPTCHA ou un champ piège invisible que seuls les robots remplissent, et détection des envois trop rapides pour être humains.

4. Un serveur IIS bien configuré

• HTTPS obligatoire avec HSTS, et redirection vers une seule adresse (avec www).
• Des en-têtes de sécurité, et la version du serveur masquée.
• Une taille maximale pour les fichiers envoyés.
• Les secrets (mots de passe, clés d'API) hors du code et hors du dossier public.
• Chaque site avec sa propre identité de pool d'applications, avec des droits minimaux.

Un extrait du web.config que j'utilise :

<system.webServer>
  <security>
    <requestFiltering removeServerHeader="true">
      <requestLimits maxAllowedContentLength="10485760" />
    </requestFiltering>
  </security>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

5. Sauvegardes et surveillance

Sauvegardes automatiques de la base, restauration testée, et lecture des journaux pour repérer l'anormal.

Passer de WordPress au sur mesure sans perdre Google

La migration conserve le contenu, les images et surtout les adresses : chaque ancienne URL redirige (301) vers la nouvelle pour ne pas perdre le référencement acquis. Au passage, on gagne en vitesse, et on obtient une administration pensée uniquement pour ce dont vous avez besoin. Plus de détails sur mon offre de migration .NET.