Les en-têtes HTTP : rôle, en-têtes de sécurité

Des métadonnées, pas du contenu

Les chapitres précédents ont déjà croisé plusieurs en-têtes (Host, Content-Type, Content-Length) sans s’y arrêter. Un en-tête est une ligne Nom: valeur qui décrit l’échange, sans faire partie du contenu transporté : la langue préférée du visiteur, le type de contenu envoyé, des instructions de mise en cache, ou encore des règles de sécurité.

Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600
Accept-Language: fr-FR,fr;q=0.9

Trois en-têtes de sécurité courants

Certains en-têtes de réponse existent spécifiquement pour indiquer au navigateur comment se comporter de façon plus stricte face au contenu reçu :

• Content-Security-Policy (CSP) : liste les sources autorisées à fournir des scripts, styles ou images pour la page. Une politique stricte réduit fortement l’impact d’une éventuelle faille XSS, en empêchant l’exécution de scripts non explicitement autorisés.
• Strict-Transport-Security (HSTS) : indique au navigateur de toujours utiliser HTTPS pour ce domaine à l’avenir, même si l’utilisateur tape http:// par erreur.
• X-Content-Type-Options: nosniff : empêche le navigateur de deviner (« sniffer ») le type d’un fichier différemment de ce qu’indique Content-Type, ce qui bloque certaines techniques d’exécution de contenu déguisé.

Un en-tête n’est qu’une déclaration

Un point mérite d’être souligné : un en-tête de sécurité n’a de valeur que si sa configuration est réellement stricte. Une CSP qui autorise script-src * (n’importe quelle source) est présente mais ne protège de rien, exactement comme une porte blindée qu’on laisse ouverte. Vérifier la présence d’un en-tête de sécurité est un premier pas ; vérifier son contenu réel en est un second, tout aussi nécessaire.