En-têtes de sécurité HTTP : les protections invisibles que votre site devrait vérifier en 2026

Un site peut utiliser HTTPS et rester insuffisamment protégé côté navigateur. Entre le serveur et l’écran de l’utilisateur, les en-têtes HTTP transmettent des instructions qui limitent certains comportements risqués : chargement de scripts externes, intégration du site dans une iframe, interprétation incorrecte d’un fichier ou accès à des fonctions sensibles du navigateur. Ces protections sont discrètes, mais elles méritent une place dans l’audit technique d’un site WordPress, d’une application PHP ou d’un CRM métier.

À quoi servent les en-têtes de sécurité HTTP ?

Un en-tête de réponse est une information envoyée par le serveur avec la page. Certains en-têtes indiquent au navigateur ce qu’il doit autoriser ou refuser. Ils peuvent réduire l’impact d’attaques comme l’injection de script, le détournement de clic ou l’exploitation d’un contenu dont le type a été mal déclaré. L’OWASP les présente comme un renforcement utile de la sécurité, et non comme un remplacement d’un code correctement développé, mis à jour et contrôlé.

Les protections les plus utiles à vérifier

• Content-Security-Policy (CSP) définit les sources autorisées pour les scripts, styles, images, polices et autres ressources. Une politique bien construite limite notamment l’exploitation de certaines failles XSS. Elle doit toutefois être adaptée au site.
• Strict-Transport-Security (HSTS) demande au navigateur de revenir automatiquement en HTTPS lors des visites suivantes. Il doit être envoyé uniquement via HTTPS. L’option includeSubDomains ne doit être activée que si tous les sous-domaines concernés fonctionnent durablement en HTTPS.
• X-Content-Type-Options: nosniff empêche le navigateur de deviner un type de contenu différent de celui annoncé par le serveur. Cela réduit certains scénarios où un fichier est interprété comme du code exécutable.
• frame-ancestors, dans la CSP, contrôle les sites autorisés à intégrer une page. X-Frame-Options reste utile pour la compatibilité avec certains navigateurs plus anciens, mais frame-ancestors offre un contrôle plus moderne.
• Referrer-Policy limite les informations d’origine transmises lorsqu’un visiteur suit un lien. Permissions-Policy peut désactiver ou restreindre des fonctions comme la caméra, le microphone ou la géolocalisation lorsqu’elles ne sont pas nécessaires.

Pourquoi copier une configuration toute faite peut casser le site

Une CSP trop stricte peut bloquer un outil d’analytics, une carte, une vidéo, un paiement en ligne, un captcha ou un script ajouté par WordPress. À l’inverse, une politique remplie d’exceptions comme unsafe-inline perd une partie de son intérêt. La bonne méthode consiste à inventorier les ressources réellement utilisées, puis à tester d’abord une politique en mode Content-Security-Policy-Report-Only. Ce mode signale les violations sans bloquer immédiatement les éléments concernés.

HSTS demande également de la prudence. Une durée longue, includeSubDomains ou l’inscription sur une liste de préchargement peuvent rendre un sous-domaine inaccessible si son certificat ou sa configuration HTTPS ne sont pas prêts. Il faut commencer avec une durée limitée, vérifier l’ensemble du domaine, puis renforcer progressivement la règle.

Comment réaliser un contrôle concret

Le premier contrôle peut se faire dans l’onglet Réseau des outils de développement du navigateur ou avec une commande qui affiche les en-têtes HTTP. Il faut tester la page d’accueil, l’administration, les formulaires, l’espace client et, le cas échéant, le tunnel de paiement.

• Relever les en-têtes déjà présents et repérer les doublons ou contradictions.
• Inventorier les domaines externes chargés par le site.
• Préparer les règles sur une préproduction ou en mode rapport.
• Tester les formulaires, statistiques, cartes, vidéos, connexions et paiements.
• Déployer progressivement, puis surveiller les erreurs après mise en ligne.

Sur WordPress, une extension peut ajouter certains en-têtes, mais une configuration au niveau du serveur, du reverse proxy ou du CDN est souvent plus cohérente. Il faut surtout éviter que plusieurs couches envoient des règles différentes. Sur une application PHP sur mesure, les en-têtes doivent être intégrés à une configuration commune afin de couvrir toutes les réponses, y compris les pages d’erreur.

Un petit réglage qui exige une vraie méthode

Les en-têtes de sécurité ne rendent pas un site invulnérable. Ils ajoutent une défense utile autour du code, des mises à jour, des sauvegardes, du contrôle des accès et de la surveillance. Pour une PME à Nice, Cannes ou Monaco, l’objectif n’est pas d’empiler des règles techniques, mais de protéger les parcours qui comptent : prise de contact, réservation, paiement, accès client et outils internes.

Points à vérifier avant publication

Relire les recommandations OWASP et MDN au moment de publier, vérifier la compatibilité actuelle de Permissions-Policy et de CSP, confirmer que tous les sous-domaines supportent HTTPS avant d’activer HSTS avec includeSubDomains ou preload, et adapter chaque règle aux services externes réellement utilisés par le site.