La sécurité d’un site WordPress ne se résume pas à “installer un plugin”. Quand on met en place une vraie protection, on finit presque toujours par revenir à deux fondations qui donnent le ton avant même d’atteindre le navigateur et la page d’accueil: la configuration du domaine et le système de noms, le DNS.
J’ai vu des sites pourtant bien “durcis” côté WordPress rester vulnérables parce que le DNS permettait un détournement facile, ou parce que les enregistrements n’étaient pas cohérents entre le registrar, le CDN et l’hébergement. À l’inverse, j’ai aussi vu des incidents se calmer parce que des alertes DNS et des choix de configuration avaient réduit la surface d’attaque, et surtout le temps de réaction.
Voici comment aborder la protection site WordPress en pensant domaine et DNS, avec des réglages concrets, des compromis réalistes, et les erreurs qui reviennent le plus.
Comprendre le rôle du DNS dans la sécurité
Le DNS sert à traduire un nom de domaine en adresses utilisables, comme des IP ou des cibles de services. Sur le plan de la sécurité, il joue deux rôles majeurs:
1) Il détermine où pointe votre site, vos services d’email, vos sous-domaines et parfois vos points d’entrée annexes. Si quelqu’un réussit à modifier une partie des enregistrements sans que vous le voyiez, il peut détourner le trafic vers une machine contrôlée par l’attaquant.
2) Il influence la fiabilité du trafic via la validation cryptographique. La validation DNSSEC limite fortement certaines formes d’usurpation, même si elle ne protège pas tout.
Un point important: le DNS n’est pas “juste” une annexe technique. C’est la carte d’orientation. WordPress peut être verrouillé, mais si l’adresse que les visiteurs suivent n’est pas celle que vous pensez, la serrure ne sert plus à grand-chose.
Sécuriser le registre et l’accès aux paramètres de domaine
Avant même de toucher aux enregistrements, il faut traiter l’accès au domaine comme une zone sensible. Le registrar et le compte DNS sont, dans la pratique, des cibles prioritaires.
Deux erreurs reviennent souvent. D’abord, laisser des mots de passe faibles ou réutilisés sur le compte du registrar. Ensuite, ne pas activer les protections d’accès, comme la double authentification, ou laisser des employés avoir des droits complets sans suivi.
Sans entrer dans des théories, l’impact est direct: une modification DNS malveillante commence presque toujours par un accès au panneau qui gère les enregistrements.
Concrètement, je conseille de:
- Activer la double authentification au niveau du registrar, et éviter les méthodes facilement contournables. Vérifier qui a accès au compte DNS. Les bons rôles sont limités: un administrateur du compte, et des comptes “lecture” pour l’observation, pas pour modifier. Mettre en place une procédure interne. Par exemple, toute modification DNS doit être validée par une seconde personne si vous travaillez en équipe.
Ces gestes semblent “administratifs”, mais ils font partie intégrante de la protection site WordPress, parce qu’ils empêchent la cause racine, la prise de contrôle du point de configuration.
Activer DNSSEC: utile, mais à condition d’être cohérent
DNSSEC est souvent présenté comme une panacée. En réalité, c’est surtout une brique qui renforce l’intégrité des réponses DNS. Si DNSSEC est correctement déployé, il devient beaucoup plus difficile de falsifier certains enregistrements en transit.
Le piège, c’est l’incohérence entre les zones et les délégations. On voit parfois des domaines où DNSSEC est activé au registrar, mais où les signatures ne correspondent pas, ou où la configuration du fournisseur DNS n’est pas prête à gérer la publication.
Mon conseil pragmatique: avant de l’activer en production, faites un test sur un domaine de préproduction si possible. Sinon, activez progressivement, gardez la capacité de rollback, et vérifiez la validation côté résolveurs. Les symptômes d’un déploiement raté sont parfois subtils, mais on les voit généralement dans des erreurs de résolution ou des retards de chargement.
Quand c’est bien fait, DNSSEC complète la sécurité de votre domaine. Quand c’est mal fait, vous créez au mieux de la complexité, au pire des interruptions.
Choisir une stratégie DNS pour le site WordPress
La majorité des sites WordPress pointent leur nom de domaine vers le serveur web via des enregistrements A (IPv4) ou AAAA (IPv6). Pour la sécurité, l’enjeu n’est pas seulement de “pointer correctement”, c’est d’éviter les zones ambiguës qui favorisent des erreurs humaines.
Les points à surveiller:
- La cohérence entre www et la racine. Par exemple, si vous utilisez www comme alias, assurez-vous que les deux points finissent sur la même cible et que la redirection ne dépend pas d’un compromis fragile. L’alignement avec le CDN ou le reverse proxy. Si vous utilisez un service de protection réseau, les enregistrements doivent refléter la réalité de votre chaîne de trafic. Les enregistrements laissés “par accident” à l’ancienne adresse IP, ou des records anciens utilisés par des sous-domaines oubliés.
Sur des systèmes simples, c’est facile. Sur des architectures avec sous-domaines, CDN, tunneling ou redirections complexes, c’est là que les oublis apparaissent.
Utiliser HTTPS correctement, et en profiter côté DNS
Le DNS ne “sécurise” pas HTTPS en lui-même, mais il conditionne ce que vos certificats couvrent et comment ils sont validés. Si vous changez de fournisseur ou de cible, un certificat peut rester bon, mais pas forcément pour la bonne combinaison racine, www, ou sous-domaines.
Si vous gérez des certificats via ACME, les validations HTTP-01 et DNS-01 dépendent directement du DNS. Dans ce contexte, un enregistrement DNS incorrect peut empêcher le renouvellement, ou forcer un mécanisme de validation moins robuste selon la configuration.
Un aspect souvent négligé: si votre domaine utilise des sous-domaines et que vous voulez garder une surface minimale, vous ne devez pas publier des records inutiles. Chaque sous-domaine actif peut devenir un point d’entrée, surtout s’il est lié à une application externe.
Enregistrements à vérifier pour réduire les surprises
Voici la première liste, courte et orientée vérification. L’idée n’est pas de tout modifier, mais de passer en revue ce qui existe et ce que cela implique réellement.
- A et AAAA pour la racine, et pour www si vous les utilisez distinctement. CNAME pour les sous-domaines (y compris ceux générés par un outil de monitoring ou par le CDN). TXT SPF et DKIM pour le routage email, si vous publiez des services d’expédition ou si vous utilisez un provider. Enregistrements pour la validation ACME (si vous utilisez DNS-01) ou pour la validation HTTP-01 (si vous dépendez d’un chemin web). CAA pour encadrer les autorités de certification autorisées (quand c’est compatible avec votre chaîne de délivrance).
Même si votre objectif principal est WordPress, email et certificats participent à la sécurité globale. Un site compromis n’est pas toujours “dégradé visuellement”, parfois il est surtout utilisé pour rebondir via phishing, ou pour envoyer des mails crédibles.
CAA: limiter qui peut délivrer un certificat
Les enregistrements CAA (Certification Authority Authorization) servent à déclarer quelles autorités de certification ont le droit de délivrer des certificats pour votre domaine. Le gain est assez concret: vous réduisez la probabilité qu’un certificat soit émis par une autorité inattendue.
Le compromis: selon votre fournisseur de certificats et votre processus d’automatisation, CAA peut nécessiter une coordination. Certains services utilisent des autorités spécifiques. Si vous ne listez pas correctement, le renouvellement peut échouer.
Dans un schéma “classique” avec un fournisseur bien connu et une gestion standard des certificats, CAA est généralement un plus. Dans des environnements plus exotiques, je préfère déployer CAA après avoir observé un cycle complet de renouvellement.
Contrôler les changements DNS et surveiller les alertes
La meilleure sécurité, ce n’est pas seulement empêcher. C’est aussi détecter rapidement. Les modifications DNS non autorisées peuvent arriver même si vous avez tout verrouillé, par exemple via un compte compromis, un employé parti de l’équipe, ou une confusion lors d’une migration.
Pour la surveillance, il y a plusieurs approches. Certains providers CDN ou DNS offrent des journaux et alertes, d’autres plugins ou services de monitoring s’appuient sur des requêtes externes.
L’important, c’est la cadence d’alerte. Si vous recevez un email une fois par semaine, vous ne voyez pas l’attaque au bon moment. Si vous recevez une alerte quasi immédiate, vous pouvez couper plus vite.
Je recommande aussi d’avoir une petite discipline: consigner les modifications DNS “légitimes” (date, raison, auteur). Lorsqu’une alerte tombe, vous pouvez trancher rapidement entre maintenance planifiée et incident.
Réduire la surface des sous-domaines
WordPress est souvent hébergé sur un sous-domaine ou utilise des sous-domaines pour des services annexes: téléchargement, images, API, ou pages marketing. Le problème n’est pas WordPress, c’est la multiplication des “points de résolution”.
Chaque sous-domaine peut être accessible publiquement, et chacun demande une stratégie de contrôle d’accès. Sur le plan DNS, le bon réflexe consiste à supprimer ce qui n’est plus utilisé, ou à le laisser sans cible active.
Si vous avez des sous-domaines créés pour des tests, puis oubliés, ils redeviennent parfois des vecteurs. J’ai déjà vu des “staging” résolus publiquement avec une config partielle, avec un accès limité côté application mais un enregistrement DNS encore actif, ce qui facilitait l’identification par un scanner.
Réduire la surface DNS est un travail de nettoyage, pas une opération ponctuelle. Lors d’une migration, faites l’inventaire. Lors d’un changement de provider, vérifiez les records hérités.
Email: SPF, DKIM, DMARC comme défense en profondeur
Même si vous parlez de protection site WordPress, l’email mérite un paragraphe à part. Les attaques qui ciblent un site WordPress finissent souvent par l’email, parce qu’il sert à la crédibilité et au rebond.
SPF évite que des serveurs non autorisés envoient des mails “au nom” de votre domaine. DKIM permet de signer le contenu. DMARC impose une politique et surtout permet d’observer ce qui se passe.
Sur le plan DNS, ces enregistrements sont critiques, et on les voit rarement dans les audits “web uniquement”. Pourtant, quand ils sont absents ou incohérents, vous pouvez être soit une victime de faux emails, soit un expéditeur dont la réputation se dégrade.
Le piège courant: copier-coller des enregistrements SPF sans comprendre qui envoie réellement. Entre un site qui envoie des notifications, un plugin d’email, un fournisseur de transactional email, et des outils marketing, il est facile d’oublier une source.
L’approche que je privilégie est simple, et elle se fait par observation. Regardez vos systèmes d’expédition réels, ajustez SPF et DKIM, puis utilisez DMARC avec une politique graduelle si nécessaire. Le but est d’arriver à un réglage solide, pas à une rupture brutale.
Relier la sécurité DNS à la posture WordPress
Une fois le domaine et le DNS maîtrisés, WordPress a moins de possibilités de subir un détournement de chemin. Mais il reste l’application: gestion des identifiants, mises à jour, durcissement du backend, limitations d’accès, sécurité du fichier wp-config.php, et contrôle des plugins.
Le point subtil: certains plugins de sécurité s’appuient sur des paramètres et des headers influencés par le reverse proxy et le CDN. Si votre DNS pointe vers un mauvais chemin, les en-têtes peuvent changer (exemple typique: la détection de l’IP client). Le résultat, ce sont des règles de filtrage qui bloquent trop, ou pas assez.
C’est pour ça que l’ajustement “DNS” et l’ajustement “WordPress” doivent se faire ensemble. Si vous changez le fournisseur DNS ou activez DNSSEC, vérifiez aussi le fonctionnement du site, et surtout le backend. Les pages d’administration sont le meilleur endroit pour voir immédiatement un problème de proxy.
Une procédure rapide en cas de suspicion de modification DNS
Malgré toutes les précautions, on peut être confronté à une alerte. Il faut alors éviter de faire n’importe quoi, par exemple modifier 15 paramètres à la fois, ce qui rend l’investigation impossible.
Voici la deuxième liste, orientée action, et volontairement courte.
- Vérifiez l’historique des changements côté registrar et côté fournisseur DNS, identifiez l’auteur et la date. Contrôlez que les records critiques (A/AAAA pour le site, CNAME vers le CDN, records d’email) correspondent à la configuration attendue. Mettez le site et l’administration en mode “calme” si nécessaire: réduire l’exposition, sans casser totalement l’accès légitime. Changez les accès (mots de passe et sessions) sur le registrar, puis sur le panneau DNS, avec double authentification. Activez une surveillance et documentez chaque changement, même si vous revenez en arrière.
L’objectif n’est pas seulement de “remettre le DNS à l’endroit”, c’est d’éviter la reprise après correction. Un incident DNS s’accompagne souvent d’un problème plus large, comme un compte compromis ou des droits trop larges.
Edge cases qui surprennent
Certaines situations reviennent, parce qu’elles combinent “bonne idée” et détail technique.
Un exemple fréquent: vous utilisez un CDN, vous remplacez les records, puis vous constatez que certaines URLs fonctionnent, d’autres non, parfois en fonction de la redirection. Cela vient souvent d’une différence entre www et la racine, ou d’une redirection gérée par l’hébergement au lieu du CDN. En sécurité, ces incohérences peuvent devenir un levier de confusion, surtout si des règles de firewall s’appliquent différemment selon l’host header.
Autre cas: l’IPv6. Beaucoup de configurations sécurisent l’IPv4 et oublient AAAA. Si AAAA pointe vers une cible inattendue ou ancienne, une partie du trafic peut contourner des règles que vous pensiez actives. Résultat: un comportement “bizarre” selon le réseau de l’utilisateur.
Dernier exemple: la délégation DNS. Si vous gérez la zone chez un fournisseur, mais que vous déléguez vers un autre, la chaîne doit être complète. DNSSEC est sensible aux délégations. Les certificats aussi. La plupart du temps, tout marche, mais au moindre changement, on doit revérifier.
Vérifier concrètement avant et après une modification DNS
Je sais que beaucoup de personnes font “un changement puis on regarde dans l’heure”. C’est utile, mais insuffisant si vous voulez éviter une panne silencieuse.
Une méthode raisonnable consiste à combiner navigation “réelle” et vérification technique:
- Tester la résolution DNS depuis plusieurs réseaux (mobile, bureau, autre pays si possible). Vérifier que le site charge correctement et que le backend WordPress répond comme prévu. Contrôler la délivrance et l’alignement des certificats si vous avez modifié les targets ou la validation. Surveiller l’email si vous avez changé SPF, DKIM ou DMARC.
Le bon sens n’est pas un luxe ici. Une erreur DNS n’est pas toujours visible immédiatement, parfois elle apparaît dans les logs seulement, ou elle touche une fraction d’utilisateurs.
Ce que je recommande comme “socle” minimal
Si vous devez prioriser, je le fais dans un ordre qui maximise l’impact et limite le risque.
D’abord, sécuriser l’accès au registrar et au DNS, avec double authentification et rôles adaptés. Ensuite, rendre la résolution simple et cohérente pour le domaine et www, et éliminer ce qui n’est pas utilisé. Ensuite seulement, ajouter les couches cryptographiques comme DNSSEC, et les contrôles de certificats comme CAA lorsque c’est compatible avec votre chaîne de renouvellement.
Enfin, compléter avec email (SPF, DKIM, DMARC) si votre domaine expédie, et mettre en place de la surveillance de changements. C’est le trio le plus efficace: empêcher, rendre cohérent, détecter.
Liens entre DNS, performance et sécurité
Un dernier point qui mérite d’être dit sans dramatiser: la sécurité DNS a aussi des implications de performance et de stabilité.
Quand vous ajoutez DNSSEC, vous introduisez parfois des étapes de validation côté résolveur. La plupart des résolveurs gèrent cela correctement, mais la latence et la résilience peuvent varier selon les réseaux. Dans une stratégie sérieuse, on mesure et on ajuste. Par exemple, si vous passez par un CDN, la latence perçue côté utilisateur est souvent dominée par le CDN, mais la résolution initiale reste un point à surveiller.
La https://gardewp.fr/securite-wordpress/ sécurité doit servir l’objectif final: un site WordPress disponible, fiable, et difficile à détourner.
Un audit “pratique” que vous pouvez lancer cette semaine
Si vous voulez transformer ces idées en travail concret, commencez par une revue rapide de ce qui existe déjà.
- Récupérez vos enregistrements DNS actuels et comparez-les à la configuration attendue (CDN, hébergement, email, certificats). Vérifiez que l’accès registrar et DNS est protégé, et que vous savez qui peut modifier quoi. Examinez les journaux de changement si votre fournisseur en fournit. Identifiez les sous-domaines inutiles, ceux qui pointent encore vers une ancienne cible, ou ceux qui servent à des tests.
Vous n’avez pas besoin de tout refaire en une journée. Mais il y a une différence entre “je n’ai rien à corriger” et “je n’ai jamais regardé”. La protection site WordPress commence souvent par ce simple constat, puis par une série de corrections modestes, mais bien ciblées.
Si vous souhaitez, dites-moi votre configuration actuelle (registrar, fournisseur DNS, présence ou non d’un CDN, et si vous gérez l’email depuis le domaine). Je pourrai vous proposer une lecture plus précise des risques typiques et des enregistrements à prioriser, sans toucher à ce qui marche déjà.