Démystifier les en-têtes HTTP de sécurité

17/02/2022 · 23 mins de lecture · cybersecurite web http https entetes  ·
Partager sur:

Traductions

Sommaire

Dans cet article, je démystifie les en-têtes du protocole Hypertext Transfer Protocol (HTTP) relatifs à la sécurité. L’objectif est de vous fournir les clés pour comprendre ce que sont ces en-têtes, à quoi ils servent et comment les utiliser. Cet article est principalement destiné aux hébergeurs et développeurs de sites Web qui souhaitent améliorer la sécurité inhérante à leurs sites, mais aussi à tous les curieux désireux d’améliorer leurs connaissances dans le domaine de la sécurité du Web. Comme d’habitude, vous trouverez l’intégralité des sources utilisées à la fin de cet article.

Introduction

Le protocole HTTP est un protocole de communication réseau pourn permettre l’échange de données pour le Web, qui constitue l’ensemble des ressources disponibles et référencées sur Internet. C’est un protocole qu’on appelle “client-serveur”, c’est-à-dire qu’un élément appelé client (un navigateur Web ou une application mobile par exemple) initie des requêtes de communication vers un élément appelé serveur (un logiciel hébergeant des pages Web) qui envoie des réponses au client, le tout dans un format bien défini. Dans ces requêtes et ces réponses circulent des données ainsi que des méta-données stockées dans des en-têtes qui contiennent des informations permettant de structurer les échanges. Il existe des centaines d’en-têtes possibles et il y en a dédiés aux requêtes, d’autres dédiés aux réponses ou bien pour les 2. Pour donner exemple, il existe un en-tête appelé Cookie, qui n’est pas un petit gateau mais bien des données fournies par le serveur au client et utilisées alors comme une sorte de jeton pour authentifier un utilisateur, le traquer, etc. Les en-têtes contiennent soit directement une valeur ou bien des directives ou paramètres (pouvant être optionnels) qui permettent de définir leur caractéristiques avec des valeurs. Il faut également savoir que ces en-têtes sont parfois manipulés par des éléments sur le réseau situés sur le chemin de transfert entre le client et le serveur.
Certains de ces en-têtes permettent d’apporter des fonctions de sécurité et je vais m’intéresser ici aux en-têtes de sécurité retournées par le serveur dans ses réponses. Ils permettent d’élever le niveau de sécurité en atténuant les risques d’exploitation de certaines vulnérabilités Web.

Vérifier les en-têtes HTTP de sécurité d’un site

Partons à la découverte de ces fameux en-têtes… Vous pouvez utiliser cet outil pour tester un site Web. Un score entre F et A+ vous sera fourni pour le site Web testé avec les détails des valeurs des en-têtes de réponse.

https://thibautprobst.fr est classé A+... Mais comment obtenir son A+ ?

Vous pouvez aussi utiliser les outils de développements des navigateurs (ici l’exemple avec Google Chrome) qui sont d’ailleurs aujourd’hui plus efficaces pour ce genre d’analyse que les logiciels de captures de paquets, la plupart du trafic Web étant chiffré (bien qu’il soit possible de déchiffrer du trafic avec Wireshark).

HTTP Strict Transport Security

L’en-tête de réponse HTTP Strict Transport Security (HSTS) permet d’indiquer au client que le site Web n’est accessible qu’au moyen du protocole HTTPS et non HTTP. HTTPS correspond à l’utilisation du protocole de chiffrement Transport Layer Security (TLS) pour chiffrer les données du protocole HTTP. L’utilisation du protocole HTTPS contribue à la confidentialité des données (par le chiffrement) et à l’intégrité des données (par l’utilisation de certificats pour authentifier le serveur et parfois le client, et par l’utilisation de fonction de hachage pour vérifier la non-altération des données).
Il y a 2 directives officiellement possibles pour l’en-tête HSTS :

  • max-age (obligatoire) : la durée (en secondes) pendant laquelle le client doit considérer que le site Web n’est accessible qu’en HTTPS.
  • includeSubDomains (optionnel) : indique si HSTS s’applique aussi sur les sous-domaines du site Web.

Exemple de mise en œuvre :
strict-transport-security: max-age=31536000; includeSubDomains

Exemple d'utilisation de HSTS

X-Frame-Options

L’en-tête de réponse X-Frame-Options permet d’indiquer si le client est autorisé à afficher une page au sein d’un élément du langage HyperText Markup Language (HTML), qui permet de décrire le contenu des pages Web, utilisé dans la page Web courante fournie par le serveur. Un tel élément peut être de type iframe (cadre flottant pour intégrer une page HTML dans la page courante), object (ressource externe intégrée dans la page courante) ou applet (applet Java). Les éléments frame ou embed, parfois inclus, sont considérés obsolètes. X-Frame-Options permet d’éviter que le contenu de votre site Web soit utilisé par des objets HTML dans d’autres sites Web (notamment de manière transparente pour l’utilisateur si des iframe transparentes sont utilisées), ce qu’on appelle le détournement de clic ou clickjacking.
Il y a 2 valeurs possibles pour l’en-tête X-Frame-Options :

  • DENY : interdit l’affichage d’une page au sein d’un élément iframe, object ou applet.
  • SAMEORIGIN : autorise l’affichage d’une page au sein d’un élément iframe, object ou applet avec une origine (protocole, hôte et port) ou origin qui est la même que la page courante. L’application de cette autorisation reste libre au navigateur Web quant au niveau d’imbrication des élements HTML, lorsque plusieurs éléments sont imbriqués.

Exemple de mise en œuvre :
x-frame-options: SAMEORIGIN

Exemple d'utilisation de X-Frame-Options avec la valeur SAMEORIGIN

X-Content-Type-Options

L’en-tête de réponse X-Content-Type-Options permet d’éviter au client d’analyser le contenu d’un fichier envoyé au travers d’une réponse Web dans un but de déterminer son type, en surchargant (écrasant) le type de fichier initialement renvoyé par le serveur dans la réponse avec l’en-tête Content-Type (qui sert à spécifier le type Multipurpose Internet Mail Extensions ou MIME d’un fichier). Lorsqu’appliqué par les navigateurs, cela permet notamment de dispenser un site Web de recevoir des fichiers d’un type non autorisé. Il n’y a qu’une valeur possible pour l’en-tête X-Content-Type-Options :

  • nosniff : interdit l’analyse du type de fichier pour surcharger ce dernier.

Exemple de mise en œuvre :
x-content-type-options: nosniff

Exemple d'utilisation de X-Content-Type-Options

X-Permitted-Cross-Domain-Policies

L’en-tête de réponse X-Permitted-Cross-Domain-Policies permet de contrôler l’utilisation du contenu du site Web dans des applications Flash ou des documents PDF externes. Un fichier nommé crossdomain.xml situé à la racine du site Web et contenant les règles de contrôle peut être spécifié dans l’en-tête pour être utilisé par le client.
Il y a 5 valeurs possibles pour l’en-tête X-Frame-Options :

  • none : interdit tout utilisation du contenu.
  • master-only : seul le fichier de règles crossdomain.xml peut être utilisé.
  • by-content-type : seuls les fichiers de règles de type défini par l’en-tête Content-Type de valeur text/x-cross-domain-policy sont autorisés. Ceci est valable pour les protocoles HTTP et HTTPS seulement.
  • by-ftp-filename : seuls les fichiers de règles dont les noms sont crossdomain.xml sont autorisés. Ceci est valable pour le protocole File Transfer Protocol (FTP) seulement.
  • all : tous les fichiers de règles du domaine du site Web sont autorisés.

Exemple de mise en œuvre :
x-permitted-cross-domain-policies: none

Exemple d'utilisation de X-Permitted-Cross-Domain-Policies avec la valeur none

Content-Security-Policy

L’en-tête de réponse Content Security Policy (CSP) permet de définir un ensemble de règles pour limiter le risque d’attaque de type Cross Site Scripting (XSS), dans lequel un client exécute malgré lui des scripts malveillants (et pointant vers des domaines externes relatifs à l’attaquant) hébergés par le serveur et injectés par un attaquant. Avec CSP, le serveur peut indiquer au client les domaines vers lesquels on est autorisé à demander du contenu (via des scripts, images, etc.).
Il y a 16 directives officiellement possibles pour l’en-tête CSP:

  • base-uri : restreint les Uniform Ressource Locators (URL, l’adresse d’un site ou d’une page Web) de bases, c’est-à-dire l’URL de base à utiliser pour composer les URLs relatives dans un document. Si la directive est absente, c’est l’élément <base> de la page Web qui est utilisé. Si la valeur est absente, toutes les URLs sont autorisées.
  • child-src : indique les sources autorisées dans l’utilisation de contextes de navigation Web imbriqués (tel iframe). Si la directive est absente, le client doit utiliser la directive default-src.
  • connect-src : indique les sources autorisées dans l’utilisation d’interfaces de programmation d’applications ou Application Programming Interface (API, permettant de charger du contenu supplémentaire de manière dynamique et transparente) au sein d’une page Web. Si la directive est absente, le client doit utiliser la directive default-src.
  • font-src : indique les sources autorisées dans l’utilisation de polices de caractères. Si la directive est absente, le client doit utiliser la directive default-src.
  • media-src : indique les sources autorisées dans l’utilisation de médias (audio ou vidéo). Si la directive est absente, le client doit utiliser la directive default-src.
  • img-src : indique les sources autorisées dans l’utilisation d’images et de favicons. Si la directive est absente, le client doit utiliser la directive default-src.
  • frame-src : indique les sources autorisées dans l’utilisation d’éléments imbriquées tels iframe. Si la directive est absente, le client doit utiliser la directive default-src.
  • object-src : indique les sources autorisées dans l’utilisation d’éléments object ou applet. Si la directive est absente, le client doit utiliser la directive default-src.
  • script-src : indique les sources autorisées dans l’utilisation de code JavaScript. Si la directive est absente, le client doit utiliser la directive default-src.
  • style-src : indique les sources autorisées dans l’utilisation de feuilles de styles (permettant la mise en forme des pages Web). Si la directive est absente, le client doit utiliser la directive default-src.
  • default-src : indique la valeur par défaut à utiliser pour toutes les directives dont le nom termine par “-src” lorsqu’elles sont absentes.
  • frame-ancestors : indique les sources autorisées à afficher une page au sein d’éléments HTML utilisé dans la page Web courante fournie par le serveur : iframe, object ou applet. Cette directive est similaire à l’en-tête X-Frame-Options (par exemple, si la valeur none est utilisée, cela revient à utiliser la valeur DENY de X-Frame-Options) mais offre plus de granularité en pouvant spécifier des sources.
  • plugin-types : indique les types MIME de fichier autorisées à être chargé par des plugins (au travers d’éléments object, embed ou applet).
  • form-action : indique les sources autorisées comme cible lors de soumissions de formulaires Web.
  • sandbox : indique l’utilisation d’un bac à sable ou sandbox, c’est-à-dire contrôler l’exécution des pop-ups, plugins et scripts au travers de différentes valeurs possibles. Elle ajoute également une contrainte de même origine (voir plus bas sur les valeurs possibles).
  • report-uri (bientôt remplacée par report-to): indique l’adresse à utiliser par le client pour envoyer un rapport en cas de déclenchement des directives lors du traitement de réponses Web.

Les valeurs retrouvées en tant que sources dans ces directives sont :

  • ‘self’ : le domaine associé au site Web hébergeant la ressource.
  • ’<host-source>’ : l’adresse IP ou le nom de domaine (pouvant inclure le protocole et un numéro de port, ainsi que la valeur * pour indiquer toutes les valeurs possibles).
  • ’<scheme-source>’ : un protocole ou un format de données.
  • ‘unsafe-eval’ : l’utilisation de la fonction JavaScript eval() (fonction permettant d’évaluer une chaîne de caractères).
  • ‘unsafe-hashes’ : une empreinte (issue d’une fonction de hachage) d’un script JavaScript.
  • ‘unsafe-inline’ : l’utilisation de ressources embarquées tels des scripts.
  • ’none’ : aucune source.

Exemple de mise en œuvre :
Content-Security-Policy: default-src 'self'; frame-src 'self' '*.example.com' ; img-src * ; form-action sandbox allow-scripts

Exemple d'utilisation de CSP

X-XSS-Protection

L’en-tête de réponse X-XSS-Protection permet aussi de limiter le risque d’attaque XSS. Cet en-tête est redondant avec CSP et non supporté par la plupart des navigateurs Web récents mais peut rester utile pour protéger des clients avec des implémentations plus anciennes. Cet protection utilise les mécanismes de filtrage XSS de certains navigateurs Web comme celui d’Internet Explorer.
Il y a 4 valeurs possibles pour l’en-tête X-XSS-Protection :

  • 0 : pas de filtrage XSS.
  • 1 : filtrage XSS par suppression des éléments de la page Web considérées malveillantes.
  • 1; mode=block : filtrage XSS et blocage de l’affichage de la page Web.
  • 1; report=<reporting-uri> : filtrage XSS par suppression des éléments de la page Web considérées malveillantes et indique l’adresse à utiliser par le client pour envoyer un rapport en cas de déclenchement du filtrage XSS.

Exemple de mise en œuvre :
X-XSS-Protection: 1; mode=block

Exemple d'utilisation de X-XSS-Protection

Permissions-Policy

L’en-tête de réponse Permissions-Policy vient remplacer l’en-tête Feature-Policy et permet de contrôler les fonctionnalités avancées pouvant être utilisées dans un navigateur au sein d’une page Web et tous les éléments iframe en son sein. Les directives posssibles sont associées à des fonctionnalités du client, et les plus répandues pour l’en-tête Permissions-Policy sont :

  • accelerometer : contrôle de l’accéleromètre.
  • ambient-light-sensor : contrôle de la luminosité ambiante.
  • autoplay : contrôle du jeu automatique des médias.
  • battery : contrôle de la lecture du statut de la batterie.
  • camera : contrôle de l’utilisation de la caméra.
  • display-capture : contrôle de la prise de captures d’écran.
  • encrypted-media : contrôle de l’utilisation de l’API Encrypted Media Extensions (EME).
  • execution-while-not-rendered : contrôle de l’exécution de code dans des cadres invisibles.
  • execution-while-out-of-viewport : contrôle de l’exécution de code dans des cadres en dehors de la fenêtre visible.
  • fullscreen : contrôle de l’affichage du plein écran.
  • gamepad : contrôle des périphériques de manettes de jeu.
  • geolocation : contrôle de l’utilisation de la géolocalisation.
  • gyroscope : contrôle de l’utilisation du gyroscope (mesure de l’orientation et vitesse angulaire dans l’espace).
  • layout-animations : contrôle de l’affichage des animations de mises en page.
  • legacy-image-formats : contrôle de l’affichage des images aux formats anciens.
  • magnetometer : contrôle de l’utilisation du magnétomètre (mesure du champ électromagnétique).
  • microphone : contrôle de l’utilisation du microphone.
  • midi : contrôle de l’utilisation de l’API Musical Instrument Digital Interface (MIDI).
  • navigation-override : contrôle de la navigation spatiale (par exemple avec des touches de clavier).
  • oversized-images : contrôle de l’affichage des images de tailles importantes.
  • payment : contrôle de l’utilisation de l’API Payment Request pour la réalisation plus simple de paiements bancaires.
  • picture-in-picture : contrôle de la lecture de vidéos en mode Picture in Picture (avoir une petite fenêtre supplémentaire lisant une vidéo, en plus de la principale)
  • publickey-credentials-get : contrôle de la récupération d’identifiants stockés.
  • screen-wave-lock : contrôle du non-assombrissement ou extinction de l’écran.
  • speaker : contrôle de l’utilisation des hauts-parleurs.
  • sync-xhr : contrôle de l’utilisation de requêtes synchrones XMLHttpRequest (interface JavaScript pour lire des données d’une URL).
  • unoptimized-images : contrôle de l’affichage d’images non optimisées.
  • usb : contrôle de l’accès aux ports USB.
  • unsized-media : contrôle de la modification de la taille des médias après la mise en page initiale.
  • vibrate : contrôle des vibrations.
  • wake-lock : contrôle de la non mise en veille.
  • web-share : contrôle du partage vers des destination externes (par exemple des applications mobiles).
  • xr-spatial-tracking : contrôle de la visualisation 3D (pour la réalité virtuelle ou augmentée).

Les valeurs retrouvées en tant que sources dans ces directives sont :

  • ’*’ : autorisé dans tout le document et tous ses contextes de navigations imbriqués. C’est la valeur par défaut si la directive n’est pas utilisée.
  • ‘self’ : autorisé dans tout le document et ses contextes de navigations imbriqués de même origine.
  • ‘src’ : autorisé dans une iframe si le document chargé dans cette iframe est de la même origine que la valeur de l’attribut src de l’iframe.
  • ’none’ : interdit.
  • ’<origin>’ : autorisé pour une ou plusieurs origines (séparées par un caractère espace).

Exemple de mise en œuvre :
permissions-policy: accelerometer=(), camera=(), gamepad=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=(), vibrate=()

Exemple d'utilisation de Permissions Policy

Referrer-Policy

L’en-tête de réponse Referrer-Policy permet de contrôler l’utilisation, dans les requêtes, de l’en-tête Referer qui sert à indiquer depuis quel site la requête Web vers une autre page a été générée. Les valeurs de cet en-tête peuvent inclure protocole, hôte, port, chemin d’accès et paramètres de la requête. Protocole, hôte et port sont appelés origine ou origin. Ce contrôle de l’utilisation de l’en-tête Referer permet d’améliorer la confidentialité des données en limitant les informations transmises (notamment à travers le chemin d’accès et les paramètres de la requête) sur votre site Web dans cet en-tête.
Il y a 8 valeurs possibles pour l’en-tête Referrer-Policy :

  • no-referrer : utilisation interdite de l’en-tête Referer.
  • no-referrer-when-downgrade : utilisation autorisée de l’en-tête Referer seulement lorsque quand le niveau de sécurité du protocole reste le même (HTTP vers HTTP ou HTTPS vers HTTPS) ou s’améliore (de HTTP vers HTTPS). C’est le comportement par défaut si aucune valeur n’est fournie.
  • origin : utilisation autorisée avec seulement l’origine.
  • same-origin : utilisation autorisée seulement lorsque l’origine reste la même.
  • origin-when-cross-origin : utilisation autorisée lorsque l’origine reste la même, et autorisée avec seulement l’origine sinon.
  • strict-origin : utilisation interdite lorsque le niveau de sécurité du protocole se dégrade (HTTPS vers HTTP), et autorisée avec seulement l’origine sinon.
  • strict-origin-when-cross-origin : utilisation autorisée lorsque l’origine reste la même, autorisée avec seulement l’origine sinon et si le niveau de sécurité du protocole reste le même, et interdite sinon.
  • unsafe-url : utilisation autorisée.

Exemple de mise en œuvre :
Referrer-Policy: strict-origin-when-cross-origin

Exemple d'utilisation de Referrer-Policy avec la valeur strict-origin-when-cross-origin

Clear-Site-Data

L’en-tête de réponse Clear-Site-Data permet d’indiquer au client la nécessité de nettoyer cache, stockage et cookies avant de traiter la réponse reçue du serveur.
Il y a 5 valeurs possibles (pouvant être cumulées) pour l’en-tête Clear-Site-Data :

  • cache : indique la nécessité de vider le cache.
  • cookies : indique la nécessite d’effacer les cookies et les identifiants d’authentification associés à l’origine (incluant les sous-domaines) de l’URL de la réponse.
  • storage : indique la nécessite d’effacer tout stockage Web local ou Document Object Model (DOM) storage effectué par le client.
  • executionContexts : indique la nécessité de recharger tous les contextes de navigation du client (généralement des iframe, onglets ou fenêtres).
  • * : indique la nécessité de nettoyer tout type de données possibles.

Exemple de mise en œuvre :
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"

Exemple d'utilisation de Clear-Site-Data

Cache-Control

L’en-tête Cache-Control permet de gérer la politique de mise en cache dans les requêtes et dans les réponses. Nous nous intéressons ici aux réponses, car bien que la mise en cache soit intéressante pour améliorer les performances et réduire les coûts de transfert (en évitant de renvoyer des requêtes pour obtenir des données), le contrôle de la mise en cache permet de limiter le risque de stockage à risque d’informations. Il est à noter qu’en l’absence de mécanisme de contrôle de cache proposé, les navigateurs utilisent des heuristiques pour déterminer la politique de cache. La spécification du protocole HTTP préconise une durée de mise en cache égale à 10% du temps écoulé entre la date actuelle et la date de dernière modification de la ressource (obtenue grâce à l’en-tête Last-Modified).
Il y a 9 directives officiellement possibles pour l’en-tête Cache-Control des réponses :

  • public : la réponse peut être mise en cache par n’importe quel cache.
  • private : la réponse ne peut être mise en cache que par un cache non partagé (accessible que par un seul utilisateur).
  • no-cache : le client doit vérifier si les données obtenues ont changé sur le serveur avant d’utiliser un cache (le serveur peut alors indiquer avec l’en-tête ETag si la donnée n’a pas changé sans renvoyer toutes les données).
  • no-store : le client ne peut pas stocker les données issues de la réponse.
  • no-transform : le contenu de la réponse ne peut pas être modifié par des équipements (de type proxy par exemple) sur le chemin de la réponse.
  • must-revalidate : le client doit refaire une requête si les données sont expirées (en se référant à l’en-tête Expires).
  • proxy-revalidate : le client doit refaire une requête si les données sont expirées, mais cela ne s’applique pas aux caches non partagés.
  • max-age : le cache de la réponse est valable pour une durée donnée (en secondes), en comptant à partir de la date de la requête. Cette directive surcharge l’en-tête Expires.
  • s-maxage : pour les caches non partagés seulement, le cache de la réponse est valable pour une durée donnée (en secondes), en comptant à partir de la date de la requête. Cette directive surcharge l’en-tête Expires ou la directive max-age de l’en-tête Cache-Control.
  • cache-extension : pour permettre des extensions sur le contrôle de la mise en cache.

Exemple de mise en œuvre :
Cache-Control: public, max-age=86400

Exemple d'utilisation de Cache-Control

Server

L’en-tête de réponse Server permet d’indiquer des informations sur le système utilisé par le serveur Web. Il n’apporte pas de fonction de sécurité mais son utilisation pourrait au contraire divulguer des informations pouvant être utiles pour un attaquant dans le but d’exploiter des vulnérabilités sur le serveur Web. Il est donc recommandé de surcharger la valeur de cet en-tête avec une valeur arbitraire.

Exemple de mise en œuvre :
Server: null

Cross-Origin-Resource-Policy

L’en-tête de réponse Cross-Origin-Resource-Policy (CORP) permet de contrôler les requêtes provenant d’origines différentes de celle associée à une réponse de votre site Web. CORP permet de limiter le risque des attaques de type Cross-Site Script Inclusion (XSSI) où un script d’une destination malveillante d’origine différente est exécuté.
Il y a 3 valeurs possibles pour l’en-tête CORP :

  • same-site : autorise le chargement de ressources depuis le même domaine (ici le domaine est le nom de domaine enregistré, ce qui est moins précis que l’origine).
  • same-origin : autorise le chargement de ressources depuis la même origine (protocole, hôte et port).
  • cross-origin : autorise le chargement de ressources depuis n’importe quelle origine.

Exemple de mise en œuvre :
Cross-Origin-Resource-Policy: same-origin

Cross-Origin-Resource-Sharing

Cross-Origin-Resource-Sharing (CORS) est un mécanisme qui permet, grâce à plusieurs en-têtes de réponse, d’indiquer au client les origines autorisées (en plus de celle du site Web) pour le chargement de ses ressources, les méthodes HTTP et les en-têtes pouvant y être exposés, ainsi que l’utilisation d’informations d’authentication ou non. On peut également définir la durée de validité des requêtes préliminaires effectuées par le client avec la méthode HTTP OPTIONS pour obtenir les options de communication sur la ressource ciblée, en amont de requêtes pour l’échange de données.
Les en-têtes du mécanisme CORS sont :

  • Access-Control-Allow-Origin : indique les origines (peut inclure la valeur *) autorisées.
  • Access-Control-Expose-Headers : indique le ou les en-têtes pouvant être utilisés par le client.
  • Access-Control-Max-Age : indique la durée (en secondes) pendant laquelle le résultat de la requête préliminaire peut être mis en cache.
  • Access-Control-Allow-Credentials : indique si la requête principale peut ou non être effectuée avec des informations d’authentification.
  • Access-Control-Allow-Methods : indique la ou les méthodes autorisées pour accéder à la ressoure.
  • Access-Control-Allow-Headers : indique, dans une réponse à une requête préliminaire, les en-têtes HTTP pouvant être utilisés lorsque la requête principale est envoyée.

Exemple de mise en œuvre :
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
Access-Control-Max-Age: 600
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Headers:

Cross-Origin-Embedder-Policy

L’en-tête de réponse Cross-Origin-Embedder-Policy (COEP) permet de contrôler l’utilisation de ressources d’origines différentes dans une page Web. COEP bloque le chargement de ces ressources sauf si elles sont autorisées par des en-têtes relatifs à CORS ou CORP. Il faut donc vérifier que les sites Web de ces ressources externes utilisent ces mécanismes et autorise le chargement depuis des origines différentes.
Il y a 2 valeurs possibles pour l’en-tête COEP :

  • unsafe-corp : autorise le chargement de ressources d’origines différentes de celle du document de la réponse, sans besoin de déclarer une politique CORS ou CORP. C’est la valeur par défaut.
  • require-corp : autorise le chargement de ressources d’origines différentes seulement si autorisé via CORS ou CORP.

Exemple de mise en œuvre :
Cross-Origin-Embedder-Policy: require-corp

Exemples d'utilisation de CORP, CORS et COEP entre des origines différentes

Cross-Origin-Opener-Policy

L’en-tête de réponse Cross-Origin-Opener-Policy (COOP) permet de contrôler l’utilisation des contextes de navigation lors d’utilisation de ressources d’origines différentes. Cela permet de séparer les ressources de confiance des autres ressources d’un point de vue mémoire sur le client. On peut ainsi contribuer à se prémunier des attaques de type Spectre.
Il y a 3 valeurs possibles pour l’en-tête COOP :

  • unsafe-none : autorise le partage des contextes de navigation pour des ressources d’origines différentes sauf si les ressources d’origines différentes ont une politique COOP différente de unsafe-none. C’est la valeur par défaut si aucune valeur n’est configurée.
  • same-origin : indique un contexte de navigation dédié pour chaque origine différente.
  • same-origin-allow-popups : autorise le partage des contextes de navigation pour des ressources d’origines différentes où la politique COOP n’est pas présente ou a pour valeur unsafe-none.

Exemple de mise en œuvre :
Cross-Origin-Opener-Policy: same-origin

Exemple d'utilisation de COOP

Conclusion

Les en-têtes de réponses peuvent améliorer la sécurité de votre site Web s’ils sont utilisés correctement. Ils reposent aussi fortement sur une bonne implémentation au sein des navigateurs Web et sont en constante évolution. Restez donc informés sur les normes !
J’espère toutefois que cet article vous aura permis de démystifier ces en-têtes et vous aidera à les mettre en œuvre plus facilement. Si malgré tout vous êtes encore un peu perdu sur la bonne stratégie à adopter, voici un résumé de ce que je peux recommander :

  • Déployez votre site en HTTPS et non en HTTP et utilisez l’en-tête HSTS pour tous vos sous-domaines.
  • Utilisez l’en-tête X-Frame-Options pour contrôler l’affichage de vos pages dans des éléments embarqués : en autorisant seulement les mêmes origines ou en l’interdisant si les impacts d’un éventuel clickjacking de vos ressources est élevé.
  • Complétez le contrôle des accès aux ressources par les autres origines avec CORP, CORS, COEP et COOP mais soyez vigilant quant aux impacts sur l’utilisation de ressources externes par d’autres sites et vice-versa. Il est judicieux de tester COEP en mode Report Only pour évaluer les potentiels impact de son activation.
  • Gardez le contrôle sur les types de fichiers échangés en déployant l’en-tête X-Content-Type-Options.
  • Empêchez l’utilisation de votre contenu dans des applications Flash ou des documents PDF avec l’en-tête X-Permitted-Cross-Domain-Policies.
  • Restreignez les domaines vers lesquels vous autorisez le chargement de contenu externes dans vos pages avec l’en-tête CSP.
  • Activez le filtrage XSS de certains navigateurs avec l’en-tête X-XSS-Protection.
  • Réduisez au minimum l’utilisation de fonctionnalités avancés sur l’équipements des clients de votre site Web avec l’en-tête Permissions-Policy.
  • Limitez la propagation d’informations contenues dans les URLs de votre site en activant l’en-tête Referrer-Policy. Un bon compromis est d’autoriser ces propagations lorsque l’origine reste la même, de l’autoriser avec seulement l’origine sinon et si le niveau de sécurité du protocole reste le même, et de l’interdire dans les autres cas.
  • Utilisez les en-têtes Clear-Site-Data et Cache-Control si vous estimez que le stockage des données de votre site sur les navigateurs comporte un risque.
  • Enfin, modifiez la valeur de l’en-tête Server afin de ne pas divulguer d’informations évidentes sur le système qui héberge votre site Web.

Ne perdez pas de vue que la sécurité est un ensemble de mesures et que seule une bonne stratégie d’utilisation des en-têtes de réponse ne suffit pas. En effet, il est important de considérer les autres mécanismes de protection existant pour la sécurité du Web : du code robuste, une protection contre le déni de service, un Web Application Firewall, un Reverse Proxy…

Sources

Traductions