mlab Academy
EN
Sécuriser son domaine

Les en-têtes de sécurité HTTP

HSTS, CSP, X-Frame-Options, attributs de cookies : ce que bloque chaque en-tête, ce que signifie son absence dans un scan, et une configuration de départ sûre.

1 Introduction

À chaque fois que votre site répond à un navigateur, il envoie la page et une série d'en-têtes : de courtes consignes que le visiteur ne voit jamais. Certaines sont de purs interrupteurs de sécurité. Elles disent au navigateur « ne me parle qu'en HTTPS », « n'exécute aucun script venu d'ailleurs » ou « ne laisse aucun autre site m'afficher dans un cadre ». Le navigateur sait déjà appliquer tout cela ; il attend juste que vous le demandiez.

Un en-tête manquant suffit rarement à pirater un site. En revanche, il retire un filet de sécurité : un seul bug ailleurs (un script injecté, un lien en http://, une page chargée dans le cadre d'un attaquant) devient alors une attaque qui fonctionne. C'est pour cela qu'un scan de domaine les liste : ils coûtent peu à ajouter et compliquent des familles entières d'attaques.

1 ligne

La plupart des en-têtes tiennent en une ligne dans le serveur web, le reverse proxy ou le CDN

1 an

max-age HSTS exigé pour entrer dans la liste de preload des navigateurs (31 536 000 s)

0

Protection restante dans X-XSS-Protection : les navigateurs l'ignorent, CSP l'a remplacé

2 Comment ça marche

Un scanner fait comme un navigateur : il demande votre page d'accueil et lit les en-têtes de la réponse. Voici une réponse bien configurée : 

HTTP/2 200
strict-transport-security: max-age=31536000; includeSubDomains
content-security-policy: default-src 'self'; frame-ancestors 'none'; object-src 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
set-cookie: session=...; Secure; HttpOnly; SameSite=Lax

Strict-Transport-Security (HSTS)

Après la première visite, le navigateur refuse le HTTP en clair pour votre domaine pendant max-age secondes. Un attaquant sur le Wi-Fi d'un café ne peut plus rétrograder la connexion pour lire ou modifier le trafic.

Content-Security-Policy (CSP)

Une liste blanche des origines autorisées pour les scripts, styles, images et cadres. Si un attaquant injecte un <script> (XSS), le navigateur refuse de l'exécuter. L'en-tête le plus puissant, et celui qui demande le plus de soin.

X-Frame-Options / frame-ancestors

Décide qui peut afficher vos pages dans un cadre. Sans lui, une page malveillante peut charger votre site de façon invisible et faire cliquer vos boutons à l'utilisateur (clickjacking). frame-ancestors dans la CSP est la forme moderne ; X-Frame-Options: DENY couvre encore les vieux navigateurs.

X-Content-Type-Options: nosniff

Empêche le navigateur de deviner le type d'un fichier. Sans lui, une « image » envoyée par un utilisateur et contenant du JavaScript peut être exécutée comme un script.

Referrer-Policy

Contrôle la part de l'URL courante envoyée aux autres sites quand un visiteur clique sur un lien. Évite que des jetons ou des chemins internes présents dans les URL fuitent vers des tiers.

Permissions-Policy

Coupe les fonctions du navigateur que votre site n'utilise pas (caméra, micro, localisation), pour qu'un script injecté ou un tiers intégré ne puisse pas les demander.

Attributs de cookies : Secure, HttpOnly, SameSite

Secure interdit le cookie en HTTP clair, HttpOnly le cache au JavaScript (une XSS ne peut plus voler la session), SameSite limite les requêtes intersites (CSRF). Tout cookie de session devrait porter les trois.

3 Analyse détaillée

Absent ou faible

Un scan remonte deux types de problèmes. Un en-tête absent se lit facilement. Un en-tête faible est présent, mais configuré de façon à ne presque rien protéger :

HSTS avec un max-age court

Un max-age de quelques minutes expire avant la visite suivante. Visez six mois à un an dès que le HTTPS fonctionne partout.

CSP avec 'unsafe-inline', 'unsafe-eval' ou *

Ces valeurs réautorisent exactement ce que la CSP doit bloquer : scripts inline, évaluation de chaînes, n'importe quelle origine. Une telle politique fait bien sur une checklist et arrête très peu de XSS. Sortez les scripts inline dans des fichiers, ou utilisez des nonces.

CSP uniquement en Report-Only

Content-Security-Policy-Report-Only signale les violations sans rien bloquer. Parfait pour tester, aucune protection en production.

Versions affichées

Server: nginx/1.18.0 ou X-Powered-By: PHP/7.4 indiquent à un attaquant quelles vulnérabilités connues essayer. Masquer la version ne corrige rien, mais rien ne justifie de l'afficher.

Une configuration de départ sûre (nginx)

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'none'; object-src 'none'" always;
server_tokens off;

Derrière un CDN (Cloudflare, Fastly, CloudFront), les mêmes en-têtes se règlent dans ses règles d'en-têtes de réponse, sans toucher à vos serveurs. Apache, Caddy et IIS ont des équivalents directs.

Déployer les deux en-têtes délicats

1

CSP : commencez en Report-Only, parcourez votre site en surveillant la console du navigateur, ajustez la liste blanche (analytics, polices, widgets de paiement), puis renommez l'en-tête en Content-Security-Policy.

2

HSTS : démarrez avec un max-age court (un jour), vérifiez que chaque sous-domaine répond en HTTPS avant d'ajouter includeSubDomains, puis augmentez. N'ajoutez preload qu'en étant sûr de vous : sortir de la liste prend des mois.

Vérifiez vos en-têtes sur mlab.sh

Un scan de domaine lit les en-têtes de sécurité et les attributs de cookies renvoyés par votre site, et signale ceux qui manquent ou sont trop faibles pour protéger.

Scanner votre domaine sur mlab.sh

4 Red Flags

Pas de HSTS sur un site avec connexion

N'importe qui sur le même réseau peut retirer le HTTPS à la première requête et capturer les identifiants. Pages de connexion, d'administration et de paiement d'abord.

Cookie de session sans HttpOnly ou Secure

Une seule XSS suffit à lire la session et à livrer le compte à l'attaquant, et une seule requête HTTP à la faire fuiter sur le réseau.

Une CSP qui autorise tout

script-src * 'unsafe-inline' 'unsafe-eval' n'a de CSP que le nom. Considérez-la comme absente.

Des pages encadrables par n'importe qui

Sans frame-ancestors ni X-Frame-Options, les pages de paramètres du compte ou de confirmation de paiement sont exposées au clickjacking.

Versions exactes dans les en-têtes

Un numéro de version périmé dans Server ou X-Powered-By est une invitation. Masquez-le, et surtout mettez le logiciel à jour.

Propulsé par mlab.sh

Modules connexes

SPF, DKIM et DMARC pour votre domaine

Empêcher un attaquant d'envoyer des emails en votre nom : le rôle de SPF, DKIM et DMARC, lire un résultat de scan et atteindre p=reject sans casse.

Prise de contrôle de sous-domaine et DNS orphelin

Comment un CNAME ou un NS oublié permet à n'importe qui de publier sur votre sous-domaine, et comment repérer et nettoyer ces entrées avant un attaquant.

Reconnaître un lien de phishing

Les techniques pour détecter les URLs frauduleuses qui imitent des sites légitimes.