Guide de référence rapide sur les en-têtes de sécurité

Découvrez les en-têtes qui peuvent protéger votre site et recherchez rapidement les informations les plus importantes.

Eiji Kitamura

Artur Janc

Maud Nalpas

Cet article liste les en-têtes de sécurité les plus importants que vous pouvez utiliser pour protéger votre site Web. Utilisez-le pour comprendre les fonctionnalités de sécurité Web, apprendre à les implémenter sur votre site Web et comme référence lorsque vous avez besoin d'un rappel.

En-têtes de sécurité recommandés pour les sites Web qui traitent des données utilisateur sensibles :: Content Security Policy (CSP); Trusted Types
En-têtes de sécurité recommandés pour tous les sites Web :: X-Content-Type-Options; X-Frame-Options; Cross-Origin Resource Policy (CORP); Cross-Origin Opener Policy (COOP); HTTP Strict Transport Security (HSTS)
En-têtes de sécurité pour les sites Web dotés de fonctionnalités avancées :: Partage des ressources entre origines multiples (CORS); Cross-Origin Embedder Policy (COEP)

Menaces connues sur le Web

Avant de vous intéresser aux en-têtes de sécurité, découvrez les menaces connues sur le Web et pourquoi vous devriez utiliser ces en-têtes de sécurité.

Protéger votre site contre les failles d'injection

Les failles d'injection se produisent lorsque des données non fiables traitées par votre application peuvent affecter son comportement et, généralement, entraîner l'exécution de scripts contrôlés par des pirates informatiques. La faille la plus courante causée par les bugs d'injection est le script intersites (XSS) sous ses différentes formes, y compris le XSS par réflexion, le XSS stocké, le XSS basé sur le DOM et d'autres variantes.

Une faille XSS peut généralement donner à un pirate informatique un accès complet aux données utilisateur traitées par l'application et à toute autre information hébergée dans la même origine Web.

Les défenses traditionnelles contre les injections incluent l'utilisation cohérente de systèmes de modèles HTML à échappement automatique, l'évitement de l'utilisation d'API JavaScript dangereuses et le traitement approprié des données utilisateur en hébergeant les importations de fichiers dans un domaine distinct et en assainissant le code HTML contrôlé par l'utilisateur.

Utilisez la Content Security Policy (CSP) pour contrôler les scripts qui peuvent être exécutés par votre application afin de réduire le risque d'injections.
Utilisez les Trusted Types pour appliquer la désinfection des données transmises aux API JavaScript dangereuses.
Utilisez X-Content-Type-Options pour empêcher le navigateur d'interpréter de manière incorrecte les types MIME des ressources de votre site Web, ce qui peut entraîner l'exécution de scripts.

Isoler votre site des autres sites Web

L'ouverture du Web permet aux sites Web d'interagir les uns avec les autres de manière à enfreindre les attentes de sécurité d'une application. Cela inclut l'envoi inattendu de requêtes authentifiées ou l'intégration de données provenant d'une autre application dans le document du pirate informatique, ce qui lui permet de modifier ou de lire les données de l'application.

Les failles courantes qui compromettent l'isolation Web incluent le détournement de clic, la falsification des requêtes intersites (CSRF), l'inclusion de scripts intersites (XSSI) et diverses fuites intersites.

Utilisez X-Frame-Options pour empêcher l'intégration de vos documents par un site Web malveillant.
Utilisez la stratégie CORP (Cross-Origin Resource Policy) pour empêcher les ressources de votre site Web d'être incluses par un site Web multi-origine.
Utilisez la Cross-Origin Opener Policy (COOP) pour protéger les fenêtres de votre site Web contre les interactions de sites Web malveillants.
Utilisez le partage des ressources entre origines multiples (CORS) pour contrôler l'accès aux ressources de votre site Web à partir de documents multi-origines.

Post-Spectre Web Development est une excellente lecture si ces en-têtes vous intéressent.

Créez un site Web performant et sécurisé

Spectre permet de lire potentiellement toutes les données chargées dans le même groupe de contexte de navigation, malgré la règle d'origine identique. Les navigateurs limitent les fonctionnalités qui pourraient exploiter la vulnérabilité derrière un environnement spécial appelé isolation multi-origine. L'isolation multi-origine vous permet d'utiliser des fonctionnalités puissantes telles que SharedArrayBuffer.

Utilisez la règle COEP (Cross-Origin Embedder Policy) avec COOP pour activer l'isolation multi-origine.

Chiffrer le trafic vers votre site

Les problèmes de chiffrement se produisent lorsqu'une application ne chiffre pas complètement les données en transit, ce qui permet aux pirates informatiques qui écoutent les communications d'en savoir plus sur les interactions de l'utilisateur avec l'application.

Un chiffrement insuffisant peut se produire dans les cas suivants : non-utilisation de HTTPS, contenu mixte, définition de cookies sans l'attribut Secure (ou le préfixe __Secure) ou logique de validation CORS laxiste.

Utilisez HTTP Strict Transport Security (HSTS) pour diffuser systématiquement vos contenus via HTTPS.

Content Security Policy (CSP)

Le script intersites (XSS) est une attaque qui exploite une faille de sécurité sur un site Web pour injecter et exécuter un script malveillant.

Content-Security-Policy fournit une couche supplémentaire pour atténuer les attaques XSS en limitant les scripts qui peuvent être exécutés par la page.

Nous vous recommandons d'activer la CSP stricte en utilisant l'une des approches suivantes :

Si vous affichez vos pages HTML sur le serveur, utilisez une CSP stricte basée sur une nonce.
Si votre code HTML doit être diffusé de manière statique ou mis en cache (par exemple, s'il s'agit d'une application monopage), utilisez une CSP stricte basée sur un hachage.

Exemple d'utilisation : une CSP basée sur un nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Utiliser CSP

Utilisations recommandées

1. Utiliser une CSP stricte basée sur une nonce {: #nonce-based-csp}

Si vous affichez vos pages HTML sur le serveur, utilisez une CSP stricte basée sur une nonce.

Générez une nouvelle valeur nonce de script pour chaque requête côté serveur et définissez l'en-tête suivant :

fichier de configuration du serveur

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

En HTML, pour charger les scripts, définissez l'attribut nonce de toutes les balises <script> sur la même chaîne {RANDOM1}.

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google Photos est un bon exemple de CSP stricte basée sur des nonces. Utilisez les outils pour les développeurs pour voir comment il est utilisé.

2. Utiliser une CSP stricte basée sur le hachage {: #hash-based-csp}

Si votre code HTML doit être diffusé de manière statique ou mis en cache, par exemple si vous créez une application monopage, utilisez une CSP stricte basée sur un hachage.

fichier de configuration du serveur

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

En HTML, vous devrez intégrer vos scripts pour appliquer une règle basée sur le hachage, car la plupart des navigateurs ne sont pas compatibles avec le hachage des scripts externes.

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

Pour charger des scripts externes, consultez "Charger des scripts sources de manière dynamique" dans la section Option B : En-tête de réponse CSP basé sur le hachage.

CSP Evaluator est un bon outil pour évaluer votre CSP, mais aussi un bon exemple de CSP strict basé sur un nonce. Utilisez les outils pour les développeurs pour voir comment il est utilisé.

Navigateurs compatibles

* https: est une solution de secours pour Safari et unsafe-inline est une solution de secours pour les très anciennes versions de navigateur. https: et unsafe-inline ne rendent pas votre règle moins sûre, car ils seront ignorés par les navigateurs compatibles avec strict-dynamic. Pour en savoir plus, consultez Ajouter des solutions de remplacement pour prendre en charge Safari et les anciens navigateurs. * Safari n'est pas encore compatible avec strict-dynamic. Toutefois, un CSP strict comme dans les exemples ci-dessus est plus sûr qu'un CSP de liste d'autorisation (et beaucoup plus sûr qu'aucun CSP) pour tous vos utilisateurs. Même dans Safari, une CSP stricte protège votre site contre certains types d'attaques XSS, car la présence de la CSP interdit certains schémas non sécurisés.

Autres points à noter concernant les CSP

La directive frame-ancestors protège votre site contre le détournement de clic, un risque qui survient si vous autorisez des sites non fiables à intégrer le vôtre. Si vous préférez une solution plus simple, vous pouvez utiliser X-Frame-Options pour bloquer le chargement, mais frame-ancestors vous offre une configuration avancée pour n'autoriser que des origines spécifiques en tant qu'intégrateurs.
Vous avez peut-être utilisé une CSP pour vous assurer que toutes les ressources de votre site sont chargées via HTTPS. Cette méthode est devenue moins pertinente, car la plupart des navigateurs bloquent désormais le contenu mixte.
Vous pouvez également définir un CSP en mode rapport uniquement.
Si vous ne pouvez pas définir de CSP en tant qu'en-tête côté serveur, vous pouvez également le définir en tant que balise Meta. Notez que vous ne pouvez pas utiliser le mode rapport uniquement pour les balises Meta (mais cela peut changer).

En savoir plus

Trusted Types

L'attaque XSS basée sur le DOM consiste à transmettre des données malveillantes à un récepteur qui accepte l'exécution de code dynamique, comme eval() ou .innerHTML.

Les Trusted Types fournissent les outils nécessaires pour écrire, examiner et gérer des applications sans XSS DOM. Ils peuvent être activés via CSP et sécuriser le code JavaScript par défaut en limitant les API Web dangereuses pour qu'elles n'acceptent qu'un objet spécial : un type approuvé.

Pour créer ces objets, vous pouvez définir des stratégies de sécurité dans lesquelles vous pouvez vous assurer que les règles de sécurité (telles que l'échappement ou l'assainissement) sont appliquées de manière cohérente avant que les données ne soient écrites dans le DOM. Ces règles sont alors les seuls endroits du code qui pourraient potentiellement introduire du DOM XSS.

Exemples d'utilisation

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;

Utiliser les types fiables

Utilisations recommandées

Appliquer les Trusted Types pour les récepteurs DOM dangereux En-tête CSP et Trusted Types :
```
Content-Security-Policy: require-trusted-types-for 'script'
```
Actuellement, 'script' est la seule valeur acceptable pour la directive require-trusted-types-for.

Bien sûr, vous pouvez combiner les types approuvés avec d'autres directives CSP :

Fusionner une CSP basée sur un nonce avec les Trusted Types :

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;


<aside class="note"><b>Remarque</b> : Vous pouvez limiter les noms de règles Trusted Types autorisés en définissant une directive <code>trusted-types</code> supplémentaire (par exemple, <code>trusted-types myPolicy</code>). Toutefois, cela n'est pas obligatoire.  </aside>


  
    Définir une règle
    Règle :
    
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    Remarque  : Vous pouvez définir des règles avec des noms arbitraires, sauf si vous limitez les noms des règles de types approuvés autorisés en définissant la directive trusted-types. 
  
  
    Appliquer la règle
    Utilisez la règle lorsque vous écrivez des données dans le DOM :
    
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    Avec require-trusted-types-for 'script', l'utilisation d'un type fiable est obligatoire. L'utilisation d'une API DOM dangereuse avec une chaîne générera une erreur.
  

Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
En savoir plus

  Éviter les failles de script intersites basées sur le DOM avec les Trusted Types
  CSP: require-trusted-types-for - HTTP |
      MDN
  CSP : trusted-types – HTTP |
      MDN
  Démonstration des Trusted Types : ouvrez l'inspecteur des outils de développement et voyez ce qui se passe.



X-Content-Type-Options

Lorsqu'un document HTML malveillant est diffusé à partir de votre domaine (par exemple, si une image importée dans un service photo contient un balisage HTML valide), certains navigateurs le traitent comme un document actif et l'autorisent à exécuter des scripts dans le contexte de l'application, ce qui entraîne un bug de script intersite.

X-Content-Type-Options: nosniff l'empêche en indiquant au navigateur que le type MIME défini dans l'en-tête Content-Type pour une réponse donnée est correct. Cet en-tête est recommandé pour toutes vos ressources.

Exemple d'utilisation
X-Content-Type-Options: nosniff


  
    
    Utiliser X-Content-Type-Options


    
      Utilisations recommandées
X-Content-Type-Options: nosniff est recommandé pour toutes les ressources diffusées depuis votre serveur, ainsi que pour l'en-tête Content-Type approprié.

Exemple d'en-têtes envoyés avec un document HTML
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  X-Content-Type-Options : HTTP MDN

    
  


X-Frame-Options

Si un site Web malveillant peut intégrer votre site en tant qu'iframe, les pirates informatiques peuvent être en mesure d'inciter l'utilisateur à effectuer des actions non souhaitées à l'aide du clickjacking. De plus, dans certains cas, les attaques de type Spectre permettent aux sites Web malveillants d'en savoir plus sur le contenu d'un document intégré.

X-Frame-Options indique si un navigateur est autorisé ou non à afficher une page dans un <frame>, <iframe>, <embed> ou <object>. Il est recommandé d'envoyer cet en-tête pour tous les documents afin d'indiquer s'ils peuvent être intégrés par d'autres documents.

Remarque  : Si vous avez besoin d'un contrôle plus précis, par exemple pour autoriser uniquement une origine spécifique à intégrer le document, utilisez la directive CSP frame-ancestors.  

Exemple d'utilisation
X-Frame-Options: DENY


  
    
    Utiliser X-Frame-Options


    
      Utilisations recommandées
Tous les documents qui ne sont pas conçus pour être intégrés doivent utiliser l'en-tête X-Frame-Options.
Vous pouvez tester l'impact des configurations suivantes sur le chargement d'un iFrame dans cette démo. Modifiez le menu déroulant X-Frame-Options, puis cliquez sur le bouton Recharger l'iFrame.
Empêche l'intégration de votre site Web par d'autres sites Web
Refuser l'intégration par d'autres documents

X-Frame-Options: DENY
Protège votre site Web contre l'intégration par des sites Web d'origine croisée
Autoriser l'intégration uniquement par des documents de même origine.
X-Frame-Options: SAMEORIGIN
 Le fait que les documents soient intégrables par défaut signifie que les développeurs Web doivent envoyer explicitement DENY ou SAMEORIGIN pour empêcher l'intégration et se protéger contre les attaques par canal auxiliaire. L'équipe Chrome envisage de passer au blocage des intégrations de documents par défaut afin que les sites Web soient sécurisés même s'ils ne définissent pas explicitement l'en-tête. Dans ce nouveau monde, les documents devraient être explicitement activés pour être intégrés. 
Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  X-Frame-Options – HTTP

    
  


Règle de ressources multi-origine (CORP)

Un pirate informatique peut intégrer des ressources provenant d'une autre origine, par exemple de votre site, pour obtenir des informations à leur sujet en exploitant les fuites multisites sur le Web.

Cross-Origin-Resource-Policy atténue ce risque en indiquant l'ensemble des sites Web par lesquels il peut être chargé. L'en-tête peut prendre l'une des trois valeurs suivantes : same-origin, same-site et cross-origin. Il est recommandé que toutes les ressources envoient cet en-tête pour indiquer si elles autorisent le chargement par d'autres sites Web.

Exemple d'utilisation
Cross-Origin-Resource-Policy: same-origin


  
    
    Utiliser CORP


    
      Utilisations recommandées
Nous vous recommandons de diffuser toutes les ressources avec l'un des trois en-têtes suivants.
Vous pouvez tester l'effet des configurations suivantes sur le chargement des ressources dans un environnement Cross-Origin-Embedder-Policy: require-corp sur cette démo. Modifiez le menu déroulant Cross-Origin-Resource-Policy, puis cliquez sur le bouton Reload the iframe (Recharger l'iFrame) ou Reload the image (Recharger l'image) pour voir l'effet.

Autoriser le chargement des ressources cross-origin
Il est recommandé que les services de type CDN appliquent cross-origin aux ressources (car elles sont généralement chargées par des pages d'origines différentes), sauf si elles sont déjà diffusées via CORS, qui a un effet similaire.

Cross-Origin-Resource-Policy: cross-origin
Limiter les ressources à charger à partir du same-origin
same-origin doit être appliqué aux ressources qui ne sont censées être chargées que par des pages de même origine. Vous devez appliquer cette règle aux ressources qui incluent des informations sensibles sur l'utilisateur ou aux réponses d'une API qui ne doit être appelée que depuis la même origine.
N'oubliez pas que les ressources avec cet en-tête peuvent toujours être chargées directement, par exemple en accédant à l'URL dans une nouvelle fenêtre de navigateur. La règle Cross-Origin Resource Policy protège uniquement la ressource contre l'intégration par d'autres sites Web.

Cross-Origin-Resource-Policy: same-origin
Limiter les ressources à charger à partir du same-site
Il est recommandé d'appliquer same-site aux ressources semblables à celles ci-dessus, mais qui sont destinées à être chargées par d'autres sous-domaines de votre site.

Cross-Origin-Resource-Policy: same-site
Remarque  : Pour en savoir plus sur la différence entre "même origine" et "même site", consultez Comprendre "même site" et "même origine". 
Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  Envisagez de déployer une stratégie de ressources d'origine croisée
  Isoler votre site Web "cross-origin" à l'aide de COOP et COEP
  Pourquoi avez-vous besoin de l'isolation multi-origine pour les fonctionnalités puissantes ?

    
  


Règle d'ouverture multi-origine (COOP)

Le site Web d'un pirate informatique peut ouvrir un autre site dans une fenêtre pop-up pour obtenir des informations à son sujet en exploitant les fuites multisites basées sur le Web. Dans certains cas, cela peut également permettre l'exploitation d'attaques par canal secondaire basées sur Spectre.

L'en-tête Cross-Origin-Opener-Policy permet à un document de s'isoler des fenêtres d'origine croisée ouvertes via window.open() ou un lien avec target="_blank" sans rel="noopener". Par conséquent, tout ouvreur cross-origin du document n'aura aucune référence à celui-ci et ne pourra pas interagir avec lui.

Exemple d'utilisation
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    Utiliser COOP


    
      Utilisations recommandées
Vous pouvez tester l'impact des configurations suivantes sur la communication avec une fenêtre pop-up d'origine croisée dans cette démo.
  Modifiez le menu déroulant Cross-Origin-Opener-Policy pour le document et la fenêtre pop-up, cliquez sur le bouton Open a popup (Ouvrir un pop-up), puis sur Send a postMessage (Envoyer un postMessage) pour vérifier si le message est bien transmis.
Isoler un document des fenêtres d'origine différente
Le paramètre same-origin permet d'isoler le document des fenêtres de document multi-origines.

Cross-Origin-Opener-Policy: same-origin
Isoler un document des fenêtres d'origine différente, mais autoriser les pop-up
Le paramètre same-origin-allow-popups permet à un document de conserver une référence à ses fenêtres pop-up, sauf s'il définit COOP sur same-origin ou same-origin-allow-popups. Cela signifie que same-origin-allow-popups peut toujours protéger le document contre toute référence lorsqu'il est ouvert dans une fenêtre pop-up, mais lui permettre de communiquer avec ses propres pop-ups.


Cross-Origin-Opener-Policy: same-origin-allow-popups
Autoriser la référence à un document par des fenêtres d'origine croisée
unsafe-none est la valeur par défaut, mais vous pouvez indiquer explicitement que ce document peut être ouvert par une fenêtre multi-origine et conserver l'accès mutuel.

 unsafe-none étant la valeur par défaut, les développeurs Web doivent envoyer same-origin ou same-origin-allow-popups de manière explicite pour protéger leur site Web contre les attaques par canal auxiliaire. 
Cross-Origin-Opener-Policy: unsafe-none
Remarque  : Les fonctionnalités telles que SharedArrayBuffer ou performance.measureUserAgentSpecificMemory() sont désactivées par défaut. Certains navigateurs vous permettent de les utiliser dans des contextes "cross-origin isolated", qui nécessitent de définir les en-têtes COOP et COEP. Pour en savoir plus, consultez Rendre votre site Web "cross-origin isolated" à l'aide de COOP et COEP. 
Signaler des schémas non compatibles avec COOP
Vous pouvez recevoir des rapports lorsque COOP empêche les interactions entre fenêtres avec l'API Reporting.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP est également compatible avec un mode "rapport uniquement", qui vous permet de recevoir des rapports sans bloquer réellement la communication entre les documents d'origines différentes.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  Pourquoi avez-vous besoin de l'isolation multi-origine pour les fonctionnalités puissantes ?

    
  


Partage des ressources entre origines multiples (CORS)

Contrairement aux autres éléments de cet article, le partage de ressources entre origines multiples (CORS, Cross-Origin Resource Sharing) n'est pas un en-tête, mais un mécanisme de navigateur qui demande et autorise l'accès aux ressources inter-origines.

Par défaut, les navigateurs appliquent la règle de même origine pour empêcher une page Web d'accéder à des ressources d'origines multiples. Par exemple, lorsqu'une image cross-origin est chargée, même si elle s'affiche visuellement sur la page Web, le code JavaScript de la page n'a pas accès aux données de l'image.
Le fournisseur de ressources peut assouplir les restrictions et autoriser d'autres sites Web à lire la ressource en activant CORS.

Exemple d'utilisation
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true


  
    
    Utiliser CORS


    
      Avant de voir comment configurer CORS, il est utile de comprendre la distinction entre les types de requêtes. En fonction des détails de la requête, celle-ci sera classée comme requête simple ou requête préliminaire.
Critères pour une demande simple :

  La méthode est GET, HEAD ou POST.
  Les en-têtes personnalisés n'incluent que Accept, Accept-Language, Content-Language et Content-Type.
  
  Content-Type correspond à application/x-www-form-urlencoded, multipart/form-data ou text/plain.
  

Tout le reste est classé comme une requête préliminaire. Pour en savoir plus, consultez Partage des ressources entre origines multiples (CORS) : HTTP | MDN.
Utilisations recommandées
Requête simple
Lorsqu'une requête répond aux critères de requête simple, le navigateur envoie une requête d'origines croisées avec un en-tête Origin qui indique l'origine de la requête.
Exemple d'en-tête de requête
Get / HTTP/1.1
Origin: https://example.com
Exemple d'en-tête de réponse
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

  Access-Control-Allow-Origin: https://example.com indique que le https://example.com peut accéder au contenu de la réponse. Les ressources destinées à être lisibles par n'importe quel site peuvent définir cet en-tête sur *. Dans ce cas, le navigateur exigera uniquement que la requête soit effectuée sans identifiants.
  
  Access-Control-Allow-Credentials: true indique que les requêtes qui contiennent des identifiants (cookies) sont autorisées à charger la ressource. Sinon, les requêtes authentifiées seront refusées même si l'origine de la requête est présente dans l'en-tête Access-Control-Allow-Origin.

Vous pouvez tester l'impact de la requête simple sur le chargement des ressources dans un environnement Cross-Origin-Embedder-Policy: require-corp sur cette démo. Cochez la case Cross-Origin Resource Sharing (Partage des ressources d'origine croisée), puis cliquez sur le bouton Reload the image (Recharger l'image) pour voir l'effet.

Requêtes préliminaires
Une requête pré-vérifiée est précédée d'une requête OPTIONS pour vérifier si la requête suivante peut être envoyée.
Exemple d'en-tête de requête
OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

  Access-Control-Request-Method: POST permet d'effectuer la requête suivante avec la méthode POST.
  Access-Control-Request-Headers: X-PINGOTHER, Content-Type permet au demandeur de définir les en-têtes HTTP X-PINGOTHER et Content-Type dans la requête suivante.

Exemples d'en-têtes de réponse
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

  Access-Control-Allow-Methods: POST, GET, OPTIONS indique que les requêtes suivantes peuvent être effectuées avec les méthodes POST, GET et OPTIONS.
  Access-Control-Allow-Headers: X-PINGOTHER, Content-Type indique que les requêtes suivantes peuvent inclure les en-têtes X-PINGOTHER et Content-Type.
  Access-Control-Max-Age: 86400 indique que le résultat de la requête préliminaire peut être mis en cache pendant 86 400 secondes.

Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  Partage des ressources entre origines multiples (CORS)
  Cross-Origin Resource Sharing (CORS) : HTTP | MDN

    
  


Règlement de l'intégrateur multi-origine (COEP)

Pour réduire la capacité des attaques basées sur Spectre à voler des ressources d'origine croisée, des fonctionnalités telles que SharedArrayBuffer ou performance.measureUserAgentSpecificMemory() sont désactivées par défaut.

Cross-Origin-Embedder-Policy: require-corp empêche les documents et les nœuds de calcul de charger des ressources d'origine croisée telles que des images, des scripts, des feuilles de style, des iFrames et autres, sauf si ces ressources choisissent explicitement d'être chargées via les en-têtes CORS ou CORP. COEP peut être combiné avecCross-Origin-Opener-Policy
pour activer l'isolation multi-origine d'un document.

Utilisez Cross-Origin-Embedder-Policy: require-corp lorsque vous souhaitez activer l'isolation multi-origine pour votre document.

Exemple d'utilisation
Cross-Origin-Embedder-Policy: require-corp


  
    
    Utiliser COEP


    
      Exemples d'utilisation
COEP accepte une seule valeur : require-corp. En envoyant cet en-tête, vous pouvez demander au navigateur de bloquer le chargement des ressources qui n'ont pas été activées via CORS ou CORP.


Vous pouvez tester l'effet des configurations suivantes sur le chargement des ressources dans cette démonstration. Modifiez les menus déroulants Cross-Origin-Embedder-Policy et Cross-Origin-Resource-Policy, la case à cocher Report Only, etc. pour voir comment ils affectent le chargement des ressources. Ouvrez également la démonstration du point de terminaison de création de rapports pour voir si les ressources bloquées sont signalées.

Activer l'isolation multi-origine
Activez l'isolation multi-origine en envoyant Cross-Origin-Embedder-Policy: require-corp avec Cross-Origin-Opener-Policy: same-origin.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Signaler les ressources incompatibles avec COEP
Vous pouvez recevoir des rapports sur les ressources bloquées par COEP avec l'API Reporting.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP est également compatible avec le mode "rapport uniquement", qui vous permet de recevoir des rapports sans bloquer réellement le chargement des ressources.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  Isoler votre site Web "cross-origin" à l'aide de COOP et COEP
  Pourquoi avez-vous besoin de l'isolation multi-origine pour les fonctionnalités puissantes ?
  Guide pour activer l'isolation multi-origine

    
  


HTTP Strict Transport Security (HSTS)

La communication via une connexion HTTP simple n'est pas chiffrée, ce qui rend les données transférées accessibles aux espions au niveau du réseau.

L'en-tête Strict-Transport-Security indique au navigateur qu'il ne doit jamais charger le site à l'aide du protocole HTTP et qu'il doit utiliser HTTPS à la place. Une fois défini, le navigateur utilisera HTTPS au lieu de HTTP pour accéder au domaine sans redirection pendant une durée définie dans l'en-tête.

Exemple d'utilisation
Strict-Transport-Security: max-age=31536000


  
    
    Utiliser HSTS


    
      Utilisations recommandées
Tous les sites Web qui passent de HTTP à HTTPS doivent répondre avec un en-tête Strict-Transport-Security lorsqu'une requête HTTP est reçue.

Strict-Transport-Security: max-age=31536000
Navigateurs compatibles

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
En savoir plus

  Strict-Transport-Security –
      HTTP

    
  


Documentation complémentaire


Développement Web post-Spectre

Guide de référence rapide sur les en-têtes de sécurité Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Protéger votre site contre les failles d'injection

Isoler votre site des autres sites Web

Créez un site Web performant et sécurisé

Chiffrer le trafic vers votre site

Content Security Policy (CSP)

Utilisations recommandées

1. Utiliser une CSP stricte basée sur une nonce {: #nonce-based-csp}

2. Utiliser une CSP stricte basée sur le hachage {: #hash-based-csp}

Navigateurs compatibles

Autres points à noter concernant les CSP

En savoir plus

Trusted Types

Utilisations recommandées

Navigateurs compatibles

En savoir plus

X-Content-Type-Options

Utilisations recommandées

Navigateurs compatibles

En savoir plus

X-Frame-Options

Utilisations recommandées

Empêche l'intégration de votre site Web par d'autres sites Web

Protège votre site Web contre l'intégration par des sites Web d'origine croisée

Navigateurs compatibles

En savoir plus

Règle de ressources multi-origine (CORP)

Utilisations recommandées

Autoriser le chargement des ressources cross-origin

Limiter les ressources à charger à partir du same-origin

Limiter les ressources à charger à partir du same-site

Navigateurs compatibles

En savoir plus

Règle d'ouverture multi-origine (COOP)

Utilisations recommandées

Isoler un document des fenêtres d'origine différente

Isoler un document des fenêtres d'origine différente, mais autoriser les pop-up

Autoriser la référence à un document par des fenêtres d'origine croisée

Signaler des schémas non compatibles avec COOP

Navigateurs compatibles

En savoir plus

Partage des ressources entre origines multiples (CORS)

Utilisations recommandées

Requête simple

Requêtes préliminaires

Navigateurs compatibles

En savoir plus

Règlement de l'intégrateur multi-origine (COEP)

Exemples d'utilisation

Activer l'isolation multi-origine

Signaler les ressources incompatibles avec COEP

Navigateurs compatibles

En savoir plus

HTTP Strict Transport Security (HSTS)

Utilisations recommandées

Navigateurs compatibles

En savoir plus

Documentation complémentaire

Guide de référence rapide sur les en-têtes de sécurité

Autoriser le chargement des ressources `cross-origin`

Limiter les ressources à charger à partir du `same-origin`

Limiter les ressources à charger à partir du `same-site`