Une connexion HTTPS bien configurée, ce n’est pas seulement un cadenas dans la barre d’adresse. C’est la base d’un durcissement WordPress crédible, parce que ça protège ce que les visiteurs échangent avec votre site: formulaires, comptes, identifiants, cookies de session, et même le chargement des ressources si vous appliquez une politique cohérente. Quand HTTPS est mal réglé, on voit vite des symptômes concrets: des redirections en boucle, des contenus qui restent en HTTP, des erreurs “certificat invalide”, et parfois une boutique ou un formulaire qui ne fonctionne plus après un changement de serveur.
Dans cet article, je vais détailler une approche pragmatique pour sécuriser la connexion HTTPS et le certificat SSL dans un contexte WordPress. Je parlerai des choix de certificats, de la chaîne de confiance, du forçage HTTPS, des redirections, et de ce qui se passe quand vous êtes derrière un reverse proxy ou un load balancer. L’objectif est simple: réduire la surface d’attaque tout en évitant les réglages “magiques” qui finissent par casser la partie visible et la partie technique.
Le rôle du HTTPS dans le durcissement WordPress
WordPress utilise des sessions et des cookies. Tant que vous restez en HTTP, ces éléments peuvent être exposés à des attaques de type interception ou altération pendant le transport. Même si WordPress chiffre certaines données applicatives, la couche transport reste déterminante.
Le TLS (la brique derrière HTTPS) apporte plusieurs garanties essentielles:
- Confidentialité et intégrité des échanges. Validation cryptographique du serveur via le certificat. Protection contre la plupart des attaques de type “homme du milieu” lorsque la chaîne de confiance est correcte.
Mais le durcissement ne s’arrête pas au certificat. Un site peut afficher un cadenas vert et pourtant garder des morceaux en HTTP, ou faire croire à WordPress qu’il est en HTTP alors que le navigateur est en HTTPS. C’est là que les problèmes se glissent, surtout dans les environnements avec proxy.
Choisir et obtenir un certificat SSL “qui tient dans la durée”
Pour un site WordPress, vous aurez souvent le choix entre des certificats fournis par votre hébergeur, des certificats gérés par votre infrastructure (par exemple via un reverse proxy), ou des certificats obtenus par une autorité de certification via un mécanisme automatisé.
Sur le papier, un certificat est un certificat. En pratique, ce qui compte, c’est:
1) La correspondance du nom de domaine (common name ou subject alternative names). 2) La chaîne complète (y compris les certificats intermédiaires). 3) La gestion du renouvellement. 4) Les contraintes d’environnement: multi-domaines, sous-domaines, IPv6, challenges ACME, etc.
Si vous travaillez en production, je recommande fortement d’avoir un renouvellement automatique testé avant d’en dépendre. Un certificat qui expire, c’est rarement un risque théorique: c’est le genre d’oubli qui transforme un incident planifié en incident réel.
Cas fréquent: http://www vers https://www, et le problème des variantes
Un site WordPress répond parfois à plusieurs variantes d’URL, par exemple:
- domaine.tld www.domaine.tld
Si votre certificat couvre un sous-ensemble de ces variantes, vous obtiendrez des avertissements navigateur selon l’entrée. Le durcissement consiste à aligner dès le départ: certificat couvrant les noms attendus, et redirections propres vers une seule variante canonique.
Je l’ai vu sur des migrations où le certificat allait bien pour domaine.tld, mais pas pour www.domaine.tld. Résultat: le crawl et certains utilisateurs passaient sur www, et WordPress ou le CDN servaient des ressources incohérentes. Le “cadenas” semblait présent sur une partie du trafic seulement, ce qui rend le diagnostic plus long.
Vérifier la chaîne de confiance et les erreurs courantes
Un certificat peut sembler “installé” tout en étant incomplet. La plupart des navigateurs peuvent tolérer certains détails, puis refuser sur d’autres appareils ou via des caches intermédiaires.
Quelques erreurs typiques à surveiller lors de la mise en place:
- “certificat non valide” pour un sous-domaine oublié. “chaîne de certificats incomplète” (souvent lié aux intermédiaires manquants). redirections vers une URL avec un certificat différent. contenu chargé en HTTP alors que la page est en HTTPS.
Il ne suffit pas de cliquer sur l’icône de sécurité une fois. Sur un WordPress, les pages peuvent charger des ressources depuis des domaines différents, et le comportement varie selon la route (connexion admin, pages e-commerce, médias, formulaires, etc.).
Un test simple en pratique: ouvrir la page en HTTPS, vérifier l’URL exacte dans la barre, puis charger une page de connexion et une page qui affiche des médias. Cherchez les demandes réseau qui partent encore en HTTP. Si elles existent, vous avez souvent un réglage WordPress ou un paramétrage serveur qui n’est pas aligné.
Forcer HTTPS: le bon endroit, le bon réglage
Le forçage HTTPS peut se faire à plusieurs niveaux: serveur web (Nginx, Apache), reverse proxy (Traefik, HAProxy), ou même via WordPress. Dans un contexte de durcissement, le plus robuste est généralement de forcer côté infrastructure, parce que WordPress n’est pas toujours atteint avant d’envoyer des redirections.
Cela dit, WordPress doit aussi être configuré pour générer les liens en HTTPS et pour gérer correctement les cookies de session. Sinon, vous aurez une redirection qui “fonctionne”, puis un retour qui casse la session, ou un mix de HTTP et HTTPS.
Réglages WordPress qui évitent les incohérences
WordPress stocke l’URL du site dans la base de données. Si votre URL “home” ou “siteurl” reste en HTTP, WordPress va générer des liens en HTTP, ou considérer certains environnements comme non sécurisés. Ce n’est pas forcément visible immédiatement, mais ça se manifeste par des redirections “bizarres” ou des ressources mal adressées.
Si vous utilisez un plugin de migration ou un outil https://gardewp.fr/securite-wordpress/ de configuration, il faut vérifier après mise en place. En production, j’évite de “toucher à tout” sans méthode. Un changement d’URL dans la base, combiné à des redirections serveur, peut déclencher des cycles difficiles à tracer.
Forcer via serveur web: un choix de méthode réaliste
Sans entrer dans un guide exhaustif pour chaque serveur, l’idée est la même: toute requête HTTP doit rediriger vers l’URL HTTPS correspondante, avec le bon hôte, le bon chemin, et sans perdre la query string si elle est utile.
Quand vous êtes derrière un reverse proxy, la difficulté change. Le serveur interne reçoit parfois déjà des requêtes en HTTP (au sens réseau interne), alors que le client était en HTTPS. C’est là que des headers comme X-Forwarded-Proto deviennent cruciaux. Si WordPress ou votre couche de redirection ne les interprète pas correctement, vous verrez des boucles ou des “cookies non sécurisés”.
Cookies, sessions et paramètres de sécurité à aligner
Le TLS chiffre le transport, mais la sécurité applicative dépend aussi de la façon dont WordPress marque les cookies.
Dans un durcissement HTTPS sérieux, vous voulez que les cookies d’authentification et de session soient marqués comme “Secure”, et idéalement “HttpOnly”. “Secure” garantit que les cookies ne seront envoyés que via HTTPS. “HttpOnly” limite l’accès côté JavaScript, ce qui réduit l’impact d’un XSS.
WordPress gère ces options, mais elles dépendent du contexte, notamment de la détection HTTPS. Si WordPress croit être en HTTP, vous pouvez vous retrouver avec des cookies qui ne sont pas marqués Secure, même si le navigateur visite en HTTPS.
C’est typiquement le cas quand:
- vous avez un reverse proxy qui termine TLS, et que WordPress ne sait pas lire correctement le proto côté client.
Dans ces situations, le durcissement consiste moins à “ajouter une option au hasard”, et plus à rendre la détection fiable partout: reverse proxy, en-têtes HTTP, configuration WordPress, et parfois paramètres additionnels dans le serveur.
HSTS: renforcer après validation, pas au premier coup
HTTP Strict Transport Security (HSTS) indique aux navigateurs que le domaine doit être contacté uniquement en HTTPS pendant une durée donnée. C’est un levier de durcissement utile, mais il faut l’activer avec prudence.
Le piège classique: vous activez HSTS trop tôt, puis vous découvrez un cas de redirection non couvert (par exemple une variante de domaine ou un sous-domaine). Pendant la durée du header, certains utilisateurs auront du mal à accéder au site, même si votre correctif est prêt.
Une approche prudente consiste à:
- vérifier d’abord que toutes les URL attendues redirigent bien vers HTTPS, tester avec plusieurs environnements (navigation standard, navigation privée, cache vidé, outils de test), puis activer HSTS avec une durée “raisonnable” au début, avant d’augmenter.
Je parle de “durée raisonnable” parce que le sujet n’est pas seulement technique, il est opérationnel. HSTS se propage, et vous ne voulez pas vous retrouver à gérer des comportements persistants alors que vous êtes encore en phase d’ajustement.
Mixed content: quand le cadenas cache des requêtes en HTTP
Le mixed content est l’une des raisons les plus sournoises de frustration après un passage en HTTPS. La page principale est en HTTPS, mais le navigateur bloque ou dégrade le chargement d’assets en HTTP. Certaines ressources peuvent rester chargées, d’autres être bloquées, et l’interface se comporte alors “à moitié”.
Dans un WordPress, cela apparaît souvent via:
- liens internes générés en HTTP, configurations d’un plugin ou d’un thème qui pointe vers des URL en HTTP, médias servis depuis une autre base d’URL, CDN qui conserve des préférences.
Le durcissement, ici, ce n’est pas seulement corriger un lien. Il faut comprendre pourquoi le lien a été généré dans le bon contexte. Une fois que vous avez réglé “home” et “siteurl” correctement, vérifiez aussi les options spécifiques à des plugins, notamment ceux qui gèrent des mises à jour, des formulaires, des images, ou des intégrations externes.
Une fois, j’ai vu une boutique WooCommerce qui fonctionnait parfaitement en HTTPS, sauf la page produit dans un sous-domaine. Le certificat était bon, la redirection aussi, mais un champ dans une table de configuration pointait vers http:// sur le sous-domaine. Le résultat: un script cassait l’UI, et le problème semblait aléatoire selon la page.
Redirections: éviter les boucles et garder des URL propres
Quand on passe en HTTPS, on veut en général:
- forcer l’usage de HTTPS, garder les chemins inchangés, préserver les paramètres nécessaires (query string), éviter d’empiler des redirections (HTTP vers HTTPS puis HTTPS vers une version avec ou sans www, etc.).
Les boucles de redirection sont souvent dues à une combinaison de:
- redirection serveur, redirection WordPress, et paramètres générés par le thème ou un plugin.
Pour diagnostiquer, je regarde d’abord le couple “entrée utilisateur -> sortie navigateur” sans supposer que “le premier redirect est le bon”. Les navigateurs affichent parfois des messages génériques, mais en inspectant la chaîne, on identifie vite la logique qui se répète.
Choisir une seule URL canonique
Si vous choisissez https://www.domaine.tld comme canonique, alors:
- toutes les autres variantes doivent aboutir à cette forme, y compris les liens internes, y compris les URL générées par des fonctionnalités (sitemaps, fil RSS, pages de login, redirections d’authentification).
Le durcissement consiste à traiter l’URL canonique comme un contrat. Tant que le site “accepte” plusieurs variantes de façon informelle, vous gardez une surface d’erreur: cookies partagés mais sur des hôtes différents, caches divergents, et redirections inconsistentes.
Reverse proxy et détection du HTTPS: le nœud du durcissement moderne
Dans les architectures actuelles, on termine souvent TLS sur un load balancer ou un reverse proxy, puis on transmet en HTTP vers WordPress. C’est pratique, parce que vous centralisez les certificats et le renouvellement.
Mais WordPress doit ensuite savoir que la requête originale venait de HTTPS. Sinon, il peut:
- marquer les cookies sans Secure, générer des URLs en HTTP, ou déclencher des redirections incorrectes.
Le mécanisme passe généralement par des headers standard du monde proxy, comme X-Forwarded-Proto. Le reverse proxy doit ajouter ces en-têtes, et votre configuration WordPress ou serveur doit faire confiance à ces en-têtes uniquement dans le contexte approprié.
Le point “sûreté” est important. Si vous faites confiance à des headers proxy venant directement du client, un attaquant peut falsifier X-Forwarded-Proto et provoquer des comportements indésirables. Donc, la bonne pratique est de confier la lecture de ces headers à l’infrastructure interne et de limiter les sources de confiance.
Je conseille souvent de valider deux choses: 1) que les headers sont bien ajoutés par le proxy, 2) et que WordPress ne lit pas ces headers de manière aveugle quand la requête ne passe pas par le proxy.
C’est exactement le genre de détail qui sépare “ça marche sur mon poste” de “c’est stable en production”.
Renforcer la config: réduire les risques au-delà du certificat
Un certificat SSL est la porte d’entrée. Pour durcir correctement un WordPress, il faut regarder ce qui se passe autour. Même si vous ne changez pas toute la posture de sécurité, une série de réglages cohérents rend l’ensemble plus robuste.
Par exemple, vous pouvez ajouter des headers de sécurité (Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, etc.). Le piège est de ne pas les appliquer à l’aveugle sur un WordPress avec beaucoup de scripts de plugins. Une mauvaise CSP casse vite l’interface, et le dépannage devient un goulet d’étranglement.
Pour rester pragmatique, je privilégie d’abord les protections directement liées à HTTPS et à la session, comme:
- s’assurer que les cookies sont cohérents en Secure, s’assurer que le site n’est pas accessible en HTTP, s’assurer que les redirections ne créent pas de cycles, puis, seulement après, élargir à d’autres headers si l’environnement le supporte.
Procédure de mise en place: un déroulé “sans surprise”
Je vous propose une méthode de travail qui marche bien en production, parce qu’elle réduit le risque d’avoir un incident de dernière minute.
1) Valider le certificat sur toutes les variantes attendues (domaine, www, sous-domaines si nécessaire) et vérifier la chaîne. 2) Mettre en place le forçage HTTPS côté serveur ou reverse proxy, en évitant les redirections multiples. 3) Ajuster WordPress pour générer les bons liens (home et siteurl), puis vérifier les pages sensibles: connexion, contenu dynamique, médias. 4) Vérifier l’absence de mixed content avec inspection des requêtes réseau. 5) Activer HSTS uniquement quand l’ensemble est stable et que les variantes de domaines sont correctement redirigées.
Je sais que c’est un peu plus long au départ. En revanche, vous évitez la situation classique: “ça marche pendant une heure, puis un plugin charge une ressource en HTTP, et c’est seulement visible chez certains visiteurs”.
Ce que vous devez tester après bascule HTTPS
Après la bascule, je recommande de tester selon des scénarios concrets plutôt que “ça s’affiche”. WordPress est vivant, il dépend de plugins et de thèmes, il y a souvent des formulaires et des pages spécifiques.
Voici les vérifications les plus utiles, sans faire un inventaire infini:
- Connexion admin, création de session, et vérification que la navigation ne déclenche pas de redirection. Affichage de pages publiques avec chargement des médias et scripts. Pages de formulaires, check des redirections après soumission. Vérification des URLs générées dans le code source, au moins sur quelques pages. Contrôle des erreurs navigateur, en particulier pour le mixed content.
Si vous voyez une redirection après login qui ne se termine pas, le problème est souvent une incohérence HTTP/HTTPS côté WordPress et cookies, pas le certificat lui-même.
Cas particuliers: multisite, sous-domaines, et CDN
WordPress multisite
En multisite, les choses se compliquent parce que vous avez des configurations par site. Si votre réseau contient des sous-domaines et que certains ne sont pas correctement couverts ou redirigés, vous pouvez avoir un comportement différent selon le sous-site.
Le durcissement ici consiste à aligner l’URL de base du réseau, à valider le certificat couvrant les sous-domaines, et à s’assurer que la détection HTTPS est uniforme pour tous les sites.
Sous-domaines et domaines additionnels
Un blog peut avoir un sous-domaine pour les images, ou un domaine dédié pour des endpoints (api, webhooks). Il est tentant de “laisser en l’état” certains endpoints. En durcissement, je conseille de considérer ces endpoints comme faisant partie du périmètre. S’ils restent en HTTP, vous gardez une brèche potentielle et vous risquez des blocages de navigateur si des scripts HTTPS tentent d’interroger des ressources HTTP.
CDN et caches
Avec un CDN, la redirection et le certificat se jouent parfois à deux endroits. Le CDN peut terminer TLS au lieu de votre serveur d’origine. Alors, votre origin server voit un trafic interne, et la cohérence des headers (proto, host) devient encore plus importante.
Une autre source d’incident: des caches qui persistent des redirections. Si vous testez en direct et que vous n’avez pas vidé le cache ou purgé correctement, vous pouvez conclure à tort que “la config est cassée”.
Quand quelque chose casse: méthodes de diagnostic utiles
En pratique, vous allez rencontrer un moment où HTTPS “ne se comporte pas”. Les erreurs typiques sont:
- boucles de redirection, cookies qui ne restent pas, erreurs “certificat” sur une seule variante, pages qui chargent partiellement.
Le diagnostic efficace est souvent celui qui isole la couche fautive. Je procède de la façon suivante:
- je confirme l’URL canonique dans le navigateur, je teste une page admin et une page publique, je vérifie côté serveur (ou proxy) quels headers proto sont envoyés, je regarde si WordPress génère des liens en HTTP dans le HTML rendu.
Si le problème se limite à une variante de domaine, c’est souvent une couverture de certificat ou une redirection canonique. Si c’est un problème de cookies et d’authentification, c’est presque toujours la détection HTTPS et la configuration des paramètres liés aux sessions.
Ajustements finaux: rendre la sécurité “opérationnelle”
Le durcissement est rarement un événement ponctuel, c’est un état à maintenir. Un certificat expire, un plugin change un paramètre, un thème ajoute un script, un DNS migre, un reverse proxy change de règles, un cache revient en arrière.
Pour rendre la sécurité opérationnelle, je favorise des réglages qui supportent la durée:
- renouvellement automatique vérifié, redirections simples et cohérentes, WordPress configuré pour générer les URLs dans le bon schéma, et tests récurrents sur quelques scénarios clés, plutôt qu’une vérification unique au moment du lancement.
Quand un site est maintenu par une petite équipe, la robustesse compte autant que la sécurité maximale sur le papier. Le but est d’éviter les “gros fixes” d’urgence tous les quelques mois.
Sécuriser la connexion HTTPS et le certificat SSL, c’est l’une des briques les plus rentables du durcissement WordPress. Le gain est double: protection immédiate du transport, et fondation solide pour les autres mesures. Si vous traitez HTTPS comme une chaîne cohérente, du certificat aux redirections, jusqu’à la détection côté WordPress, vous réduisez drastiquement les incidents et vous gardez un site qui reste accessible, même dans les environnements complexes.