Sur WordPress, beaucoup d’attaques ne viennent pas d’un « hack spectaculaire », mais d’une surface trop large : scripts non contrôlés, intégration en iframe possible (clickjacking), ou navigation en HTTP encore tolérée quelque part. Les en-têtes de sécurité HTTP permettent de réduire ces risques côté navigateur, avec des gains rapides si la mise en place est cadrée et testée.
Cette démarche est pertinente pour une PME en Suisse romande, que vos visiteurs viennent de Montreux et Yverdon-les-Bains (Vaud), Vernier et Carouge (Genève), Bulle et Morat (Fribourg), Sierre et Monthey (Valais), Le Locle (Neuchâtel) ou Porrentruy (Jura).
Sources officielles : OWASP (HTTP Security Response Headers) · MDN (Content-Security-Policy) · MDN (Strict-Transport-Security) · Cloudflare (Response Header Transform Rules) · https.cio.gov (HSTS).
1) La liste courte des en-têtes utiles (et pourquoi)
- Content-Security-Policy (CSP) : limite les sources autorisées pour scripts, styles, images, connexions. Réduit notamment le risque XSS. (Commencer en mode Report-Only.)
- frame-ancestors (via CSP) ou X-Frame-Options : empêche ou contrôle l’intégration en iframe, défense principale contre le clickjacking.
- Strict-Transport-Security (HSTS) : force l’accès en HTTPS et empêche les retours involontaires en HTTP.
- Referrer-Policy : limite les fuites d’URL complètes vers des sites tiers.
- Permissions-Policy : restreint certaines API navigateur (selon votre besoin).
OWASP maintient une synthèse des en-têtes recommandés et de leurs configurations. La documentation MDN détaille chaque en-tête, son objectif et ses précautions.
2) CSP : la bonne méthode pour éviter de casser le site
La CSP est puissante, donc elle se déploie progressivement. MDN explique que l’en-tête Content-Security-Policy sert à contrôler les ressources qu’un navigateur est autorisé à charger pour une page donnée.
Étape A : démarrer en « Report-Only »
En phase initiale, utilisez Content-Security-Policy-Report-Only pour observer ce qui serait bloqué, sans bloquer. Ensuite, corrigez les sources nécessaires (analytics, reCAPTCHA, CDN, polices), puis basculez en CSP active.
Étape B : sécuriser d’abord les points sensibles
- Réduire les scripts inline quand c’est possible.
- Limiter
script-srcaux domaines réellement utilisés. - Encadrer
connect-srcsi des appels vers des APIs existent (analytics, services tiers).
MDN précise que la directive script-src régit les sources JavaScript valides et couvre aussi certains cas d’inline handlers.
3) Anti-clickjacking : frame-ancestors (préféré) ou X-Frame-Options
Le clickjacking dépend de la capacité à intégrer votre site dans un iframe. MDN indique deux outils de défense : la directive frame-ancestors dans une CSP, ou l’en-tête X-Frame-Options.
Recommandation simple :
- Si possible, utilisez CSP frame-ancestors.
- Sinon, utilisez X-Frame-Options: DENY (ou SAMEORIGIN si un cas métier justifie l’iframe interne).
4) HSTS : utile, mais à activer uniquement quand tout est déjà en HTTPS
MDN explique que Strict-Transport-Security informe le navigateur que le site doit être accessible uniquement en HTTPS et que les tentatives HTTP seront automatiquement « upgradées ».
Attention : HSTS ne se pose pas « pour voir ». https.cio.gov rappelle que HSTS vise à éviter la dépendance aux redirections HTTP vers HTTPS et renforce la protection des visiteurs. Activez-le quand le site est entièrement en HTTPS (y compris sous-domaines concernés) et que le certificat est propre.
5) Où configurer ces en-têtes : serveur, plugin, ou Cloudflare
Trois approches existent, à choisir selon votre stack :
- Serveur (Nginx/Apache) : méthode la plus directe et stable.
- Plugin : pratique, mais attention aux doublons et aux réglages masqués.
- Cloudflare : utile si vous passez par Cloudflare et voulez piloter des en-têtes au niveau du réseau.
Cloudflare documente ses Response Header Transform Rules, qui permettent de modifier les en-têtes des réponses HTTP envoyées aux visiteurs (ajout, suppression, remplacement).
Exemple d’en-têtes (à adapter, et à tester)
# Exemple générique (à adapter à votre serveur et vos besoins)
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
# CSP (commencer en Report-Only, puis activer)
Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' data: https:; script-src 'self' https:; style-src 'self' https: 'unsafe-inline'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Note : la CSP ci-dessus est volontairement générique. Sur WordPress, des scripts inline et des plugins peuvent nécessiter des ajustements. La méthode propre reste : Report-Only, analyse, puis resserrage progressif.
Checklist (30 minutes) avant de déployer en production
- Tester 2 pages clés : Accueil et Contact (et Checkout si WooCommerce).
- Vérifier les ressources tierces réellement utilisées (analytics, cartes, reCAPTCHA, polices).
- Déployer CSP en Report-Only d’abord, corriger, puis activer.
- Activer frame-ancestors ou X-Frame-Options et vérifier qu’aucune intégration légitime n’est cassée.
- Activer HSTS uniquement quand l’ensemble du site est en HTTPS stable.
FAQ En-têtes de sécurité WordPress (Suisse romande)
Quel est l’en-tête le plus utile pour éviter le clickjacking ?
Priorité à frame-ancestors via CSP. À défaut, X-Frame-Options est une protection classique.
Une CSP va-t-elle casser mon WordPress ?
Elle peut casser des scripts si elle est trop stricte d’emblée. La méthode recommandée est de démarrer en Report-Only, puis d’ajuster les sources nécessaires. MDN détaille l’objectif et l’usage de CSP.
Peut-on régler ces en-têtes via Cloudflare ?
Oui, via les Transform Rules de Cloudflare, qui permettent de manipuler les en-têtes de réponse envoyés aux visiteurs.
HSTS est-il risqué ?
HSTS est efficace, mais il doit être activé quand le site est entièrement en HTTPS et stable, car le navigateur mémorise la politique. MDN et https.cio.gov décrivent son rôle et son fonctionnement.
Besoin de sécuriser WordPress sans casser l’UX et la conversion ?
Pour définir un set d’en-têtes cohérent, déployer une CSP progressivement, configurer Cloudflare si nécessaire et valider sur mobile dans tous les cantons romands, contactez clickclick.ch.