Sec-Fetch - Aller chercher/demander/protéger une ressource Web HTTP - Content-Security-Policy - Cross-Origin - X-Frame - X-Content

NdM : 2021/09/04 - Cette page est en cours de complément rédactionnel..

J'écris cette documentation pour comprendre la norme de sécurité Sec-Fetch-* - "aller chercher/demander/protéger" une ressource Web.

Dans ce papier je vais d'écrire certaines fonctionnalités de sécurité pour site Web - Que cela (la ressource) soit inter-sites soit intra-site :)

Pour commencer je vais parler du header X-Frame-Options qui permet de bloquer les contenus de nos sites Web qu'un attaquant voudrait inclure à son site via une iframe par exemple en simulant que le contenu pourrait lui appartenir !

Puis je vais d'écrire les fonctionnalité récentes tel que CORS, les demandes et réponses d'origines croisées de partage de ressources pour différents type de format de documents transitant pour le web - js/css/html/json et d'autres.

X-Frame-Options :

L'en-tête de réponse HTTP X-Frame-Options peut être utilisé pour indiquer si un navigateur doit être autorisé ou non à afficher une page dans une frame, iframe, embed ou object. Les sites peuvent l'utiliser pour éviter les attaques de détournement de clic, en s'assurant que leur contenu n'est pas intégré à d'autres sites.

La sécurité supplémentaire n'est fournie que si l'utilisateur qui accède au document utilise un navigateur prenant en charge X-Frame-Options.

Directives :

• DENY : refuser
  La page ne peut pas être affichée dans un cadre, quel que soit le site qui tente de le faire.
• SAMEORIGIN : même origine
  La page ne peut être affichée que dans un cadre sur la même origine que la page elle-même. La spécification laisse aux fournisseurs de navigateurs le soin de décider si cette option s'applique au niveau supérieur, au parent ou à l'ensemble de la chaîne, bien qu'il soit soutenu que l'option n'est pas très utile à moins que tous les ancêtres soient également dans la même origine.
• ALLOW-FROM uri : seulement pour l'adresse (obsolète)
  Il s'agit d'une directive obsolète qui ne fonctionne plus dans les navigateurs modernes. Ne l'utilisez pas. En prenant en charge les navigateurs hérités, une page ne peut être affichée dans un cadre que sur l'uri d'origine spécifié. Notez que dans l'implémentation existante de Firefox, cela souffrait toujours du même problème que SAMEORIGIN - il ne vérifie pas les ancêtres des cadres pour voir s'ils sont dans la même origine. L'en-tête HTTP Content-Security-Policy a une directive frame-ancestors que vous pouvez utiliser à la place.

---

• MDN Web Docs : HTTP Header X-Frame-Options (EN)
• MDN Web Docs : HTTP Header X-Frame-Options (FR)

---

Les sites web peuvent utiliser les entêtes X-Frame-Options ou une stratégie de sécurité du contenu (CSP) pour contrôler si d'autres sites web peuvent les intégrer dans leurs propres pages. C'est une fonctionnalité de sécurité importante pour empêcher le détournement de clic (clickjacking) (attaque qui permet à des sites malveillants de duper les utilisateurs et utilisatrices pour les amener à cliquer sur les liens d'un site) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de malware.

Pour exemple en ajoutant un header('X-Frame-Options: deny'); en haut d'une page Web cela permet que personne ne puisse inclure votre site/page web via une iframe.

X-Content-Type-Options : les en-têtes Content-Type ne doivent pas être modifiés ou et suivis

L'entête X-Content-Type-Options est un marqueur utilisé par le serveur pour indiquer que les types MIME annoncés dans les en-têtes Content-Type ne doivent pas être modifiés ou et suivis. Cela permet de se détacher du sniffing de type MIME, ou, en d'autres termes, c'est une façon de dire que les webmasters savaient ce qu'ils faisaient.

Cet en-tête a été introduit par Microsoft dans IE 8 comme un moyen pour les webmasters de bloquer le reniflement de contenu qui se passait et pouvait transformer les types MIME non exécutables en types MIME exécutables. Depuis, d'autres navigateurs l'ont introduit, même si leurs algorithmes de reniflage MIME étaient moins agressifs.

A partir de Firefox 72, la désactivation du reniflement MIME est également appliqué aux documents de premier niveau si un Content-type est fourni. Les pages web HTML qui sont servies avec un type MIME différent de text/html, peuvent alors être juste téléchargées au lieu d'êtres rendues (interprétées et affichées par le navigateur). Assurez vous de valoriser correctement ces 2 en-têtes.

Les testeurs de sécurité du site s'attendent généralement à ce que cet en-tête soit défini.

Note: X-Content-Type-Options ne s'appliquent qu'au blocage des demandes par nosniff pour les destinations de demandes de "script" et "style". Il permet également le blocage en lecture croisé (CORB) pour les fichiers HTML, TXT, JSON, et XML (à l'exception des images SVG image/svg+xml).

Directives

• nosniff
  Bloque une requête si la destination de la requête est de type
  • "style" et le MIME n'est pas de type text/css, ou
  • "script" et le MIME n'est pas de type JavaScript MIME type
  
  Permet le blocage de la lecture croisée pour les types MIME
  • text/html
  • text/plain
  • text/json, application/json ou tout autre type avec une extension JSON : */*+json
  • text/xml, application/xml ou tout autre type avec une extension XML : */*+xml (hors image/svg+xml)

---

• MDN Web Docs : HTTP Header X-Content-Type-Options

Content-Security-Policy (CSP ) : Politique de sécurité de contenu

L'en-tête de réponse HTTP Content-Security-Policy permet aux administrateurs d'un site web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Bien qu'il y ait quelques exceptions, ces règles impliquent la plupart du temps de définir les origines du serveur et les points d'accès pour les scripts. Cet en-tête aide à se protéger contre les attaques de cross-site scripting (XSS (en-US) ).

Directives de récupération (fetch)

Les directives de récupération (ou fetch directives en anglais) contrôlent les emplacements à partir desquels certains types de ressource peuvent être chargés.

• child-src
  Définit les sources valides pour les web workers et les éléments qui représentent des contextes de navigation imbriqués tels que frame et iframe.

  Plutôt que la directive child-src, si vous souhaitez réguler les contextes de navigation imbriqués et les workers séparément, vous pouvez utiliser respectivement les directives frame-src et worker-src.

• connect-src
  Restreint les URL qui peuvent être chargées via des scripts.
• default-src
  Représente la valeur par défaut des directives de récupération qui ne sont pas définies explicitement.
  
  
• D'autres directives de récupération : font-src, frame-src, img-src, manifest-src, media-src, object-src, prefetch-src, script-src, script-src-elem, script-src-attr, style-src, style-src-elem, style-src-attr, worker-src

Directives de document

Les directives de document permettent de paramétrer les propriétés d'un document ou d'un environnement pour un web worker auquel une règle de sécurité s'applique.

• form-action
  Restreint les URL qui peuvent être utilisées comme cibles pour envoyer des formulaires depuis un contexte donné.
• frame-ancestors
  Définit les parent valides qui peuvent intégrer une page grâce aux éléments frame, iframe, object, embed, ou applet.
• navigate-to
  Restreint les URL vers lesquelles on peut naviguer depuis un document, quel que soit le moyen de navigation (un lien, un formulaire, window.location, window.open, etc.)

Directives de rapport

Les directives de rapport permettent de contrôler ce qui se passe lorsqu'une règle CSP est violée. Voir également l'en-tête Content-Security-Policy-Report-Only.

• report-uri
  Indique à l'agent utilisateur de rapporter les tentatives d'enfreintes du CSP. Un rapport d'enfreinte est un ensemble de documents JSON envoyés via une requête HTTP POST à l'URI indiquée.

  Bien que la directive report-to est prévue remplacer la directive report-uri maintenant dépréciée, report-to n'est pas encore supportée par la plupart des navigateurs modernes...

• report-to
  Déclenche un évènement SecurityPolicyViolationEvent.

Autres directives

Les directives de rapport permettent de contrôler ce qui se passe lorsqu'une règle CSP est violée. Voir également l'en-tête Content-Security-Policy-Report-Only.

• block-all-mixed-content
  Empêche le chargement de toute ressource via HTTP lorsque la page est chargée avec HTTPS.
• referrer
Referrer-Policy doit être utilisé à la place. Était utilisée pour indiquer l'en-tête référent (sic) pour les liens sortants.
• require-sri-for
  Oblige à utiliser le contrôle d'intégrité des sous-ressources (SRI ) pour les scripts ou les styles de la page.
• trusted-types
  Utilisée pour spécifier une liste de permissions de règles de Trusted Types . Les Trusted Types permettent à des applications de verrouiller les puits d'injection XSS dans le DOM pour n'accepter que des valeurs typées et non falsifiables plutôt que des chaines de caractères.
• upgrade-insecure-requests
  Indique à l'agent utilisateur de considérer toutes les URL non-sécurisées d'un site (celles servies via HTTP) comme si elles avaient été remplacées par des URL sécurisées. Cette directive est destinée aux sites web qui ont de nombreuses URL historiques non-sécurisées et qui doivent être réécrites.

---

Exemples :

Dans cet exemple, on désactive les scripts écrits à même le document (inline), les opérations eval() et les ressources (images, polices, scripts, etc.) peuvent uniquement être chargées via HTTPS :

Script avec 5 lignes

001// en-tête HTTP
002Content-Security-Policy: default-src https:
003
004// version avec la balise HTML meta
005<meta http-equiv="Content-Security-Policy" content="default-src https:">

Dans cet exemple, on ne met pas en place la règle de sécurité mais on récolte les enfreintes qui se seraient produites pour cette règle :

Script avec 1 ligne

001Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/

---

• MDN Web Docs : HTTP Header Content-Security-Policy
• WikipediA : Content Security Policy

---

Cross-Origin : Origine croisée

Les requêtes de n'importe quelle origine (à la fois sur le même site et entre sites) peuvent lire la ressource.

Cross-origin Resource Sharing (CORS ) : Partage des ressources entre origines multiples

Le cross-origin resource sharing (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP multi-origine (cross-origin) lorsqu'il demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante.

Quelles requêtes utilisent le CORS ?

Le standard CORS est utilisé afin de permettre les requêtes multi-origines pour :

• L'utilisation des API XMLHttpRequest ou Fetch
• Les polices web (pour récupérer des polices provenant d'autres origines lorsqu'on utilise @font-face en CSS), afin que les serveurs puissent déployer des polices TrueType uniquement chargées en cross-site et utilisées par les sites web qui l'autorisent .
• Les textures WebGL
• Les frames (images ou vidéo) dessinées sur un canevas avec drawImage
• Les feuilles de style (pour les accès CSSOM )
• Les scripts (pour les exceptions non silencieuses (unmuted exceptions)).

---

• Fetch Specification CORS
• MDN Web Docs : HTTP Cross-origin Resource Sharing (CORS) - Partage des ressources entre origines multiples

Cross-Origin-Read-Blocking (CORB) : Blocage de lecture d'origine croisée

Le blocage de lecture cross-origin, mieux connu sous le nom de CORB, est un algorithme qui identifie les récupérations de ressources cross-origin douteuses (par exemple, les récupérations qui échoueraient de toute façon comme les tentatives de rendu JSON dans un élément img) et les bloque avant qu'elles n'atteignent une page Web. CORB réduit le risque de fuite de données sensibles en les éloignant des pages Web d'origine croisée.

Cross-Origin-Resource-Policy (CORP) : Politique de ressources d'origine croisée

Cross-Origin Resource Policy est une stratégie définie par l'en-tête HTTP Cross-Origin-Resource-Policy qui permet aux sites Web et aux applications d'opter pour la protection contre certaines demandes provenant d'autres origines (telles que celles émises avec des éléments tels que script et img), pour atténuer les attaques spéculatives par canal latéral, comme Spectre, ainsi que les attaques par inclusion de scripts intersites.

CORP est une couche de protection supplémentaire au-delà de la politique de même origine par défaut. Cross-Origin Resource Policy complète le Cross-Origin Read Blocking (CORB), qui est un mécanisme pour empêcher certaines lectures cross-origin par défaut.

Directives :

• same-site : même-site
  Seules les requêtes du même Site peuvent lire la ressource.

  Attention : C'est moins sécurisé qu'une origine. L'algorithme pour vérifier si deux origines sont le même site est défini dans la norme HTML et consiste à vérifier le domaine enregistrable.

• same-origin : même origine
  Seules les requêtes de la même origine (c'est-à-dire schéma + hôte + port) peuvent lire la ressource.
• cross-origin : origine croisée
  Les requêtes de n'importe quelle origine (à la fois sur le même site et entre sites) peuvent lire la ressource.

---

• Fetch Specification CORB
• MDN Web Docs : HTTP Cross-Origin Resource Policy (CORP) (EN)
• MDN Web Docs : HTTP Header Cross-Origin-Resource-Policy (EN)

Cross-Origin-Opener-Policy (COOP) : Politique d'ouverture d'origine croisée

L'en-tête de réponse HTTP Cross-Origin-Opener-Policy (COOP) vous permet de vous assurer qu'un document de niveau supérieur ne partage pas un groupe de contexte de navigation avec des documents d'origine croisée.

COOP traitera et isolera votre document et les attaquants potentiels ne pourront pas accéder à votre objet global s'ils l'ouvraient dans une fenêtre contextuelle, empêchant ainsi un ensemble d'attaques d'origine croisée appelée XS-Leaks.

Si un document d'origine croisée avec COOP est ouvert dans une nouvelle fenêtre, le document d'ouverture n'y fera pas référence et la propriété window.opener de la nouvelle fenêtre sera nulle. Cela vous permet d'avoir plus de contrôle sur les références à une fenêtre que rel=noopener, ce qui n'affecte que les navigations sortantes.

Directives :

• unsafe-none : dangereux-aucun
  Ceci est la valeur par défault. Permet au document d'être ajouté au groupe de contexte de navigation de son ouvreur, à moins que l'ouvreur lui-même n'ait un COOP de même origine ou de même origine-autoriser-les-popups.
• same-origin-allow-popups : même-origine-autoriser-popups
  Conserve les références aux fenêtres ou aux onglets nouvellement ouverts qui ne définissent pas COOP ou qui refusent l'isolement en définissant une COOP sur unsafe-none.
• same-origin : même-origine
  Isole le contexte de navigation exclusivement aux documents de même origine. Les documents cross-origin ne sont pas chargés dans le même contexte de navigation.

Exemples :

Certaines fonctionnalités dépendent de l'isolement des origines croisées

Certaines fonctionnalités telles que les objets SharedArrayBuffer ou Performance.now() avec des minuteries non étranglées ne sont disponibles que si votre document a un en-tête COOP avec la valeur de même origine définie.

Script avec 2 lignes

001Cross-Origin-Opener-Policy: same-origin
002Cross-Origin-Embedder-Policy: require-corp

Voir aussi l'en-tête Cross-Origin-Embedder-Policy que vous devrez également définir.
Pour vérifier si l'isolation d'origine croisée a réussi, vous pouvez tester la propriété crossOriginIsolated disponible pour les contextes de fenêtre et de travail :

Script avec 5 lignes

001if (crossOriginIsolated) {
002  // Post SharedArrayBuffer
003} else {
004  // Do something else
005}

---

• MDN Web Docs : HTTP Header Cross-Origin-Opener-Policy (EN)

Cross-Origin-Embedder-Policy (COEP) : Politique d'intégration d'origine croisée

L'en-tête de réponse HTTP Cross-Origin-Embedder-Policy (COEP) empêche un document de charger des ressources d'origine croisée qui n'accordent pas explicitement l'autorisation de document (à l'aide de CORP ou CORS).

Directives :

• unsafe-none : dangereux-aucun
  Ceci est la valeur par défault. Permet au document de récupérer des ressources d'origine croisée sans donner d'autorisation explicite via le protocole CORS ou l'en-tête Cross-Origin-Resource-Policy.
• require-corp : exiger-corp
  Un document ne peut charger que des ressources de la même origine, ou des ressources explicitement marquées comme chargeables à partir d'une autre origine.
  Si une ressource d'origine croisée prend en charge CORS, l'attribut crossorigin ou l'en-tête Cross-Origin-Resource-Policy doit être utilisé pour la charger sans être bloqué par COEP.

Exemples :

Certaines fonctionnalités dépendent de l'isolement des origines croisées

Vous ne pouvez accéder à certaines fonctionnalités telles que les objets SharedArrayBuffer ou Performance.now() avec des minuteries non étranglées, si votre document a un en-tête COEP avec la valeur require-corp définie.

Script avec 2 lignes

001Cross-Origin-Embedder-Policy: require-corp
002Cross-Origin-Opener-Policy: same-origin

Voir aussi l'en-tête Cross-Origin-Opener-Policy que vous devrez également définir.
Pour vérifier si l'isolation d'origine croisée a réussi, vous pouvez tester la propriété crossOriginIsolated disponible pour les contextes de fenêtre et de travail :

Script avec 5 lignes

001if (crossOriginIsolated) {
002  // Post SharedArrayBuffer
003} else {
004  // Do something else
005}

Éviter le blocage COEP avec CORS
Si vous activez COEP à l'aide de require-corp et qu'une ressource d'origine croisée doit être chargée, elle doit prendre en charge CORS et vous devez explicitement marquer la ressource comme chargeable à partir d'une autre origine pour éviter le blocage de COEP. Par exemple, vous pouvez utiliser l'attribut crossorigin pour cette image à partir d'un site tiers :

Script avec 1 ligne

001<img src="https://thirdparty.com/img.png" crossorigin>

---

• MDN Web Docs : HTTP Header Cross-Origin-Embedder-Policy (EN)

---

Same-origin policy : Politique de même origine

La politique de même origine est un mécanisme de sécurité critique qui restreint la manière dont un document ou un script chargé par une origine peut interagir avec une ressource d'une autre origine.

Il aide à isoler les documents potentiellement malveillants, réduisant ainsi les vecteurs d'attaque possibles. Par exemple, il empêche un site Web malveillant sur Internet d'exécuter JS dans un navigateur pour lire les données d'un service de messagerie Web tiers (auquel l'utilisateur est connecté) ou d'un intranet d'entreprise (qui est protégé contre l'accès direct par l'attaquant par n'ayant pas d'adresse IP publique) et relayant ces données à l'attaquant.

---

• MDN Web Docs : Security Same-origin_policy

---

Fetch : aller chercher/demander/protéger une ressource Web

La norme Fetch définit les requêtes, les réponses et le processus qui les lie : la récupération.

---

• Fetch Specification - Lien officiel : Dernière mise à jour 19 juillet 2021
• Fetch Specification - Lien officiel (traduction automatique FRançaise)

Sec-Fetch-*

Présentation des métadonnées Fetch : firefox 90 supports fetch metadata request headers .

Comme illustré dans le scénario d'attaque ci-dessus, l'en-tête de demande HTTP Sec-Fetch-Site permet au serveur d'applications Web de faire la distinction entre une demande de même origine provenant de l'application Web correspondante et une demande d'origine croisée provenant d'un site Web contrôlé par un attaquant.

L'inspection des en-têtes Sec-Fetch-* permet finalement au serveur d'applications Web de rejeter ou d'ignorer également les demandes malveillantes en raison du contexte supplémentaire fourni par la famille d'en-têtes Sec-Fetch-*. Au total, il existe quatre en-têtes Sec-Fetch-* différents : Dest, Mode, Site et User qui, ensemble, permettent aux applications Web de se protéger et de protéger leurs utilisateurs finaux contre les attaques intersites mentionnées précédemment.

Aller de l'avant

Alors que Firefox sera bientôt livré avec sa nouvelle architecture de sécurité d'isolation de site qui résoudra quelques-uns des problèmes ci-dessus, nous recommandons que les applications Web utilisent les en-têtes Fetch Metadata nouvellement pris en charge qui fournissent un mécanisme de défense en profondeur pour les applications de toutes sortes.

Sec-Fetch-Dest : indique la destination de la demande

L'en-tête de demande de métadonnées d'extraction Sec-Fetch-Dest indique la destination de la demande. C'est l'initiateur de la demande d'extraction d'origine, c'est-à-dire où (et comment) les données extraites seront utilisées.

Cela permet aux serveurs de déterminer s'il faut traiter une demande en fonction de son adéquation avec la manière dont elle est censée être utilisée. Par exemple, une demande avec une destination audio doit demander des données audio, pas un autre type de ressource (par exemple, un document qui inclut des informations utilisateur sensibles).

Script avec 21 lignes

001Sec-Fetch-Dest: audio
002Sec-Fetch-Dest: audioworklet
003Sec-Fetch-Dest: document
004Sec-Fetch-Dest: embed
005Sec-Fetch-Dest: empty
006Sec-Fetch-Dest: font
007Sec-Fetch-Dest: frame
008Sec-Fetch-Dest: iframe
009Sec-Fetch-Dest: image
010Sec-Fetch-Dest: manifest
011Sec-Fetch-Dest: object
012Sec-Fetch-Dest: paintworklet
013Sec-Fetch-Dest: report
014Sec-Fetch-Dest: script
015Sec-Fetch-Dest: serviceworker
016Sec-Fetch-Dest: sharedworker
017Sec-Fetch-Dest: style
018Sec-Fetch-Dest: track
019Sec-Fetch-Dest: video
020Sec-Fetch-Dest: worker
021Sec-Fetch-Dest: xslt

Directives

Ces directives correspondent aux valeurs retournées par Request.destination.

Exemples

Une requête intersites générée par un élément img entraînerait une requête avec les en-têtes de requête HTTP suivants (notez que la destination est une image) :

Script avec 3 lignes

001Sec-Fetch-Dest: image
002Sec-Fetch-Mode: no-cors
003Sec-Fetch-Site: cross-site

---

• MDN Web Docs : HTTP Headers Sec-Fetch-Site (EN)

Sec-Fetch-Mode : Ces directives correspondent aux valeurs de Request.mode.

L'en-tête de demande de métadonnées d'extraction Sec-Fetch-Mode indique le mode de la demande.

De manière générale, cela permet à un serveur de faire la distinction entre : les requêtes provenant d'un utilisateur naviguant entre les pages HTML, et les requêtes de chargement d'images et d'autres ressources. Par exemple, cet en-tête contiendrait naviguer pour les requêtes de navigation de niveau supérieur, tandis que no-cors est utilisé pour charger une image.

Directives

• cors : cross-origin resource sharing - origine croisée de partage de ressources (partage de ressources inter-origine)
  La requête est une requête de protocole CORS.
• navigate : naviguation
  La requête est initiée par la navigation entre les documents HTML.
• no-cors : pas d'origine croisée de partage de ressources
  La requête est une requête no-cors (voir Request.mode ).
• same-origin : même origine
  La demande est faite à partir de la même origine que la ressource demandée.
• websocket :
  La demande est faite pour établir une connexion WebSocket.

Exemples

Si un utilisateur clique sur un lien de page vers une autre page sur la même origine, la requête résultante aurait les en-têtes suivants (notez que le mode est navigation) :

Script avec 3 lignes

001Sec-Fetch-Dest : document
002Sec-Fetch-Mode : navigate (navigation)
003Sec-Fetch-Site : same-origin (même origine)

Une requête intersites générée par un élément img entraînerait une requête avec les en-têtes de requête HTTP suivants (notez que le mode est no-cors) :

Script avec 3 lignes

001Sec-Fetch-Dest: image
002Sec-Fetch-Mode : no-cors (sans cors)
003Sec-Fetch-Site : same-site (même origine)

---

• MDN Web Docs : HTTP Headers Sec-Fetch-Mode (EN)

Sec-Fetch-Site : indique la relation entre l'origine d'un initiateur de demande et l'origine de la ressource demandée.

L'en-tête de demande de métadonnées d'extraction Sec-Fetch-Site indique la relation entre l'origine d'un initiateur de demande et l'origine de la ressource demandée. En d'autres termes, cet en-tête indique à un serveur si une demande de ressource provient de la même origine, du même site, d'un site différent, ou est une demande "initiée par l'utilisateur". Le serveur peut ensuite utiliser ces informations pour décider si la demande doit être autorisée.

Les demandes de même origine sont généralement autorisées par défaut, mais ce qui se passe pour les demandes provenant d'autres origines peut en outre dépendre de la ressource demandée ou des informations contenues dans d'autres en-têtes de demande de métadonnées Fetch. Par défaut, les demandes qui ne sont pas acceptées doivent être rejetées avec un code de réponse 403.

Directives

• cross-site : intersites
  L'initiateur de la demande et le serveur hébergeant la ressource ont un site différent (c'est-à-dire une demande de "potentially-evil.com" pour une ressource sur "example.com").
• same-origin : même origine
  L'initiateur de la requête et le serveur hébergeant la ressource ont la même origine (même schéma, hôte et port).
• same-site : même-site
  L'initiateur de la requête et le serveur hébergeant la ressource ont le même schéma, domaine et/ou sous-domaine, mais pas nécessairement le même port.
• none : rien
  Cette demande est une opération initiée par l'utilisateur. Par exemple : saisir une URL dans la barre d'adresse, ouvrir un signet ou glisser-déposer un fichier dans la fenêtre du navigateur.

Exemples

Une requête d'extraction vers https://mysite.example/foo.json provenant d'une page Web sur https://mysite.example (avec le même port) est une requête de même origine. Le navigateur générera l'en-tête Sec-Fetch-Site: same-origin comme indiqué ci-dessous, et le serveur autorisera généralement la requête :

Script avec 4 lignes

001GET /foo.json
002Sec-Fetch-Dest : none (vide)
003Sec-Fetch-Mode : cors
004Sec-Fetch-Site : same-origin (même origine) 

Une requête d'extraction vers la même URL à partir d'un autre site, par exemple potentiellement-evil.com, amène le navigateur à générer un en-tête différent (par exemple Sec-Fetch-Site : cross-site), que le serveur peut choisir d'accepter ou de rejeter :

Script avec 4 lignes

001GET /foo.json
002Sec-Fetch-Dest : none (vide)
003Sec-Fetch-Mode : cors
004Sec-Fetch-Site : cross-site (intersites)

---

• MDN Web Docs : HTTP Headers Sec-Fetch-Site (EN)

Sec-Fetch-User :

L'en-tête de requête de récupération de métadonnées Sec-Fetch-User n'est envoyé que pour les requêtes initiées par l'activation de l'utilisateur, et sa valeur sera toujours ?1.

Un serveur peut utiliser cet en-tête pour identifier si une requête de navigation à partir d'un document, d'un iframe, etc., a été émise par l'utilisateur.

Directives

• ?1 :
  La valeur sera toujours ?1. Lorsqu'une demande est déclenchée par autre chose qu'une activation de l'utilisateur, la spécification exige que les navigateurs omettent complètement l'en-tête.

Exemples

Si un utilisateur clique sur un lien vers une autre page de la même origine, la requête résultante aura les en-têtes suivants :

Script avec 4 lignes

001Sec-Fetch-Dest: document
002Sec-Fetch-Mode: navigate
003Sec-Fetch-Site: same-origin
004Sec-Fetch-User: ?1

---

Bonne gestion de vos ressources à travers le réseau international.

Cordialement,
Romain.

Liens de documentations CORS avec plus d'informations : CORP, COOP, COEP - CSP :

• The Fetch standard defines requests, responses, and the process that binds them: fetching.
• MDN Web Docs : Resources for developers, by developers.
  
  
• MDN Web Docs : Web APIs
• MDN Web Docs : API Request
  L'API Fetch fournit une interface pour récupérer des ressources (y compris sur le réseau). Cela semblera familier à tous ceux qui ont utilisé XMLHttpRequest, mais la nouvelle API fournit un ensemble de fonctionnalités plus puissant et plus flexible.
• MDN Web Docs : API Request.mode
  
  
• MDN Web Docs : Hypertext Transfer Protocol (HTTP)
• MDN Web Docs : HTTP Content Security Policy (CSP)
• MDN Web Docs : HTTP headers Politique de sécurité de contenu
• MDN Web Docs : HTTP Cross-Origin Resource Sharing (CORS)
• MDN Web Docs : HTTP Cross-Origin Resource Sharing (CORS) Errors CORS preflight channel did not succeed Reason: <acronym title="Cross-Origin Resource Sharing" lang="EN">CORS</acronym> preflight channel did not succeed (Raison : le canal de contrôle en amont CORS n'a pas réussi)
• MDN Web Docs : HTTP headers Cross-Origin Resource Sharing (CORS)
• MDN Web Docs : HTTP headers Security
• MDN Web Docs : HTTP headers Fetch metadata request headers
• MDN Web Docs : HTTP headers Upgrade

• The Modern JavaScript Tutorial : Fetch: Requêtes Cross-Origin
• Fetch Metadata and Isolation Policies
• ARunerBlog : CORS In Action - Preflight Invocation

• DreamHost : CORS headers (EN)
  Le partage de ressources d'origine croisée (CORS) permet de demander des ressources restreintes sur un site Web à un autre domaine en dehors du domaine à partir duquel il a été initialement servi.
• Web.Dev : Protect your resources from web attacks with Fetch Metadata (Protégez vos ressources contre les attaques Web avec Fetch Metadata)
  De nombreuses applications Web sont vulnérables aux attaques d'origine croisée telles que la falsification de requêtes intersites (CSRF), l'inclusion de scripts intersites (XSSI), les attaques de synchronisation, les fuites d'informations d'origines croisées ou les attaques par canal secondaire d'exécution spéculative (Spectre).
  Les en-têtes de requête Fetch Metadata vous permettent de déployer un puissant mécanisme de défense en profondeur (une politique d'isolation des ressources) pour protéger votre application contre ces attaques d'origine croisée courantes.
  Il est courant que les ressources exposées par une application Web donnée ne soient chargées que par l'application elle-même, et non par d'autres sites Web. Dans de tels cas, le déploiement d'une politique d'isolation des ressources basée sur les en-têtes de requête Fetch Metadata demande peu d'efforts et protège en même temps l'application contre les attaques intersites.

• WikipediA : Cross-origin resource sharing

---

OAuth : Open Authorization >>

---

---

---

Keywords :

Fetch Sec-Fetch Content-Security-Policy Cross-Origin X-Frame X-Content Fetch/request/protect an HTTP web resource Obtener/solicitar/proteger un recurso web HTTP جلب / طلب / حماية مورد ويب HTTP

---