Sécurité WordPress : comment gérer correctement les domaines et DNS
Gérer un site WordPress, ce n’est pas seulement installer un thème et maintenir des mises à jour. Une grande partie de la sécurité se joue en amont, au niveau du domaine et des DNS. Les attaques les plus douloureuses ne passent pas toujours par WordPress lui-même, elles commencent parfois avec un changement de résolution, un oubli de verrouillage chez le registrar, ou une zone DNS laissée “ouvertes à tout”.
Sur le terrain, j’ai vu des incidents où le site n’était pas piraté, mais rendu indisponible pendant des heures, parce que le changement DNS a été fait trop vite, avec des enregistrements incomplets. J’ai aussi vu des redirections vers une mauvaise destination, et dans un cas précis, la cause était une mise à jour partielle du CNAME entre l’ancien et le nouveau fournisseur. Dans tous les cas, comprendre la mécanique domaine et DNS fait gagner du temps, et surtout évite des catastrophes évitables.
Domaine, DNS, et pourquoi la sécurité se joue en premier
Le domaine, c’est l’identité. C’est https://gardewp.fr/securite-wordpress/ ce que les gens tapent dans leur navigateur, et c’est ce que les systèmes utilisent pour retrouver un service. Les DNS, eux, sont le carnet d’adresses: ils indiquent à qui appartient chaque “nom” (www, blog, mail, etc.) Et vers quoi il pointe (une adresse IP, un nom d’hôte, une route mail, des clés, etc.).
D’un point de vue sécurité WordPress, il faut raisonner en couches :
Votre site WordPress est derrière un nom de domaine, donc toute altération du mapping “nom vers destination” a un impact direct. Les DNS conditionnent aussi l’envoi d’e-mails (MX, SPF, DKIM, DMARC). Un domaine mal configuré peut livrer de la fraude ou faciliter l’usurpation. La gestion des comptes qui contrôlent ces paramètres (registrar, panneau DNS, API) est une surface d’attaque en soi. Les DNS ne se compromettent pas par magie, ils se compromettent par accès humain.
La sécurité ne vient pas d’un “secret”. Elle vient d’un contrôle strict: limiter qui peut changer quoi, rendre les changements traçables, et concevoir des mécanismes de repli.
Verrouiller le registrar: la première barrière (souvent négligée)
La première étape concrète, c’est le registrar, le service chez lequel le domaine est enregistré. C’est là que vous définissez les serveurs DNS (nameservers), et souvent c’est là aussi que se gèrent les transferts et les protections de base.
Un scénario fréquent: quelqu’un obtient un accès à votre compte registrar via un mot de passe réutilisé, ou via une session non sécurisée. Il ne faut alors pas grand chose pour provoquer un basculement de nameservers vers une zone DNS contrôlée par l’attaquant. Même si votre hébergeur et WordPress n’ont rien, votre site peut pointer ailleurs, et vos e-mails aussi.
Les protections typiques à activer côté registrar, quand elles existent, sont :
un verrouillage “transfer lock” (bloquer les transferts de domaine), la désactivation du changement non autorisé des contacts (ou la vérification renforcée), l’authentification multifacteur (MFA) pour l’accès au compte, un mécanisme de validation pour les changements de DNS ou de nameservers.
Je recommande de traiter le registrar comme un poste de contrôle critique. Si votre domaine est “co-admin” à plusieurs personnes, documentez qui a le droit d’agir et comment vous vérifiez qu’un changement est bien attendu.
Petite réalité pratique: certains registrars affichent des options différentes selon la région, et les libellés changent. Le bon réflexe consiste à chercher les protections liées aux transferts et à l’authentification forte, pas à cocher au hasard.
DNS: comprendre les enregistrements qui comptent pour WordPress
Dans une zone DNS, vous trouverez plusieurs types d’enregistrements. Pour un site WordPress, les plus décisifs sont souvent :
A et AAAA: associent un nom à une adresse IPv4 ou IPv6. CNAME: associe un nom à un autre nom d’hôte. NS: indique quels serveurs DNS répondent pour la zone. TXT: stocke des informations diverses, notamment SPF, parfois des validations de domaines (selon les services). MX: route les e-mails entrants. Pour certains environnements, des enregistrements supplémentaires servent à la validation TLS ou à des services de sécurité.
La sécurité WordPress passe par une règle simple: vous devez savoir exactement ce que fait chaque enregistrement, et qui l’a modifié.
Le piège du “ça pointe vers l’hébergeur, donc c’est bon”
Ce raisonnement est dangereux. On croit que tant que “ça répond”, c’est correct. En réalité, un CNAME peut pointer vers un service mal configuré, un A peut pointer vers la mauvaise IP, et un wildcard peut introduire une résolution inattendue pour des sous-domaines.
Prenons un exemple banal. Vous changez d’hébergement. Vous créez un nouvel A pour www vers la nouvelle IP, puis vous oubliez @ (le domaine nu) ou le sous-domaine app utilisé par une intégration. Pendant la période de transition, certains visiteurs tombent sur l’ancienne version, d’autres sur la nouvelle. Ce mélange n’est pas seulement une question de performance, c’est aussi une question de sécurité opérationnelle: cache, cookies de session, règles de redirection, et certaines intégrations d’authentification peuvent réagir différemment.
TTL et propagation: la sécurité a une horloge
Quand vous modifiez des DNS, les caches (chez votre provider, chez des résolveurs intermédiaires, chez l’utilisateur) gardent souvent les anciennes réponses pendant un certain temps. Ce temps est lié au TTL (Time To Live). Un TTL plus court réduit la durée de propagation “visqueuse”. Un TTL plus long, lui, rend les changements plus lents, et donc plus risqués quand on ne maîtrise pas le plan de bascule.
Sur un site WordPress, je conseille généralement de penser en mode “fenêtre de changement” :
avant le changement, réduire temporairement le TTL sur les enregistrements clés, exécuter la bascule, vérifier la résolution depuis plusieurs points (pas seulement chez soi), garder un plan de retour si un détail casse.
Ce n’est pas glamour, mais c’est là que les incidents se transforment en simples ajustements.
DNSSEC: utile, mais pas magique
DNSSEC ajoute une couche de signature cryptographique des réponses DNS, ce qui aide à détecter certains types d’altération en transit. Concrètement, cela protège la chaîne de confiance DNS, dans le cas où un résolveur vérifie les signatures.
Mais DNSSEC n’est pas un anti-piratage universel. Si quelqu’un contrôle votre zone DNS ou votre compte registrar, il peut signer des réponses conformes à la zone telle qu’elle est administrée. DNSSEC aide surtout à empêcher la modification par un tiers sur la voie de distribution.
La décision d’activer DNSSEC dépend de votre stack et de votre expérience. Si vous le mettez en place, assurez-vous que :
vous contrôlez la clé et les mécanismes de rotation si votre provider le demande, vous comprenez les interactions avec votre infrastructure DNS, vous testez avant un changement majeur.
Si vous êtes déjà dans un environnement où plusieurs services consomment le domaine (mail, CDN, hébergeur, validation de certificats), une activation DNSSEC peut nécessiter de coordonner les validations.
TLS et redirections: la sécurité dépend du “bon nom” et du bon chemin
Un site WordPress sérieux utilise TLS, donc HTTPS. Les certificats reposent sur la capacité à prouver le contrôle du nom de domaine. La résolution DNS influence souvent les mécanismes de vérification (selon l’autorité de certification et la méthode choisie).
Le point de sécurité souvent sous-estimé est la cohérence entre le domaine et WordPress. WordPress peut forcer les redirections vers une URL “canonique”. Si vos DNS et vos redirections ne correspondent pas, vous risquez des comportements bizarres :
des boucles de redirection (http vers https, www vers non-www), des cookies envoyés vers un mauvais périmètre (selon le domaine), des intégrations OAuth ou API qui valident strictement les noms.
Une règle pratique: décidez rapidement quelle est la version canonique (par exemple https://example.com/ sans www, ou l’inverse), puis alignez DNS, certificats, et configuration WordPress (paramètres d’URL, et éventuellement configuration applicative).
E-mail et sécurité WordPress: SPF, DKIM, DMARC ne sont pas un détail
Même si votre question porte “domaines et DNS” pour WordPress, l’e-mail du même domaine fait partie du paysage. Les attaquants adorent les contextes où ils peuvent déclencher du spam, des reset de mot de passe, ou des communications d’apparence légitime.
SPF, DKIM, DMARC sont des politiques qui réduisent l’efficacité de l’usurpation.
SPF: indique quels serveurs ont le droit d’envoyer pour ce domaine. DKIM: signe les e-mails pour prouver l’intégrité et l’origine. DMARC: demande quoi faire si SPF ou DKIM échouent, et permet de recevoir des rapports.
Ce qui m’a le plus surpris, c’est la fréquence des configurations “héritées”. Par exemple, un domaine a changé d’hébergeur ou de service mail, mais les TXT SPF ou les enregistrements DKIM n’ont jamais été mis à jour. Résultat: des e-mails légitimes peuvent finir en quarantaine, et les utilisateurs cherchent des contournements (adresses alternatives, services tiers, etc.) Qui ouvrent d’autres risques.
Bon réflexe: quand vous changez le DNS pour WordPress, regardez aussi les enregistrements mail liés au même domaine, pas seulement ceux qui concernent www.
Mettre à jour des DNS en production: méthode et prudence
Modifier des DNS peut sembler trivial dans un panneau web, mais c’est rarement une opération “bouton unique”. Une bascule de domaine ou le passage à un nouveau fournisseur implique souvent plusieurs enregistrements à coordonner.
L’approche la plus efficace que j’ai adoptée consiste à préparer la bascule comme un mini-projet, même si elle ne dure qu’une heure.
Une check-list simple avant de toucher aux enregistrements
vérifier quelle est la version canonique (avec ou sans www) et l’aligner avec WordPress, identifier les enregistrements à modifier, et les dépendances (mail, sous-domaines, validations), prévoir un plan de retour (au moins l’ordre des actions pour revenir en arrière), réduire temporairement le TTL si vous devez minimiser l’impact, documenter qui fait le changement et à quelle heure.
Ça évite le classique “on a changé pour 10 minutes, et maintenant on ne sait plus revenir”.
Ordre des actions: ne pas casser la cohérence
Quand on change d’hébergement ou de CDN, la logique est souvent la suivante :
d’abord, préparer la destination côté hébergeur (que le site réponde correctement), ensuite, ajuster les enregistrements DNS, enfin, valider la résolution depuis plusieurs contextes.
Le risque, c’est l’étape “destination pas prête” suivie d’un DNS public. Cela arrive quand on fait une bascule trop tôt, ou quand on a des caches de configurations applicatives qui ne sont pas synchronisés.
Transfert de domaine et migration DNS: le moment où tout peut déraper
Un transfert de domaine est une opération à haut risque. Entre le moment où le registrar bascule et celui où tout devient stable, il y a parfois des périodes où la résolution est moins prévisible.
Ce que je considère comme “sécurité”, pendant une migration, c’est surtout la maîtrise de la séquence et la capacité à observer ce qui se passe.
Sur le terrain, les incidents de migration viennent souvent de :
des nameservers pas encore propagés au bon moment, une zone DNS qui existe mais qui ne correspond plus aux attentes, des fichiers de configuration partiellement importés.
Si vous migrez vers un nouveau provider DNS, vérifiez que les enregistrements critiques existent bien au même endroit (A, CNAME, TXT, MX). Les “oubliés” sont souvent les sous-domaines ou des services de validation.
Sécuriser l’accès aux DNS: permissions, API, et journalisation
Une zone DNS, dans un panneau, peut être modifiée par différents rôles. La meilleure protection n’est pas seulement technique, elle est organisationnelle.
Je m’attarde toujours sur trois points :
Principe du moindre privilège: seules les personnes qui doivent vraiment modifier les DNS doivent pouvoir le faire. Les autres ont un accès lecture. MFA partout: pas seulement pour WordPress, aussi pour le panneau DNS et le registrar. Journal des modifications: idéalement, vous pouvez voir qui a changé quoi, et quand.
Là encore, ce n’est pas une question théorique. J’ai déjà vu un changement DNS fait par un stagiaire, via un compte non MFA, avec une intention légitime. Le résultat a été un CNAME vers la mauvaise cible. La correction a été rapide parce que l’historique montrait exactement l’action.
Détection: savoir qu’un changement DNS a eu lieu (sans paniquer)
La difficulté, c’est que les DNS ne “crient” pas. Quand une modification arrive, elle peut être visible uniquement via des requêtes de résolution, et parfois avec des caches qui rendent l’observation confuse.
Vous pouvez mettre en place une routine de contrôle, sans vous transformer en opérateur système en permanence. L’objectif est d’attraper les changements inattendus assez tôt.
En pratique, je recommande d’inspecter régulièrement les enregistrements clés, et surtout après toute action liée à :
un changement d’hébergement, un ajout de sous-domaine, une migration de mail, une modification de certificats ou d’intégrations.
Si vous avez une équipe, demandez une règle simple: toute modification DNS se fait avec un message interne, une date, et un ticket. Même sans automatisation, cette discipline réduit énormément les surprises.
Scénarios concrets et erreurs classiques
“On a changé A et tout semblait bon”
Dans un cas réel, le domaine nu (@) était resté sur l’ancienne IP, tandis que www avait été basculé. Les utilisateurs qui arrivaient via un lien direct vers https://example.com/ ne voyaient pas la version attendue. Ce n’était pas une compromission, mais une divergence de comportement. C’est souvent suffisant pour déclencher une vague de plaintes, et surtout des comportements de session incohérents.
La correction a été de rendre la configuration canonique identique sur le domaine nu et sur www, puis d’ajuster les redirections.
“Le mail a cessé de livrer, mais personne n’a touché au mail”
Lors d’une migration DNS, on a remplacé l’ensemble des enregistrements d’une zone par un import incomplet. Résultat, les TXT liés à SPF et DKIM n’étaient plus valides, et DMARC finissait par rejeter. Les équipes ont mis des jours à comprendre que le problème n’était pas “chez le provider mail”, mais dans la zone DNS.
Leçon: traiter mail et web comme un tout cohérent, même si votre projet est “WordPress”.
“Délégation DNS pour un sous-domaine, mauvaise idée sans cadre”
La délégation, par exemple pour blog.example.com ou shop.example.com, peut être propre. Mais elle implique que le sous-domaine soit géré ailleurs avec ses propres règles. Si vous déléguez sans documenter, vous multipliez les surfaces.
Si vous le faites, assurez-vous que les équipes qui gèrent le sous-domaine ont aussi les mêmes exigences de sécurité (MFA, accès restreints, process de changement).
CDN, WAF, et DNS: articuler sans confondre
Beaucoup d’architectures ajoutent un CDN devant WordPress. Le CDN change souvent ce que vous mettez dans les DNS: CNAME vers le CDN, ou parfois redirection vers une IP associée au proxy.
Il faut garder en tête que CDN et WAF ajoutent de la protection, mais que la partie DNS reste déterminante. Un mauvais enregistrement peut :
contourner le CDN et exposer le serveur directement, envoyer le trafic vers une autre propriété CDN, créer des incohérences de certificat si le nom n’est pas correctement couvert.
Le meilleur réflexe est de regarder le comportement réel côté navigateur et aussi via la résolution. Si vous changez le DNS, attendez-vous à devoir vérifier plusieurs aspects, y compris la chaîne de certificats et la redirection.
Réflexe final: “DNS” n’est pas un paramètre, c’est une responsabilité
La sécurité WordPress passe par WordPress, mais aussi par la façon dont votre domaine pointe vers le monde. Quand DNS est propre, cohérent, documenté, et contrôlé, la surface d’attaque diminue. Quand DNS est “laissé pour plus tard”, c’est souvent le moment où un incident démarre, même si le code WordPress n’a pas bougé.
Si vous ne deviez retenir qu’un seul fil conducteur, ce serait celui-ci: traitez les DNS comme de la configuration système critique, avec des permissions strictes, des changements traçables, et un plan de retour. C’est ce qui transforme une opération délicate, migration, changement d’hébergeur ou mise en place d’un nouvel environnement, en tâche maîtrisée plutôt qu’en roulette.
Si vous souhaitez, donnez-moi votre architecture actuelle (registrar, provider DNS, hébergeur, CDN ou proxy éventuel, domaine nu avec ou sans www, et si vous avez du mail sur le même domaine). Je peux vous proposer une stratégie de bascule et une liste des enregistrements à vérifier, adaptée à votre cas, sans hypothèses inutiles.