Quand un client me demande un audit de sécurité, il pense à des mots de passe, à des mises à jour, à un plugin douteux. Presque personne ne pense aux en-têtes HTTP. Ce sont quelques lignes de texte que votre serveur envoie avec chaque page, et qui disent au navigateur : « ne devine pas le type de ce fichier », « n’affiche pas ce site dans l’iframe d’un autre », « ne passe jamais par du HTTP non chiffré ». Peu coûteux à poser, ils ferment des familles entières d’attaques.
Je vous montre ceux qui comptent pour un site vitrine ou un petit site de services, les valeurs que j’utilise, et comment éviter de casser votre site en les activant.
Pourquoi les en-têtes comptent
Un navigateur est très tolérant par défaut. Il accepte qu’une page soit chargée dans un cadre invisible sur un site pirate (clickjacking), il peut interpréter un fichier texte comme du JavaScript, il suit un lien HTTP même si votre site est en HTTPS. Les en-têtes de sécurité retirent ces tolérances une par une.
Ils ne remplacent ni les mises à jour ni une bonne sauvegarde. Ils ajoutent une couche de défense. Pour le reste du tableau, mon article sur la sécurité web des sites professionnels donne les bases.
Les six en-têtes à poser en priorité
Les valeurs ci-dessous viennent de la fiche HTTP Headers de l’OWASP, la référence du secteur.
1. Strict-Transport-Security (HSTS)
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadIl force le navigateur à n’utiliser que HTTPS pour votre domaine, pendant la durée indiquée (ici deux ans). Même si un visiteur tape http://, le navigateur bascule tout seul en HTTPS sans passer par une requête non chiffrée.
Attention à includeSubDomains : tous vos sous-domaines doivent être servis en HTTPS, y compris www s’il existe. Un vieux intranet.mondomaine.fr resté en HTTP deviendrait inaccessible.
2. X-Content-Type-Options
X-Content-Type-Options: nosniffUne seule valeur possible, aucune raison de s’en passer. Le navigateur respecte le type de fichier annoncé par le serveur au lieu de le deviner. C’est l’en-tête le plus simple et le plus sûr de la liste.
3. Protection contre l’affichage en iframe
X-Frame-Options: DENYCet en-tête empêche d’intégrer votre site dans une page tierce, ce qui bloque le clickjacking (un faux bouton posé au-dessus de votre vrai formulaire). L’OWASP précise que la directive frame-ancestors de la CSP le remplace dans les navigateurs récents ; garder les deux est courant. Si vous devez vous-même intégrer vos pages (un outil interne par exemple), utilisez SAMEORIGIN plutôt que DENY.
4. Referrer-Policy
Referrer-Policy: strict-origin-when-cross-originQuand un visiteur clique sur un lien sortant, le navigateur peut transmettre l’adresse de la page d’origine. Avec cette valeur, seule l’origine (le domaine) part vers un site tiers, et rien du tout vers un site en HTTP. L’OWASP recommande de la définir explicitement plutôt que de compter sur le comportement par défaut du navigateur. Utile si vos URL contiennent des identifiants de suivi ou de dossier.
5. Permissions-Policy
Permissions-Policy: geolocation=(), camera=(), microphone=()Vous déclarez les fonctions du navigateur que votre site n’utilisera jamais. Si un script tiers compromis tente d’activer la caméra, le navigateur refuse. Désactivez ce dont vous n’avez pas besoin ; l’ancien nom Feature-Policy est abandonné.
6. Cross-Origin-Opener-Policy
Cross-Origin-Opener-Policy: same-originIl isole votre onglet des fenêtres ouvertes par d’autres sites. Peu de risque de casse sur un site vitrine, sauf si vous utilisez une fenêtre de paiement ou de connexion tierce qui communique avec votre page : testez-la.
La Content-Security-Policy : l’en-tête puissant (et piégeux)
La CSP liste les origines autorisées pour chaque type de ressource : scripts, styles, images, polices, formulaires. Un script injecté depuis un domaine non listé ne s’exécute pas. C’est la meilleure défense contre le XSS, et c’est aussi celle qui casse le plus de sites.
Un point de départ réaliste pour un site vitrine :
Content-Security-Policy: default-src 'self'; img-src 'self' data:; frame-ancestors 'self'; base-uri 'self'; form-action 'self'Chaque service tiers (statistiques, carte, vidéo, anti-spam) demande ensuite sa ligne : script-src, connect-src, frame-src. Ma méthode, dans l’ordre :
- Envoyer la politique en
Content-Security-Policy-Report-Only: le navigateur signale les violations sans rien bloquer. - Ouvrir chaque page type (accueil, contact, une page avec vidéo ou carte) avec la console du navigateur ouverte et relever les blocages.
- Ajouter uniquement les origines nécessaires, jamais
*. - Passer en mode bloquant quand la console reste propre.
Un conseil : évitez 'unsafe-inline' pour les scripts. Il annule l’essentiel de la protection. Si votre thème ou un plugin impose des scripts inline, c’est un argument pour changer de plugin.
Ce qu’il ne faut plus utiliser
Trois en-têtes traînent encore dans de vieux tutoriels, et l’OWASP les déconseille :
X-XSS-Protection: mettez0ou ne le définissez pas. La protection est abandonnée, la CSP la remplace.Expect-CT: à retirer du code existant.Public-Key-Pins(HPKP) : supprimé de Chromium en 2018, à retirer de la production.
Les scanners de sécurité gratuits qui notent votre site sur des critères obsolètes peuvent vous pousser à les ajouter. Ne le faites pas pour gagner une lettre.
Le piège du preload HSTS
Le mot preload dans l’en-tête HSTS vous permet de demander l’inscription de votre domaine dans la liste intégrée aux navigateurs. Les exigences, publiées sur hstspreload.org, sont strictes : max-age d’au moins un an, includeSubDomains, la directive preload, un certificat valide, une redirection HTTP vers HTTPS, et tous les sous-domaines en HTTPS.
Le même site prévient que l’inscription est difficile à annuler : le retrait peut prendre des mois à atteindre les utilisateurs. Mon avis : demandez le preload seulement quand le domaine est stable et que vous n’avez plus de service en HTTP nulle part. Pour un domaine qui héberge encore une vieille application, restez sur un HSTS simple sans preload.
Où poser les en-têtes
Selon votre hébergement, trois endroits possibles :
- Le serveur web (Nginx, Apache) : le plus fiable, il s’applique à tout, fichiers statiques compris.
- Le CDN ou le proxy : pratique si vous n’avez pas la main sur le serveur, à condition de vérifier que l’en-tête n’est pas doublé.
- L’application : un middleware dans le code du site. C’est ce que je fais sur les sites que je développe en Astro ou Laravel, avec une seule liste d’en-têtes versionnée dans le dépôt.
Si votre mutualisé ne permet aucun de ces réglages, c’est un signe de plus qu’il faut revoir l’hébergement.
Checklist d’actions
- Lister tous les domaines et sous-domaines, vérifier qu’ils répondent en HTTPS.
- Poser
nosniff,Referrer-Policy,Permissions-Policyet la protection anti-iframe : risque de casse très faible. - Poser le HSTS avec un
max-agecourt (une semaine) pour tester, puis l’allonger. - Écrire la CSP en mode rapport seul, corriger, puis la rendre bloquante.
- Retirer
X-XSS-Protection,Expect-CTetPublic-Key-Pinss’ils existent. - Vérifier le résultat avec les outils de développement du navigateur (onglet Réseau, réponse de la page) et après chaque changement de plugin ou de service tiers.
Comptez environ une heure pour les cinq premiers en-têtes, et une demi-journée pour une CSP propre sur un site avec plusieurs services externes.
Conclusion
Les en-têtes de sécurité ne se voient pas, ne rapportent pas de visiteurs et ne font pas de belles captures d’écran. C’est justement pour cela qu’ils sont oubliés, et qu’ils font la différence le jour où un script tiers est compromis ou qu’un lien malveillant vise votre formulaire.
Si vous voulez les faire poser et surveiller sans y consacrer votre temps, ils font partie de ce que je mets en place dans la maintenance de site et dans l’accompagnement DevOps et hébergement.
Sources :
