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 consultez rapidement les informations les plus importantes.

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
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 vous y référer 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)
Types de confiance
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 :
Cross-Origin Resource Sharing (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é.

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 un pirate informatique. La faille la plus courante causée par des bugs d'injection est le script intersites (XSS) sous ses différentes formes, y compris le XSS réfléchi, 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 des API JavaScript dangereuses et le traitement approprié des données utilisateur en hébergeant les importations de fichiers dans un domaine distinct et en nettoyant le code HTML contrôlé par l'utilisateur.

  • Utilisez la Content Security Policy (CSP) pour contrôler les scripts pouvant être exécutés par votre application afin de limiter le risque d'injection.
  • Utilisez les Trusted Types pour appliquer le nettoyage des données transmises aux API JavaScript dangereuses.
  • Utilisez X-Content-Type-Options pour empêcher le navigateur de mal interpréter 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 d'une manière qui peut 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 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 de requête intersites (CSRF), l'inclusion de scripts intersites (XSSI) et diverses fuites intersites.

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

Créez un site Web performant en toute sécurité

Spectre rend potentiellement lisibles toutes les données chargées dans le même groupe de contexte de navigation, malgré la règle de même origine. Les navigateurs limitent les fonctionnalités susceptibles d'exploiter la faille 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.

Chiffrer le trafic vers votre site

Des problèmes de chiffrement surviennent lorsqu'une application ne chiffre pas entièrement les données en transit, ce qui permet à des pirates d'espionner 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.

Content Security Policy (CSP)

Le script intersites (XSS) est une attaque dans laquelle une faille sur un site Web permet d'injecter et d'exécuter un script malveillant.

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

Nous vous recommandons d'activer une 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 des nonces.
  • 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 : 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 une CSP

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

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

Générez une nouvelle valeur de 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 de développement 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 devez 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, lisez "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 stricte basée sur un nonce. Utilisez les outils de développement pour voir comment il est utilisé.

Navigateurs compatibles

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 approuvés à 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. Cela est devenu moins pertinent : de nos jours, la plupart des navigateurs bloquent le contenu mixte.
  • Vous pouvez également définir une CSP en mode rapport uniquement.
  • Si vous ne pouvez pas définir une CSP en tant qu'en-tête côté serveur, vous pouvez également la définir en tant que balise Meta. Notez que vous ne pouvez pas utiliser le mode Rapport uniquement pour les balises Meta (bien que cela puisse changer).

En savoir plus

Types de confiance

Le XSS basé sur le DOM est une attaque dans laquelle des données malveillantes sont transmises à un récepteur compatible avec l'exécution de code dynamique, tel que eval() ou .innerHTML.

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

Pour créer ces objets, vous pouvez définir des règles de sécurité dans lesquelles vous pouvez vous assurer que les règles de sécurité (telles que l'échappement ou la suppression) 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 susceptibles d'introduire des failles 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 de confiance

  1. 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 entendu, vous pouvez combiner les types de confiance avec d'autres directives CSP :

Fusion d'une CSP basée sur un nonce ci-dessus 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>


    
  
  1. 
    
    Définir une règle
    
    
    Règlement :
    
    
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    
    
  
    2. 
  
  2. 
    
    Appliquer la règle
    
    
    Utilisez la règle lors de l'écriture de 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 de confiance est obligatoire. L'utilisation d'une API DOM dangereuse avec une chaîne entraîne une erreur.
    
  
    3. 



Navigateurs compatibles



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


En savoir plus

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 intersites.

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

X-Content-Type-Options: nosniff est recommandé pour toutes les ressources diffusées à partir de votre serveur, avec l'en-tête Content-Type approprié.

X-Content-Type-Options: nosniff

Exemples 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

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Source

En savoir plus

X-Frame-Options

Si un site Web malveillant peut intégrer votre site en tant qu'iframe, cela peut permettre à des pirates d'appeler des actions involontaires de l'utilisateur par le biais du clickjacking. De plus, dans certains cas, les attaques de type Spectre permettent à des sites Web malveillants de découvrir le contenu d'un document intégré.

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

Exemple d'utilisation

X-Frame-Options: DENY
Utiliser X-Frame-Options

Tous les documents qui ne sont pas conçus pour être intégrés doivent utiliser l'en-tête X-Frame-Options.

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 
X-Frame-Options: DENY

Empêche l'intégration de votre site Web par des sites Web interorigines

Autoriser l'intégration uniquement par des documents de même origine.

X-Frame-Options: SAMEORIGIN

Navigateurs compatibles

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Source

En savoir plus

Règle de ressources interorigine (CORP)

Un pirate informatique peut intégrer des ressources d'une autre origine, par exemple de votre site, pour obtenir des informations les concernant en exploitant des fuites intersites 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 prend 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 leur chargement par d'autres sites Web.

Exemple d'utilisation

Cross-Origin-Resource-Policy: same-origin
Comment utiliser CORP

Il est recommandé de diffuser toutes les ressources avec l'un des trois en-têtes suivants.

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 interorigines), sauf si elles sont déjà diffusées via CORS, qui a un effet similaire.

Cross-Origin-Resource-Policy: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

Limiter les ressources à charger depuis same-origin

same-origin doit être appliqué aux ressources destinées à être chargées uniquement par des pages de même origine. Vous devez l'appliquer aux ressources qui incluent des informations sensibles sur l'utilisateur ou aux réponses d'une API qui n'est censée être appelée qu'à partir de la même origine.

N'oubliez pas que les ressources comportant 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 de ressources interorigines protège uniquement la ressource contre l'intégration par d'autres sites Web.

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

Limiter les ressources à charger depuis same-site

Il est recommandé d'appliquer same-site aux ressources semblables à celles ci-dessus, mais destinées à être chargées par d'autres sous-domaines de votre site.

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

Navigateurs compatibles

Browser Support

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Source

En savoir plus

Règle d'ouverture interorigine (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 intersites sur le Web. Dans certains cas, cela peut également permettre l'exploitation d'attaques par canal auxiliaire basées sur Spectre.

L'en-tête Cross-Origin-Opener-Policy permet à un document de s'isoler des fenêtres interorigines ouvertes via window.open() ou d'un lien avec target="_blank" sans rel="noopener". Par conséquent, tout outil d'ouverture interorigine 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

Isoler un document des fenêtres interorigines

La définition de same-origin permet d'isoler le document des fenêtres de document interorigines.

Cross-Origin-Opener-Policy: same-origin 
Cross-Origin-Opener-Policy: same-origin

Isoler un document des fenêtres interorigines, mais autoriser les pop-ups

La définition de same-origin-allow-popups permet à un document de conserver une référence à ses fenêtres pop-up, sauf si elles définissent COOP avec same-origin ou same-origin-allow-popups. Cela signifie que same-origin-allow-popups peut toujours empêcher le document d'être référencé lorsqu'il est ouvert en tant que fenêtre pop-up, mais lui permettre de communiquer avec ses propres pop-ups.

Cross-Origin-Opener-Policy: same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

Autoriser un document à être référencé par des fenêtres interorigines

unsafe-none est la valeur par défaut, mais vous pouvez indiquer explicitement que ce document peut être ouvert par une fenêtre interorigine et conserver l'accès mutuel.

Cross-Origin-Opener-Policy: unsafe-none 
Cross-Origin-Opener-Policy: unsafe-none

Modèles de rapport incompatibles 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 la communication entre les documents interorigines.

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

Navigateurs compatibles

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

En savoir plus

Partage des ressources entre origines multiples (CORS)

Contrairement aux autres éléments de cet article, le partage de ressources inter-origines (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 interorigines. Par exemple, lorsqu'une image interorigine 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. Selon les détails de la requête, celle-ci sera classée comme une requête simple ou une requête préliminaire.

Critères d'une requête 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.
  • La valeur de Content-Type est 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 de ressources interorigines (CORS) - HTTP | MDN.

Requête simple

Lorsqu'une requête répond aux critères d'une requête simple, le navigateur envoie une requête interorigine 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 l'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 n'exigera que la requête soit effectuée sans identifiants.
  • Access-Control-Allow-Credentials: true indique que les requêtes contenant des identifiants (cookies) sont autorisées à charger la ressource. Sinon, les requêtes authentifiées seront rejetées, même si l'origine de la requête est présente dans l'en-tête Access-Control-Allow-Origin.

Requêtes préliminaires

Une requête préliminaire 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 ultérieures 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 ultérieures 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

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

Source

En savoir plus

Règle de l'intégrateur interorigine (COEP)

Pour réduire la capacité des attaques basées sur Spectre à voler des ressources interorigines, 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 workers de charger des ressources interorigines telles que des images, des scripts, des feuilles de style, des iFrames et autres, sauf si ces ressources acceptent explicitement d'être chargées via des en-têtes CORS ou CORP. COEP peut être combiné avec Cross-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 n'accepte qu'une seule valeur : require-corp. En envoyant cet en-tête, vous pouvez demander au navigateur de bloquer le chargement des ressources qui ne sont pas activées via CORS ou CORP.

Fonctionnement de COEP

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 non compatibles avec COEP

Vous pouvez recevoir des rapports sur les ressources bloquées par la COEP à l'aide de l'API Reporting.

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP est également compatible avec le mode "Rapport uniquement", ce qui vous permet de recevoir des rapports sans bloquer le chargement des ressources.

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

Navigateurs compatibles

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

En savoir plus

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 écoutes au niveau du réseau.

L'en-tête Strict-Transport-Security indique au navigateur qu'il ne doit jamais charger le site en HTTP, mais utiliser HTTPS à la place. Une fois l'en-tête défini, le navigateur utilise 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

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

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Source

En savoir plus

Documentation complémentaire

Précédent
Définition des termes "same-site" et "same-origin"