Sécurité WordPress : audit du CDN et de la protection contre DDoS

Quand un site WordPress ralentit ou tombe, la cause n’est pas toujours “le piratage”. Souvent, c’est un enchaînement plus banal: un trafic énorme qui épuise la capacité, un CDN mal configuré qui laisse passer trop d’origin hits, ou une protection DDoS qui détecte, bloque partiellement, puis laisse quand même des requêtes coûteuses atteindre PHP et la base. J’ai vu des sites qui semblaient “protégés” sur le papier, mais dont l’architecture faisait que l’origine prenait le choc au pire moment, au point de déclencher des délais, des timeouts, puis des effets en cascade côté base de données.

Un audit du CDN et de la défense DDoS doit donc être concret, orienté flux, et axé sur les coûts réels: combien de requêtes atteignent l’origine, quels chemins applicatifs sont les plus sollicités, quels headers et quels paramètres changent entre le trafic normal et le trafic anormal. Dans ce billet, je propose une méthode d’audit et de sécurisation WordPress centrée sur le réseau, sans perdre de vue ce qui finit, inévitablement, par toucher WordPress.

Comprendre le rôle exact du CDN dans votre stratégie anti-DDoS

Un CDN n’est pas seulement un “accélérateur”. C’est un filtre, une cache layer, et parfois un pare feu applicatif en amont. En pratique, la différence entre un CDN utile et un CDN décoratif se voit dans deux métriques simples:

• le taux de requêtes servies au niveau du CDN (cache hit) au lieu d’être relayées à l’origine,
• la part du trafic qui conserve un comportement compatible avec la cache et la sécurité (requêtes statiques, bonnes méthodes HTTP, patterns attendus).

Dans un incident DDoS classique (volume élevé ou rafales), le vrai problème n’est pas forcément la bande passante. C’est la combinaison entre le trafic entrant et la façon dont votre application traite ce trafic. WordPress, particulièrement avec des pages dynamiques, des plugins et des endpoints (recherche, login, REST API), peut transformer un pic réseau en surcharge applicative.

Je me souviens d’un audit où le CDN était “actif” et visible dans l’interface, mais où l’on constatait un volume très élevé de requêtes vers wp-admin et certains scripts à faible cacheabilité. Les pics de CPU venait d’ailleurs, l’origine était sollicitée comme si le CDN n’existait pas. Le point n’était pas de “changer de CDN”, mais d’aligner configuration, cache et règles de protection pour que l’origine reste silencieuse.

Ce qu’il faut auditer avant de toucher aux règles

Avant de modifier la configuration, il faut cartographier. Une règle DDoS trop permissive ou mal pensée, ça ne se voit pas toujours en temps normal. Par contre, en période de test ou lors d’un événement, ça devient évident.

Concrètement, vérifiez l’état de base:

• Votre domaine pointe-t-il bien sur le CDN (CNAME, A records, mode proxifié si votre provider en a un)?
• Le CDN protège-t-il réellement toutes les routes, ou seulement une partie du périmètre?
• Avez-vous plusieurs domaines, sous-domaines (par exemple www, media, api) avec des traitements différents?
• Les DNS de certains sous-domaines contournent-ils le CDN de façon involontaire?

Ensuite, examinez la manière dont WordPress produit les réponses. Un CDN peut être efficace sur les assets (images, CSS, JS), mais si vos pages HTML restent quasi systématiquement dynamiques (absence de cache, cookies mal gérés, headers de non-cache), vous perdez une grande partie de la protection “indirecte” du CDN. Et quand la cache HTML ne tient pas, tout finit au PHP.

Enfin, pensez “chemins coûteux”. Même si vous bloquez beaucoup de trafic au niveau réseau, il existe toujours des endpoints qui méritent une attention spéciale: login, XML-RPC, wp-json, sitemap, pages search, pages avec commentaires, et parfois des hooks de plugins.

Mesurer l’impact CDN vs origine: les indicateurs à regarder

Un audit utile ne se contente pas d’ouvrir un dashboard. Il cherche des preuves de flux. Selon votre stack, vous pouvez croiser plusieurs signaux: logs CDN, logs web serveur, métriques applicatives, et parfois traces au niveau du reverse proxy.

Les indicateurs que j’utilise le plus:

• Ratio de requêtes servies depuis le cache (cache hit) versus requêtes passées à l’origine.
• Distribution des codes HTTP, en particulier 2xx, 3xx, 4xx et 5xx, pendant et juste après une rafale.
• Volume d’origin hits par seconde (même un ordre de grandeur suffit): si ça monte au même rythme que l’entrée, c’est que la cache ne joue plus son rôle.
• Temps de réponse P95 ou P99 côté edge et côté origine. Une hausse P99 côté origine est souvent un signe de saturation applicative.
• Headers révélateurs comme X-Forwarded-For, True-Client-IP (si votre CDN le fournit), ou l’absence de certains headers attendus. Si WordPress “voit” le mauvais IP, les règles anti-brute force et les logs peuvent devenir inutiles.

À ce stade, évitez l’erreur classique: ajouter des règles au hasard parce que “ça semble mieux dans le panneau”. Ce qui compte, c’est ce que votre trafic réellement fait.

Audit et sécurisation WordPress: vérifier la cohérence cache, headers et cookies

WordPress et ses plugins peuvent casser la cache sans que personne ne s’en rende compte. Il suffit d’un plugin qui injecte des cookies, d’un template qui ajoute des headers “no-store”, ou d’une configuration qui sort un “Set-Cookie” sur trop de réponses.

Le premier réflexe consiste à analyser un échantillon de réponses:

• Les pages publiques ont-elles un comportement stable en matière de cache?
• Les assets statiques sont-ils bien cacheables côté CDN?
• Les pages dynamiques sont-elles strictement celles qui doivent l’être?

Ensuite, regardez la différence entre requêtes “navigateur normal” et requêtes “script/robot”. Beaucoup de DDoS par application imitent un navigateur, mais pas parfaitement. Si vous voyez des patterns de headers incohérents ou des méthodes inattendues, c’est un levier.

Enfin, traquez l’effet cookies. Un CDN peut choisir de ne pas servir le cache si des cookies spécifiques sont présents. Un bug de configuration, comme un cookie inutile ajouté à toutes les pages, peut réduire drastiquement le taux de cache hit et donc augmenter les origin hits.

Mettre au propre les règles CDN avant la défense DDoS

Une défense DDoS efficace n’est pas uniquement “bloquer”. C’est aussi “ne pas envoyer d’effort là où il ne doit pas aller”. Si vous laissez trop de requêtes dynamiques jusqu’à l’origine, vous utilisez PHP et MySQL comme amortisseur. Sur un incident, ça ne tient pas.

L’audit des règles CDN, c’est donc un exercice d’alignement:

• règles d’edge qui bloquent ou challengeent les patterns clairement abusifs,
• cache rules qui limitent les origin hits,
• protections ciblées sur les endpoints à haut risque,
• cohérence des timeouts et de la gestion d’erreur.

Je recommande de commencer par des ajustements qui ne cassent pas l’usage normal. Une fois que vous savez que la cache est plus stable et que l’origine est moins sollicitée, vous pouvez renforcer les protections.

Voici une première checklist opérationnelle, utile pour cadrer l’audit sans vous perdre.

• Vérifier que tout le trafic pour le domaine passe bien par le CDN, y compris les sous-domaines de médias.
• Contrôler les origin hits par seconde et les corréler avec les endpoint les plus sollicités (wp-admin, wp-login, wp-json, recherche).
• Échantillonner des réponses HTML et vérifier la présence de headers et cookies qui empêchent le cache.
• Tester la stabilité en charge légère, puis moyenne, pour observer si P95 P99 de l’origine grimpe anormalement.
• Valider que les IP réelles sont bien celles que WordPress utilise pour le filtrage et les logs (headers de client).

Cette checklist n’est pas un script magique. Elle sert à obtenir des “faits” avant d’agir.

Test pratique: comment valider que la cache protège vraiment

Vous pouvez faire des tests plus ou moins réalistes. L’objectif n’est pas d’organiser un vrai DDoS, ni d’abîmer votre service. L’objectif est de vérifier la logique de routage et de cache sous contraintes.

Un test utile ressemble à ceci: vous simulez une augmentation de requêtes vers des pages et des assets, puis vous comparez les origin hits. Si le CDN est configuré correctement, vous devez voir un comportement où les assets et, selon votre stratégie, une partie du HTML restent majoritairement servis depuis l’edge.

Si vous constatez que chaque requête rejoint l’origine, vous avez au minimum un problème de cache, au pire un problème de règles CDN qui bypassent la cache.

Edge case à connaître: certaines pages nécessitent réellement un rendu dynamique pour chaque utilisateur. Dans ce cas, l’approche n’est pas de forcer la cache sur tout, mais de durcir la défense sur les endpoints dynamiques. On traite alors l’origine comme une ressource rare, pas comme un service prêt à absorber.

Renforcer la protection DDoS sans dégrader l’expérience

La plupart des fournisseurs DDoS ont des modes, des seuils, des challenges et des règles de réputation. Mais la sécurité, ce n’est pas uniquement la capacité à bloquer. C’est aussi la capacité à ne pas bloquer les bons clients.

Dans un audit, je cherche trois choses:

1) Est-ce que la protection agit avant l’origine, ou seulement après? 2) Est-ce qu’elle challenge au lieu de bloquer, quand c’est pertinent? 3) Est-ce que les faux positifs sont plausibles, par exemple avec des crawlers légitimes, des outils de monitoring, ou des navigateurs en réseau mobile?

Un mauvais réglage peut réduire l’efficacité. Par exemple, si vous challengez trop agressivement des routes qui devraient rester ouvertes, vous pouvez provoquer des boucles de validation, des délais, et une perception de panne alors que vous n’êtes pas réellement submergé.

Autre cas: la latence induite par certaines protections. Même si elles “tiennent”, si elles augmentent le temps de réponse côté edge, vous transformez la charge en attente et vous finissez par saturer les ressources applicatives derrière.

Quels signaux indiquent une attaque applicative via WordPress

Certaines attaques ne se manifestent pas comme un “gros volume” uniforme. Elles cherchent plutôt des points faibles: un endpoint qui fait beaucoup de travail, une recherche non protégée, un REST API exposé, ou XML-RPC qui peut https://gardewp.fr/securite-wordpress/ devenir coûteux.

Il y a des signaux, et ils se voient souvent dans les logs. Voici ceux que je surveille le plus, car ils permettent d’ajuster la défense sans trop de tâtonnement.

• Montée d’erreurs 4xx sur des endpoints spécifiques, surtout wp-login.php, wp-admin, xmlrpc.php, ou wp-json.
• Volumes anormaux sur la recherche WordPress et sur des pages qui devraient être cacheables.
• Requêtes avec User-Agent incohérent ou chaînes trop répétitives, qui n’imitent pas réellement un navigateur.
• Hausse des timeouts ou des 5xx côté origine corrélée à certains chemins applicatifs.
• Patterns de cookies et headers qui indiquent un client automatisé plutôt qu’un utilisateur.

Même sans “deviner” l’attaque exacte, ces signaux guident vers les bons leviers: règles d’accès ciblées, ajustements cache, et limitation de requêtes pour les routes sensibles.

Durcir les endpoints WordPress exposés au trafic

Une protection CDN et DDoS solide ne remplace pas la discipline applicative. C’est là que l’audit et sécurisation WordPress devient concret, parce que WordPress a des zones par nature plus exposées.

Sans rentrer dans un catalogue de plugins, la logique est simple: réduire la surface utile, et surtout réduire le coût. Quelques principes orientés résultats:

• Bloquer ou limiter ce qui ne devrait pas être accessible publiquement, selon votre politique.
• Réduire les effets de bord liés aux logs, parce que l’excès de logs peut lui aussi devenir un facteur de surcharge.
• S’assurer que le rate limiting existe là où le coût est élevé.

Un point souvent négligé: XML-RPC, REST API, et la page de recherche. Même quand la page semble “publique”, les requêtes de recherche peuvent déclencher des requêtes base de données coûteuses. Les attaques DDoS applicatives cherchent précisément ce genre de coût.

Assurer la qualité des erreurs: ne pas transformer un incident en incendie

Quand le trafic est mauvais, l’application doit “échouer proprement”. Sinon, vous convertissez une attaque en panne plus large.

Je vois souvent deux symptômes:

• des timeouts qui s’additionnent, donc votre pool PHP se remplit et la latence globale explose,
• des erreurs 500 répétées qui déclenchent des comportements en chaîne, par exemple des redémarrages automatiques de certaines couches.

D’un point de vue audit, vous devez vérifier que vos couches de proxy et votre serveur web ont des timeouts cohérents avec ce que l’edge attend. Si le CDN coupe trop tard, vous payez la saturation. S’il coupe trop tôt, vous risquez de créer un bruit de fausses pannes.

Le CDN peut aussi vous aider à présenter des erreurs contrôlées. Mais faites attention: si vous configurez une page d’erreur qui n’est pas cacheable ou qui déclenche un plugin, vous pouvez aggraver le trafic au lieu de le calmer.

Revoir la géographie, le protocole et les protocoles alternatifs

Un audit sérieusement mené tient compte des contraintes réseau. Selon votre configuration, certaines régions ou certains protocoles (HTTP/2, HTTP/3 si vous l’activez) peuvent influencer le comportement du CDN et de certaines protections.

Ce que je vérifie:

• Le profil de trafic pendant les pics. Si tout vient d’une zone inhabituelle, vous pouvez ajuster certaines règles, mais uniquement avec prudence.
• La cohérence entre HTTPS partout et redirections. Un site qui redirige de façon inattendue peut créer des boucles de requêtes ou multiplier les round trips.
• Le comportement des requêtes vers des chemins “non standards”. Certaines attaques scannent et testent, et si vos règles sont trop permissives, l’origine subit.

On peut gagner beaucoup en stabilité en supprimant les chemins inattendus ou en forçant des comportements simples et invariants.

Exemples d’ajustements qui changent vraiment le ratio cache hit

Sans donner de “recette universelle”, voici des ajustements qui reviennent souvent lors d’audits réussis:

• Corriger les headers cache sur les assets, surtout si des plugins modifient les réponses ou injectent des cookies partout.
• Ajuster les règles CDN pour ne pas bypasser la cache pour des raisons inutiles. Par exemple, un header de tracking peut être mal interprété.
• Vérifier les règles de compression et de minification, car une réponse mal formée ou trop lourde peut augmenter la taille transférée, donc le coût.
• Restreindre les endpoints dynamiques à des chemins précis, avec des règles d’accès et de rate limiting.
• Éviter les comportements qui déclenchent des requêtes lourdes lors de l’erreur. Par exemple, une page de 403 qui reconstruit tout WordPress au lieu de servir une réponse statique.

Ces points ne sont pas “spectaculaires”, mais ils déplacent le trafic, et c’est ce qui compte.

Plan d’action sur deux phases: stabiliser, puis durcir

Pour éviter de casser votre site, l’audit et sécurisation WordPress se fait par étapes. La première phase consiste à réduire l’impact de la couche réseau sur WordPress. La seconde phase consiste à durcir, en particulier sur les endpoints qui supportent mal la charge.

Phase 1, stabilisation: vous cherchez à rendre la cache plus efficace et à diminuer les origin hits. La mesure de réussite est simple: moins de requêtes atteignent l’origine pour le même volume de trafic, et les P95/P99 de la couche applicative restent sous contrôle.

Phase 2, durcissement: vous élargissez les protections DDoS, mais de manière ciblée. L’objectif est d’éviter les faux positifs et de garder une expérience acceptable pour les utilisateurs légitimes. Si vous devez challenge, faites-le là où ça protège vraiment, et pas sur tout le site par réflexe.

Gestion des logs et de la preuve en cas d’incident

Une protection DDoS “qui marche” doit aussi vous fournir des preuves. Sans logs, vous naviguez à l’aveugle et vous reproduisez des erreurs.

Dans l’audit, vérifiez:

• quels événements sont enregistrés côté CDN (bloqué, challenge, route vers l’origine),
• si vos logs web serveur incluent les IP réelles via les headers corrects,
• si WordPress peut corréler certains endpoints aux périodes de pics.

Je conseille de conserver une fenêtre de logs suffisamment longue pour corréler un incident. Les durées dépendent de votre politique et du coût de stockage, mais au minimum, prévoyez une période qui couvre la durée d’une enquête “raisonnable”.

En parallèle, demandez-vous qui doit pouvoir agir. Si la sécurité est gérée par une personne, mais que l’outillage ne permet pas de lire vite et bien les données, vous perdez des heures précieuses lors d’un événement.

Les compromis à anticiper (cache, sécurité, compatibilité)

Le CDN et la protection DDoS sont des leviers puissants, mais ils imposent des compromis.

• Une cache plus agressive peut surprendre certaines fonctionnalités, par exemple des pages qui devraient intégrer un état utilisateur.
• Un durcissement plus strict peut bloquer des outils d’analyse, des lecteurs de flux, ou des clients IoT qui n’imitaient pas bien un navigateur.
• Une défense DDoS plus “sévère” peut augmenter la latence de challenge, ce qui se voit surtout lors de pics modérés.

Lors d’un audit, je préfère documenter les décisions. Pas besoin d’un roman, mais au moins une note claire sur “pourquoi ce endpoint est traité ainsi” et “quels impacts attendus”. Cela évite de réagir au prochain incident comme si vous découvriez le problème.

Checklist de fin d’audit: valider que tout s’emboîte

Avant de clore un audit, je fais une dernière vérification d’architecture. Pas en mode “tout est parfait”, mais en mode “on sait ce qui se passe quand ça déraille”.

• Confirmer que l’origine ne reçoit pas inutilement du trafic pour les contenus qui devraient être servis depuis l’edge.
• Vérifier que les endpoints coûteux sont identifiés et protégés de façon cohérente avec leur exposition réelle.
• Contrôler que les IP utilisateur exploitées par WordPress correspondent à la réalité (headers).
• Valider que les timeouts et les retours d’erreur ne transforment pas un pic en panne globale.
• S’assurer que les journaux permettent une enquête rapide, sans dépendre d’un seul tableau de bord.

À ce stade, vous avez une sécurité réseau plus robuste, mais surtout une explication défendable de votre posture.

Ce que je recommande comme routine, après l’audit

Un CDN et une défense DDoS ne sont pas “réglés une fois”. Ils évoluent avec vos plugins, votre thème, votre trafic, et vos habitudes de déploiement. Après l’audit, mettez en place une routine légère:

• relire les patterns d’origine hits après chaque changement significatif (nouveau plugin, nouveau thème, mise à jour majeure),
• surveiller l’évolution des codes HTTP, en particulier quand vous modifiez la cache,
• tester régulièrement un petit scénario de charge et vérifier que le comportement reste cohérent.

Le but n’est pas de vivre en stress. Le but est de détecter tôt, quand les signaux sont encore faibles, que votre cache se dégrade ou que WordPress devient plus coûteux qu’avant.

Si vous souhaitez, je peux aussi adapter cette démarche à votre configuration exacte (CDN utilisé, type de reverse proxy, organisation DNS, plugins clés, endpoints exposés). Avec ces éléments, on peut transformer l’audit en plan d’actions plus précis, en gardant vos contraintes de performance et d’expérience utilisateur.