aboutsummaryrefslogtreecommitdiff
path: root/files/fr/web/security
diff options
context:
space:
mode:
authorPeter Bengtsson <mail@peterbe.com>2020-12-08 14:40:17 -0500
committerPeter Bengtsson <mail@peterbe.com>2020-12-08 14:40:17 -0500
commit33058f2b292b3a581333bdfb21b8f671898c5060 (patch)
tree51c3e392513ec574331b2d3f85c394445ea803c6 /files/fr/web/security
parent8b66d724f7caf0157093fb09cfec8fbd0c6ad50a (diff)
downloadtranslated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.gz
translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.bz2
translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.zip
initial commit
Diffstat (limited to 'files/fr/web/security')
-rw-r--r--files/fr/web/security/index.html24
-rw-r--r--files/fr/web/security/public_key_pinning/index.html170
-rw-r--r--files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.html56
-rw-r--r--files/fr/web/security/same_origin_policy_for_javascript/index.html115
-rw-r--r--files/fr/web/security/secure_contexts/index.html154
-rw-r--r--files/fr/web/security/subresource_integrity/index.html147
6 files changed, 666 insertions, 0 deletions
diff --git a/files/fr/web/security/index.html b/files/fr/web/security/index.html
new file mode 100644
index 0000000000..7cb67bdad9
--- /dev/null
+++ b/files/fr/web/security/index.html
@@ -0,0 +1,24 @@
+---
+title: Sécurité Web
+slug: Web/Security
+tags:
+ - Landing
+ - Security
+ - Web
+translation_of: Web/Security
+---
+<div class="summary">
+<p><span class="seoSummary">La sécurité d'un site internet ou d'une application web est essentielle. Même de simple bugs dans votre code peuvent impliquer la fuite d'informations privées et des personnes mals intentionnées essayent constamment de trouver des moyens de voler des données. Les articles sur la sécurité web listés ici fournissent des informations qui devraient vous aider à sécuriser votre site et rendre votre code plus sûr contre les attaques et vols de données.</span></p>
+</div>
+
+<p>{{LandingPageListSubpages}}</p>
+
+<h2 id="Voir_aussi">Voir aussi</h2>
+
+<ul>
+ <li><a href="https://lists.mozilla.org/listinfo/dev-security">Liste de diffusion (<em>mailing list</em>) (en anglais)</a></li>
+ <li><a href="https://blog.mozilla.com/security/">Blog</a></li>
+ <li><a href="https://twitter.com/mozsec">@mozsec on Twitter</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages}}</p>
diff --git a/files/fr/web/security/public_key_pinning/index.html b/files/fr/web/security/public_key_pinning/index.html
new file mode 100644
index 0000000000..287455b2e0
--- /dev/null
+++ b/files/fr/web/security/public_key_pinning/index.html
@@ -0,0 +1,170 @@
+---
+title: Public Key Pinning
+slug: Web/Security/Public_Key_Pinning
+tags:
+ - HTTPS
+ - Référence(2)
+ - Sécurité
+translation_of: Web/HTTP/Public_Key_Pinning
+---
+<p class="summary"><span class="seoSummary">L'extention <strong>Public Key Pinning pour HTTP</strong> (HPKP) est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques <a href="https://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu">MITM</a> avec des certificats contrefaits.</span></p>
+
+<div class="note">
+<p><strong>Note :</strong> La Public Key Pinning décrite ici est différente du limité <a href="http://monica-at-mozilla.blogspot.de/2014/08/firefox-32-supports-public-key-pinning.html">preload list based key pinning</a> introduit dans Firefox 32.</p>
+</div>
+
+<p>Pour s'assurer de l’authenticité de la clé publique du serveur utilisé dans une session TLS, cette clé publique est enveloppée dans un certificat X.509 qui est généralement signé par une autorité de certifications (CA, pour Certificate Authority). Les clients web tels que les navigateurs font confiance à beaucoup de ces autorités de certifications, et chacune d'entre elles peut créer des certificats pour des domaines arbitraires. Si un attaquant est capable de compromettre une seule de ces CA, il peut pratiquer des attaques {{Glossary("MitM")}} sur diverses connections TLS. HPKP peut contourner cette menace pour le protocole HTTPS en disant au client web quelles clés publiques appartiennent à un certain serveur web.</p>
+
+<p>HPKP est une technique qui s'appuie sur la confiance au premier accès (TOFU, <em>Trust on First Use</em>). La première fois un serveur web dit au client en utilisant l'en-tête HTTP HPKP quelles clés publiques lui appartiennent, le client sauvegarde cette information pour une période de temps donnée. Quand le client visite le serveur à nouveau, il s'attend à un certificat contenant une clé publique dont l'empreinte est sauvegardée. Si le serveur présente une clé publique inconnue, le client doit présenter un avertissement à l'utilisateur.</p>
+
+<p class="note">Firefox (and Chrome) <strong>désactivent la vérification de l'épinglage</strong> lorsqu'un site épinglé présentent une chaine de certificats qui se termine par <strong>un certificat racine installé par l'utilisateur</strong> (et non un certificat racine de base).</p>
+
+<h2 id="Activer_HPKP">Activer HPKP</h2>
+
+<p>Activer cette fonctionnalité pour votre site est simple : il faut juste retourner l'en tête HTTP <code>Public-Key-Pins</code> HTTP quand le site est accédé via HTTPS :</p>
+
+<pre>Public-Key-Pins: pin-sha256="base64=="; max-age=<em>expireTime</em> [; includeSubdomains][; report-uri="<em>reportURI"</em>]
+</pre>
+
+<dl>
+ <dt><code>pin-sha256</code></dt>
+ <dd>La chaîne de caractère entre guillemets est l’empreinte du <em>Subject Public Key Information</em> (SPKI) encodé en base 64. Il est possible de spécifier plusieurs épinglage (pin) pour différentes clé publiques. Certains navigateurs pourraient autoriser dans le future d'autres algorithmes de hachage que SHA-256. Voir plus bas comment extraire cette information depuis le fichier d'un certificat ou d'une clé.</dd>
+ <dt><code>max-age</code></dt>
+ <dd>Le temps, en seconde, pendant laquelle le navigateur doit mémoriser que le site ne doit être visité qu'avec l'une des clés épinglées.</dd>
+ <dt><code>includeSubdomains</code> {{ optional_inline() }}</dt>
+ <dd>Si ce paramètre optionnel est spécifié, cette règle s'applique aussi a tous les sous-domaines du domaine actuel.</dd>
+ <dt><code>report-uri</code> {{ optional_inline() }}</dt>
+ <dd>Si ce paramètre optionnel est spécifié, les échecs de validation sont notifiés à l'URL donnée.</dd>
+</dl>
+
+<div class="note">
+<p><strong>Note :</strong> La spécification actuelle <strong>impose</strong> d'inclure au minimum une seconde clé dite de sauvegarde, qui n'est pas encore utilisée en production. Cela permet de changer de clé publique sans bloquer l'accès aux clients qui auraient déjà noté les clés épinglés. C'est important par exemple dans le cas où la clé actuellement utilisées serait compromise, ce qui forcerait l'utilisation d'une clé différente (la clé de sauvegarde dans ce cas).</p>
+</div>
+
+<div class="note">
+<p><strong>Note :</strong> Firefox n'implémente pas encore les rapports de violation d'épinglage. Chrome les implémente à partie de la version 46.</p>
+
+<ul>
+ <li>Firefox: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1091176">Bug 1091176 - Implement report-uri directive for HPKP </a> et <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=787133">Bug 787133 - (hpkp) Implement Public Key Pinning Extension for HTTP (HPKP)</a></li>
+ <li>Chrome: <a href="https://developers.google.com/web/updates/2015/09/HPKP-reporting-with-chrome-46">https://developers.google.com/web/updates/2015/09/HPKP-reporting-with-chrome-46</a> , <a href="https://www.chromestatus.com/feature/4669935557017600">HTTP Public Key Pinning violating reporting</a> et <a href="https://code.google.com/p/chromium/issues/detail?id=445793"> Issue 445793: HPKP Reporting on invalid pins</a></li>
+</ul>
+</div>
+
+<p id="sect1"> </p>
+
+<h3 id="Extraire_la_clé_publique_encodé_en_Base64">Extraire la clé publique encodé en Base64</h3>
+
+<p>En premier, vous devez extraire la clé publique depuis votre fichier de certificats ou de clés puis l'encoder en base 64.</p>
+
+<p>Les commandes suivantes vous aideront à extraire la clé publique et à l'encoder en base 64 depuis le fichier d'une clé, d'un certificat ou d'un CSR (Certificate Signing Request).</p>
+
+<pre><code>openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | </code>openssl enc -base64</pre>
+
+<pre><code>openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | </code>openssl enc -base64</pre>
+
+<pre><code>openssl x509 -in my-certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | </code>openssl enc -base64</pre>
+
+<h3 id="sect2"> </h3>
+
+<h3 id="Exemple_d'entête_HPKP">Exemple d'entête HPKP</h3>
+
+<pre>Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubdomains; report-uri="<em>https://www.example.net/hpkp-report"</em></pre>
+
+<p>Dans cet exemple, <strong>pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="</strong> épingle la clé publique utilisée en production par le serveur. La deuxième déclaration d'épinglage <strong>pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="</strong> représente la clé de sauvegarde. <strong>max-age=5184000</strong> dit au client de mémoriser cette information pendant deux mois, ce qui est un temps raisonnable d'après la RFC. Cet épinglage s'applique aussi à tous les sous-domaines, car <strong>includeSubdomains</strong> est présent. Enfin, <strong>report-uri="https://www.example.net/hpkp-report"</strong> indique où envoyer les rapports d'erreurs de validation.</p>
+
+<p> </p>
+
+<h3 id="Mettre_en_place_le_header_HPKP_sur_votre_serveur_web">Mettre en place le header HPKP sur votre serveur web</h3>
+
+<p>Les étapes concrètes nécessaires pour délivrer l'en-tête HPKP dépendent du serveur web que vous utilisez.</p>
+
+<div class="note">
+<p><strong>Note:</strong> Ces exemples utilisent un a max-age de deux mois et incluent aussi tous les sous-domaines. Il est conseillé de vérifier que cela convient à votre serveur.</p>
+</div>
+
+<p>Inclure une ligne similaire à votre configuration activera HPKP, en remplaçant les valeurs en pointillé des lignes <code>pin-sha256="..." </code>:</p>
+
+<h4 id="Apache">Apache</h4>
+
+<pre>Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
+</pre>
+
+<p><strong>Note :</strong> Cela demande le module <code>mod_headers</code> activé.</p>
+
+<h4 id="Nginx">Nginx</h4>
+
+<pre>add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';</pre>
+
+<p><strong>Note :</strong> Cela demande le module <code>ngx_http_headers_module</code>.</p>
+
+<h4 id="Lighttpd">Lighttpd</h4>
+
+<pre>setenv.add-response-header  = ( "Public-Key-Pins" =&gt; "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")</pre>
+
+<p><strong>Note:</strong> Cela demande le module <code>mod_setenv</code> chargé, ce qui peut être fait en ajoutant la ligne suivante (s'il n'est pas déjà chargé) :</p>
+
+<pre><code>server.modules += ( "mod_setenv" )</code></pre>
+
+<h2 id="sect3"> </h2>
+
+<h2 id="Compatibilité_des_navigateurs">Compatibilité des navigateurs</h2>
+
+<p>{{ CompatibilityTable() }}</p>
+
+<div id="compat-desktop">
+<table class="compat-table">
+ <tbody>
+ <tr>
+ <th>Fonctionnalité</th>
+ <th>Chrome</th>
+ <th>Firefox (Gecko)</th>
+ <th>Internet Explorer</th>
+ <th>Opera</th>
+ <th>Safari</th>
+ </tr>
+ <tr>
+ <td>Basic support</td>
+ <td>{{ CompatChrome("38") }}</td>
+ <td>{{ CompatGeckoDesktop("35") }}</td>
+ <td>{{ CompatNo()}}</td>
+ <td>{{ CompatUnknown() }}</td>
+ <td>{{ CompatUnknown() }}</td>
+ </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+ <tr>
+ <th>Fonctionnalité</th>
+ <th>Chrome pour Android</th>
+ <th>Firefox Mobile (Gecko)</th>
+ <th>IE Mobile</th>
+ <th>Opera Mobile</th>
+ <th>Safari Mobile</th>
+ </tr>
+ <tr>
+ <td>Basic support</td>
+ <td>{{ CompatUnknown() }}</td>
+ <td>{{ CompatGeckoMobile("35") }}</td>
+ <td>{{CompatUnknown()}}</td>
+ <td>{{ CompatUnknown() }}</td>
+ <td>{{ CompatUnknown() }}</td>
+ </tr>
+ </tbody>
+</table>
+</div>
+
+<h2 id="Spécifications">Spécifications</h2>
+
+<ul>
+ <li><a href="https://tools.ietf.org/html/rfc7469">IETF RFC - Public Key Pinning Extension for HTTP</a></li>
+</ul>
+
+<h2 id="Voir_également">Voir également</h2>
+
+<ul>
+ <li><a href="/fr/docs/S%C3%A9curit%C3%A9/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li>
+</ul>
diff --git a/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.html b/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.html
new file mode 100644
index 0000000000..cf4e65ea9b
--- /dev/null
+++ b/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.html
@@ -0,0 +1,56 @@
+---
+title: 'Referer header: privacy and security concerns'
+slug: 'Web/Security/Referer_header:_privacy_and_security_concerns'
+tags:
+ - Privacy
+ - Referrer Policy
+ - Sécurité
+ - referer
+ - referrer
+translation_of: 'Web/Security/Referer_header:_privacy_and_security_concerns'
+---
+<p class="summary">L'<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer">entête HTTP Referer</a> présente des risques de confidentialité et de sécurité<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer">.</a> Cet article les décrit et donne des conseils pour les minimiser.</p>
+
+<h2 id="Le_problème...">Le problème...</h2>
+
+<p><span class="tlid-translation translation" lang="fr"><span title="">L'en-tête </span></span><code>{{httpheader("Referer")}}</code> (sic) <span class="tlid-translation translation" lang="fr"><span title=""> contient l'adresse de la page web précédente lorsqu'un lien vers la page actuelle a été suivi, ce qui offre de nombreuses possibilités légitimes comme l'analyse, la journalisation ou la mise en cache optimisée</span><span title="">. </span><span title="">Cependant, il existe des utilisations plus problématiques telles que le suivi ou le vol d'informations, ou même des effets secondaires tels que la fuite accidentelle d'informations sensibles.</span></span></p>
+
+<p>Par exemple, considérons une page de réinitialisation de mot de passe comportant un lien vers un réseau social dans le pied de page. Si le lien a été suivi, selon la façon dont l’information a été partagée, le réseau social peut recevoir l’URL de réinitialisation du mot de passe et peut toujours être en mesure d’utiliser l’information partagée, ce qui pourrait compromettre la sécurité de l’utilisateur.</p>
+
+<p>Selon la même logique, une image hébergée chez un tiers, mais intégrée à votre page, pourrait entrainer la fuite d'informations sensibles pour le tiers. Même si la sécurité n’est pas compromise, l’information peut ne pas être quelque chose que l’utilisateur veut partager.</p>
+
+<h2 id="Comment_régler_ce_problème">Comment régler ce problème ?</h2>
+
+<p>Une grande partie de ce risque peut être atténuée en concevant de manière adéquate les applications. Une application correctement conçue éliminerait ces risques en ne donnant la possibilité d'utiliser qu'une seule fois les URLs de réinitialisation, ou en associant ces URLs à un jeton utilisateur unique, et en transmettant les données sensibles par différents moyens.</p>
+
+<p>Vous devez utiliser <code>POST</code> plutôt que <code>GET</code> dans la mesure du possible, pour éviter de transmettre des données sensibles à d’autres emplacements via des URL.</p>
+
+<p>Vous devriez toujours utiliser <code>{{glossary("HTTPS")}}</code> pour vos sites. Cela présente de nombreux avantages en matière de sécurité, y compris le fait que les sites HTTPS ne transmettent jamais le "referer" à des sites non-HTTPS. C'est aujourd'hui de moins en moins nécessaire maintenant que la plupart des sites Web utilisent HTTPS, mais cela reste malgré tout un élément à prendre en compte.</p>
+
+<p>De plus, vous devriez envisager de supprimer tout contenu provenant d'un tiers (ex., les widgets de réseautage social inclus dans des <code>{{htmlelement("iframe")}})</code> des zones sécurisées de vos sites Web, comme les pages de réinitialisation de mots de passe, les formulaires de paiement, les interfaces de connexion, etc.</p>
+
+<p>Vous pouvez également atténuer ces risques en utilisant :</p>
+
+<ul>
+ <li>L’en-tête <code>{{httpheader("Referrer-Policy")}}</code> sur votre serveur pour contrôler quelle information est envoyée par l’en-tête <code>Referer</code>. Encore une fois, une directive <code>no-referrer</code> omettrait intégralement l’en-tête <code>Referer</code>.</li>
+ <li>L’attribut <code>referrerpolicy</code> sur les éléments HTML qui présentent des risques de fuite d'informations (comme <code>&lt;img&gt;</code> et <code>&lt;a&gt;</code>). Cet attribut peut prendre par exemple la valeur  <code>no-referrer</code> afin d'empêcher l'envoi de l’en-tête <code>Referer</code>.</li>
+ <li>L’attribut <code>rel</code> défini à <code>noreferrer</code> sur les éléments HTML à risques (comme <code>&lt;img&gt;</code> et &lt;a&gt;). Voir Types de liens et rechercher <code>noreferrer</code> pour plus d’informations.</li>
+ <li>La technique de la <a href="https://geekthis.net/post/hide-http-referer-headers/#exit-page-redirect">page de sortie</a>.</li>
+</ul>
+
+<p>Les frameworks soucieux de la sécurité employés côté serveur ont tendance à inclure d'emblée des mesures d’atténuation pour résoudre ces problèmes, par exemple :</p>
+
+<ul>
+ <li>La sécurité dans Django (voir notamment Cross Site Request Forgery (CSRF) protection).</li>
+ <li>helmet referrer-policy — middleware pour configurer l'entête Referrer-Policy dans les applications Node.js/Express (voir aussi helmet pour plus d'aménagements liés à la sécurité).</li>
+</ul>
+
+<h2 id="Politique_et_exigences.">Politique et exigences.</h2>
+
+<p>Il serait pertinent de rédiger pour votre (vos) équipe(s) de projet un ensemble d’exigences en matière de sécurité et de protection des renseignements personnels en en précisant l’utilisation dans le cadre de l'atténuation des risques. Vous devriez demander l’aide d’un expert en sécurité Web pour rédiger ces exigences en tenant compte à la fois des besoins et du bien-être des utilisateurs, ainsi que d’autres questions liées à la législation et la réglementation comme le <a href="https://ec.europa.eu/info/law/law-topic/data-protection/eu-data-protection-rules_fr">Réglement Général à la Protection des Données de l'Union Européenne</a>.</p>
+
+<h2 id="Voir_aussi">Voir aussi</h2>
+
+<ul>
+ <li><a href="https://infosec.mozilla.org/guidelines/web_security.html#referrer-policy">Lignes directrices de l'équipe de sécurité de Mozilla sur Referrer-Policy</a></li>
+</ul>
diff --git a/files/fr/web/security/same_origin_policy_for_javascript/index.html b/files/fr/web/security/same_origin_policy_for_javascript/index.html
new file mode 100644
index 0000000000..bcbdbe613f
--- /dev/null
+++ b/files/fr/web/security/same_origin_policy_for_javascript/index.html
@@ -0,0 +1,115 @@
+---
+title: Same-origin policy
+slug: Web/Security/Same_origin_policy_for_JavaScript
+translation_of: Web/Security/Same-origin_policy
+---
+<p>La same-origin policy restreint la manière dont un document ou un script chargé depuis une origine peut interagir avec une autre ressource chargée depuis une autre origine.</p>
+
+<h2 id="Définition_de_lorigine">Définition de l'origine</h2>
+
+<p>Deux pages ont la même origine si le protocole, le port (si spécifié) et l'hôte sont les mêmes pour les deux pages. Le tableau suivant présente des comparaisons d'origines pour l'URL <code><span class="nowiki">http://store.company.com/dir/page.html</span></code>:</p>
+
+<table class="standard-table">
+ <tbody>
+ <tr>
+ <th>URL</th>
+ <th>Résultat</th>
+ <th>Motif</th>
+ </tr>
+ <tr>
+ <td><code><span class="nowiki">http://store.company.com/dir2/other.html</span></code></td>
+ <td>Succès</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code><span class="nowiki">http://store.company.com/dir/inner/another.html</span></code></td>
+ <td>Succès</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code><span class="nowiki">https://store.company.com/secure.html</span></code></td>
+ <td>Échec</td>
+ <td>Protocoles différents</td>
+ </tr>
+ <tr>
+ <td><code><span class="nowiki">http://store.company.com:81/dir/etc.html</span></code></td>
+ <td>Échec</td>
+ <td>Port différents</td>
+ </tr>
+ <tr>
+ <td><code><span class="nowiki">http://news.company.com/dir/other.html</span></code></td>
+ <td>Échec</td>
+ <td>Hôtes différents</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Voir aussi <a href="/en-US/docs/Same-origin_policy_for_file:_URIs" title="/en-US/docs/Same-origin_policy_for_file:_URIs">origin definition for <code>file:</code> URLs</a>.</p>
+
+<p>Les cookies utilisent une définition de l'origine différente de celle qui vient d'être définie.</p>
+
+<h2 id="Changer_lorigine">Changer l'origine</h2>
+
+<p>Une page peut changer son origine dans une certaine mesure. Un script peut définir la valeur de <code><a href="/en/DOM/document.domain" title="en/DOM/document.domain">document.domain</a> </code>vers un suffixe du domaine courant. S'il procéde ainsi, le domaine le plus court sera utilisé pour les prochaines vérifications d'origines. Par exemple, un script dans la page <code><span class="nowiki">http://store.company.com/dir/other.html</span></code> exécute le code suivant :</p>
+
+<pre class="eval">document.domain = "company.com";
+</pre>
+
+<p>Après l'exécution de ce code, la page passerait le test d'origine avec <code><span class="nowiki">http://company.com/dir/page.html</span></code>. Ceci-dit, il ne serait pas possible de définir <code>document.domain</code> à <code>othercompany.com</code>.</p>
+
+<p>Le numéro de port est stocké par le navigateur séparément. Tout appel aux setter, y compris <code>document.domain = document.domain </code>entraîne l'effacement du port par la valeur <code>null</code>. Une page située sur <code>company.com:8080 </code>ne peut donc pas communiquer avec une autre située sur <code>company.com </code>en ne définissant que <code>document.domain = "company.com"</code> dans la première page. Ceci doit être fait dans les deux pages, ainsi les ports seront à <code>null </code>pour les deux.</p>
+
+<h2 id="Accès_réseau_cross-origin">Accès réseau cross-origin</h2>
+
+<p>La same-origin policy contrôle les interactions entre deux origines différentes, quand vous utilisez <code><a href="/en-US/docs/DOM/XMLHttpRequest" title="/en-US/docs/DOM/XMLHttpRequest">XMLHttpRequest</a> </code>par exemple. Ces interactions sont généralement rangées dans trois catégories :</p>
+
+<ul>
+ <li><em>Écritures </em>cross-origin généralement autorisées. Par exemple, les liens, les redirections ou les envois de formulaires. Quelques rares requêtes HTTP nécessitent <a href="/en-US/docs/HTTP/Access_control_CORS#Preflighted_requests" title="/en-US/docs/HTTP/Access_control_CORS#Preflighted_requests">preflight</a>.</li>
+ <li><em>Embarqué </em>cross-origin généralement autorisé. Les exemples sont listés ci-après.</li>
+ <li><em>Lectures </em>cross-origin généralement non autorisées.</li>
+</ul>
+
+<p>Voici quelques exemples de ressources qui peuvent être embarqués malgré leur origine incomptatible avec la same-origin policy :</p>
+
+<ul>
+ <li>JavaScript avec <code>&lt;script src="..."&gt;&lt;/script&gt;</code>. Les messages d'erreur de syntaxe ne sont disponibles que pour les script ayant la même origine.</li>
+ <li>CSS avec<code> &lt;link rel="stylesheet" href="..."&gt;</code>. Étant donnée la <a href="http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html" title="http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html">souplesse des règles de syntaxe</a> du CSS, les CSS d'origine différentes nécessitent une entête <code>Content-Type</code> correcte. Les restrictions varient selon les navigateurs : <a href="http://msdn.microsoft.com/en-us/library/ie/gg622939%28v=vs.85%29.aspx" title="http://msdn.microsoft.com/en-us/library/ie/gg622939%28v=vs.85%29.aspx">IE</a>, <a href="http://www.mozilla.org/security/announce/2010/mfsa2010-46.html" title="http://www.mozilla.org/security/announce/2010/mfsa2010-46.html">Firefox</a>, <a href="http://code.google.com/p/chromium/issues/detail?id=9877" title="http://code.google.com/p/chromium/issues/detail?id=9877">Chrome</a>, <a href="http://support.apple.com/kb/HT4070" title="http://support.apple.com/kb/HT4070">Safari</a> et <a href="http://www.opera.com/support/kb/view/943/" title="http://www.opera.com/support/kb/view/943/">Opera</a>.</li>
+ <li>Images avec <a href="/en-US/docs/HTML/Element/Img" title="/en-US/docs/HTML/Element/Img"><code>&lt;img&gt;</code></a>. Les formats d'image supportés, comprenant PNG, JPEG, GIF, BMP, SVG, ...</li>
+ <li>Fichiers média avec <a href="/en-US/docs/HTML/Element/video" title="/en-US/docs/HTML/Element/video"><code>&lt;video&gt;</code></a> et <a href="/en-US/docs/HTML/Element/audio" title="/en-US/docs/HTML/Element/audio"><code>&lt;audio&gt;</code></a>.</li>
+ <li>Plug-ins avec <a href="/en-US/docs/HTML/Element/object" title="/en-US/docs/HTML/Element/object"><code>&lt;object&gt;</code></a>, <a href="/en-US/docs/HTML/Element/embed" title="/en-US/docs/HTML/Element/embed"><code>&lt;embed&gt;</code></a> et <a href="/en-US/docs/HTML/Element/applet" title="/en-US/docs/HTML/Element/applet"><code>&lt;applet&gt;</code></a>.</li>
+ <li>Fonts avec <a href="/en-US/docs/CSS/@font-face" title="/en-US/docs/CSS/@font-face"><code>@font-face</code></a>. Certain navigateurs autorisent les fonts cross-origin, d'autres appliquent la same-origin policy pour les fonts.</li>
+ <li>N'importe quoi avec <a href="/en-US/docs/HTML/Element/frame" title="/en-US/docs/HTML/Element/frame"><code>&lt;frame&gt;</code></a> et <a href="/en-US/docs/HTML/Element/iframe" title="/en-US/docs/HTML/Element/iframe"><code>&lt;iframe&gt;</code></a>. Un site peut utiliser l'entête<code><a href="/en-US/docs/HTTP/X-Frame-Options" title="/en-US/docs/HTTP/X-Frame-Options"> X-Frame-Options</a></code> pour interdire cela depuis une page n'ayant pas la même origine.</li>
+</ul>
+
+<h3 id="Autoriser_laccès_cross-origin">Autoriser l'accès cross-origin</h3>
+
+<p>Utiliser <a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">CORS</a> pour autoriser l'accès cross-origin.</p>
+
+<h3 id="Comment_bloquer_laccès_cross-origin_access">Comment bloquer l'accès cross-origin access</h3>
+
+<ul>
+ <li>Pour interdire les écritures cross-origin writes, contrôlez dans la requête un token qui ne peut être déviné, connu sous le nom de <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29" title="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">Cross-Site Request Forgery (CSRF)</a> token, et interdisez la lecture cross-origin des pages qui conaissent ce token.</li>
+ <li>Pour interdire la lecture cross-origin d'une ressource, assurez-vous qu'elle ne peut pas être embarquée.</li>
+ <li>Pour interdire l'embarquement (embed) d'une ressource cross-origin, assurez vous qu'elle ne peut pas être interprétée comme une des ressources embarquable vues précédemment. Dans la plupart des cas, les navigateurs ne respectent pas le<code> Content-Type</code>. Par exemple, pour un tag <code>&lt;script&gt;</code> pointant un document HTML, le navigateur va tenter de parser le HTML comme du JavaScript. Si votre ressource n'est pas un point d'entrée de votre site, vous pouvez également utiliser une token CSRF.</li>
+</ul>
+
+<h2 id="Accès_script_cross-origin">Accès script cross-origin</h2>
+
+<p>Les APIs JavaScript comme <a href="/en-US/docs/DOM/HTMLIFrameElement" title="/en-US/docs/DOM/HTMLIFrameElement"><code>iframe.contentWindow</code></a>, <a href="/en-US/docs/DOM/window.parent" title="/en-US/docs/DOM/window.parent"><code>window.parent</code></a>, <a href="/en-US/docs/DOM/window.open" title="/en-US/docs/DOM/window.open"><code>window.open</code></a> et <a href="/en-US/docs/DOM/window.opener" title="/en-US/docs/DOM/window.opener"><code>window.opener</code></a> autorisent les documents à se référencer directement entre eux. Quand deux documents n'ont pas la même origine, ces références fournissent des accès limités aux objets <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window" title="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window">Window</a> et <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location" title="http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location">Location</a>.  Certains navigateurs <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=839867" title="https://bugzilla.mozilla.org/show_bug.cgi?id=839867">permettent l'accès à plus de propriétés</a> que ce que les spécifications permettent. A la place, vous pouvez utiliser<code><a href="/en-US/docs/DOM/window.postMessage" title="/en-US/docs/DOM/window.postMessage"> window.postMessage</a></code> pour communiquer entre deux documents.</p>
+
+<h2 id="Voir_aussi">Voir aussi</h2>
+
+<ul>
+ <li><a href="/en/Same-origin_policy_for_file:_URIs" title="En/Same-origin policy for file: URIs">Same-origin policy for file: URIs</a></li>
+ <li><a href="http://www.w3.org/Security/wiki/Same_Origin_Policy" title="http://www.w3.org/Security/wiki/Same_Origin_Policy">Same-Origin Policy at W3C</a></li>
+</ul>
+
+<div class="originaldocinfo">
+<h2 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h2>
+
+<ul>
+ <li>Author(s): Jesse Ruderman</li>
+</ul>
+</div>
+
+<div class="noinclude">{{ languages( {"ja": "Ja/Same_origin_policy_for_JavaScript", "zh-cn": "Cn/JavaScript的同源策略"} ) }}</div>
diff --git a/files/fr/web/security/secure_contexts/index.html b/files/fr/web/security/secure_contexts/index.html
new file mode 100644
index 0000000000..652438d274
--- /dev/null
+++ b/files/fr/web/security/secure_contexts/index.html
@@ -0,0 +1,154 @@
+---
+title: Secure Contexts
+slug: Web/Security/Secure_Contexts
+translation_of: Web/Security/Secure_Contexts
+---
+<p>Un navigateur entre dans un <strong>contexte sécurisé</strong> quand il a satisfait les exigences minimale de sécurité. Un contexte sécurisé permet au navigateur de mettre à disposition des APIs qui nécessitent des transferts sécurisés avec l'utilisateur.</p>
+
+<p> </p>
+
+<h2 id="Pourquoi_certaines_fonctionnalitées_devraient_être_limitées">Pourquoi certaines fonctionnalitées devraient être limitées ?</h2>
+
+<p>Certaines APIs du web peuvent donner beaucoup de pouvoir à un attaqueur, lui permettant par exemple:</p>
+
+<ul>
+ <li>Entrer dans la vie privée d'un utilisateur.</li>
+ <li>Avoir accès à l'ordinateur d'un utilisateur.</li>
+ <li>Avoir accès à des données (comme l'identité de l'utilisateur).</li>
+</ul>
+
+<h2 id="À_quel_moment_un_context_est-il_considéré_comme_sécurisé">À quel moment un context est-il considéré comme sécurisé ?</h2>
+
+<p>Un contexte sera considéré comme sécurisé s'il est servi locallement, ou depuis un serveur sécurisé. Un contexte qui n'est pas à la racine (une page qui n'est pas dans une fenêtre, iframe, ...) doit avoir tous ses contextes parents sécurisés.</p>
+
+<p>Les fichiers servis locallement avec des chemins comme <em>http://localhost</em> et <em>file://</em> sont considérés sécurisés.</p>
+
+<p>Les contextes qui ne sont pas servis locallement doivent être servis avec <em>https://</em> ou <em>wss:// </em>et les protocoles utilisés ne doivent pas être considérés obsolètes.</p>
+
+<h2 id="Détection_des_fonctionnalités">Détection des fonctionnalités</h2>
+
+<p>Les pages peuvent utiliser la détection de fonctionnalités pour vérifier si elles sont dans un context sécurisé ou non en utilisant le booléen <code>isSecureContext </code>qui est présent dans le scope global.</p>
+
+<pre class="brush: js">if (window.isSecureContext) {
+  // La page est dans un contexte sécurisé, les services workers sont disponibles.
+ navigator.serviceWorker.register("/offline-worker.js").then(function () {
+ ...
+ });
+}</pre>
+
+<h2 id="Quelles_APIs_requièrent_un_contexte_sécurisé">Quelles APIs requièrent un contexte sécurisé ?</h2>
+
+<ul>
+ <li>{{SpecName('Service Workers')}}</li>
+ <li>{{SpecName('Web Bluetooth')}}</li>
+ <li>{{SpecName('EME')}}</li>
+</ul>
+
+<h3 id="Prositions_de_brouillons">Prositions de brouillons</h3>
+
+<ul>
+ <li><a href="https://w3c.github.io/sensors/">https://w3c.github.io/sensors/</a></li>
+ <li><a href="https://w3c.github.io/webappsec-credential-management/">https://w3c.github.io/webappsec-credential-management/</a></li>
+ <li><a href="https://w3c.github.io/geofencing-api/">https://w3c.github.io/geofencing-api/</a></li>
+ <li><a href="https://w3c.github.io/web-nfc/releases/20150925/">https://w3c.github.io/web-nfc/releases/20150925/</a></li>
+</ul>
+
+<h3 id="Navigateurs">Navigateurs</h3>
+
+<p>Certains navigateurs peuvent décider de demander à certaines APIs d'être dans un contexte sécurisé même si la spécification ne le demande pas.</p>
+
+<table class="standard-table">
+ <tbody>
+ <tr>
+ <td> </td>
+ <td>Chrome</td>
+ <td>Safari</td>
+ <td>Firefox</td>
+ </tr>
+ <tr>
+ <td>getUserMedia</td>
+ <td>
+ <p>Désactivé</p>
+
+ <p><a href="https://codereview.chromium.org/1336633002">Supprimé dans Chrome 47</a></p>
+ </td>
+ <td> </td>
+ <td>
+ <p>Accès temporaire uniquement (les utilisateurs ne peuvent pas choisir "Retenir ce choix" dans la selection de permission).</p>
+ </td>
+ </tr>
+ <tr>
+ <td>Geolocation</td>
+ <td>
+ <p>Désactivé</p>
+
+ <p><a href="https://codereview.chromium.org/1530403002/">Supprimé dans Chrome 50</a></p>
+ </td>
+ <td>
+ <p>Désactivé</p>
+
+ <p><a href="https://trac.webkit.org/changeset/200686">Suppression ici</a></p>
+ </td>
+ <td>
+ <p>Suppression en cours</p>
+
+ <p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1072859">Suppression attendue pour Firefox 55</a></p>
+ </td>
+ </tr>
+ <tr>
+ <td>EME</td>
+ <td>Avertissement de dépréciation</td>
+ <td> </td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>Device motion / orientation</td>
+ <td>Avertissement de dépréciation</td>
+ <td> </td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>MIDI</td>
+ <td>Désactivé</td>
+ <td> </td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td><em>{{SpecName('Web Crypto API')}}</em></td>
+ <td><em>est réservé à HTTPS même is la vérification du Secure Context est antérieur</em></td>
+ <td> </td>
+ <td> </td>
+ </tr>
+ </tbody>
+</table>
+
+<p>Pour vérifier le support de votre navigateur, utilisez le site: http://permission.site</p>
+
+<p><em>Note: Safari et Chrome ne supportent pas complètement la spécification des Secure Contexts, certaines APIs peuvent fonctionner avec des iframes utilisant du HTTPS dans une page utilisant du HTTP ou dans une page qui a un contexte ouvert avec une page non sécurisée (c'est le cas quand une page utilisant du HTTP utilise window.open ou target="_blank").</em></p>
+
+<h2 id="Spécifications">Spécifications</h2>
+
+<table class="standard-table">
+ <tbody>
+ <tr>
+ <td>Spécification</td>
+ <td>État</td>
+ <td>Commentaire</td>
+ </tr>
+ <tr>
+ <td>{{SpecName('Secure Contexts')}}</td>
+ <td>{{Spec2('Secure Contexts')}}</td>
+ <td>Brouillon</td>
+ </tr>
+ </tbody>
+</table>
+
+<p> </p>
+
+<h2 id="Voir_aussi">Voir aussi</h2>
+
+<p> </p>
+
+<ul>
+ <li>{{domxref("Window.isSecureContext")}}</li>
+</ul>
diff --git a/files/fr/web/security/subresource_integrity/index.html b/files/fr/web/security/subresource_integrity/index.html
new file mode 100644
index 0000000000..65e78ef12f
--- /dev/null
+++ b/files/fr/web/security/subresource_integrity/index.html
@@ -0,0 +1,147 @@
+---
+title: Subresource Integrity
+slug: Web/Security/Subresource_Integrity
+tags:
+ - Intro
+ - Sécurité
+translation_of: Web/Security/Subresource_Integrity
+---
+<p><em><strong>Subresource Integrity</strong></em> (SRI, ou « Intégrité des sous-ressources ») est une fonction de sécurité qui permet aux navigateurs de vérifier que les fichiers qu'ils vont chercher (par exemple, à partir d'un <a href="/fr/docs/Glossaire/CDN">CDN</a>) sont livrés sans manipulation inattendue. Cela fonctionne en permettant de fournir un hachage cryptographique (« <em>hash</em> ») auquel le fichier récupéré doit correspondre.</p>
+
+<h2 id="Comment_fonctionne_le_contrôle_d'intégrité_des_sous-ressources">Comment fonctionne le contrôle d'intégrité des sous-ressources ?</h2>
+
+<p>Utiliser un <a href="/en-US/docs/Glossary/CDN">CDN</a> pour héberger des fichiers tels que les scripts et les feuilles de style qui sont partagés entre plusieurs sites permet d'améliorer les performances du site et d'économiser de la bande passante. Cependant, utiliser des CDN comporte un risque : si un attaquant prend le contrôle du CDN, il pourra injecter du contenu malveillant dans les fichiers (ou les remplacer complètement), et il pourra donc aussi potentiellement attaquer tous les sites qui récupèrent les fichiers sur ce CDN.</p>
+
+<p>Le contrôle d'intégrité des sous-ressources vous permet d'atténuer le risque de ce genre d'attaques, en veillant à ce que les fichiers de votre application ou document Web utilisent (à partir d'un CDN ou ailleurs) aient été livrés sans modification d'un tiers ayant injecté du contenu supplémentaire dans les fichiers - et sans autre changement de toute nature ayant été faits à ces fichiers.</p>
+
+<h2 id="Utiliser_le_SRI">Utiliser le SRI</h2>
+
+<p>Le contrôle d'intégrité des sous-ressources s'active en spécifiant un hachage cryptographique encodé en base64 d'une ressource (fichier) que vous transmettez au navigateur au moment où il va chercher cette ressource, comme valeur de l'attribut <code><strong>integrity</strong></code> de chaque élément {{HTMLElement("script")}} ou {{HTMLElement("link")}}.</p>
+
+<p>Une valeur de l'attribut <code><strong>integrity</strong></code> commence par au moins une chaîne, chaque chaîne comprenant un préfixe indiquant un algorithme particulier de hachage (actuellement les préfixes autorisés sont <code>sha256</code>, <code>sha384</code> et <code>sha512</code>), suivi d'un tiret, et se terminant par le hachage base64 proprement dit.</p>
+
+<div class="note">
+<p><strong>Note : </strong>Une valeur de l'attribut <code><strong>integrity</strong></code> peut contenir plusieurs hachages séparés par des espaces. Une ressource sera chargée si elle correspond à l'un de ces hachages.</p>
+</div>
+
+<p>Voici un exemple de valeur pour l'attribut <code><strong>integrity</strong></code> avec un hash sha384 encodé en base64 :</p>
+
+<pre>sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
+</pre>
+
+<div class="note">
+<p><strong>Note :</strong> Le « <em>hash</em> » est à proprement parler une <strong><em>fonction de hachage cryptographique</em></strong> formé en appliquant une fonction de hachage particulière à une certaine entrée (par exemple, un script ou un fichier de feuille de styles). Mais il est plus commun d'utiliser le mot <strong><em>hash</em></strong> pour indiquer <em>fonction de hachage cryptographique</em>, d'où son utilisation dans cet article.</p>
+</div>
+
+<h3 id="Outil_pour_générer_des_hachages_SRI">Outil pour générer des hachages SRI</h3>
+
+<p>Vous pouvez générer des <em>hashes</em> SRI en ligne de commande avec OpenSSL en utilisant une commande de ce genre :</p>
+
+<pre class="brush: bash">cat <strong>FILENAME.js</strong> | openssl dgst -sha384 -binary | openssl enc -base64 -A</pre>
+
+<p>Il existe également, <strong>SRI Hash Generator</strong> : <a href="https://srihash.org/">https://srihash.org/</a> qui est un utilitaire en ligne permettant de générer des <em>hashes</em> SRI. </p>
+
+<h2 id="Exemples">Exemples</h2>
+
+<p>Dans les exemples suivants, supposons que <code>oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC</code> est la valeur attendue du <em>hash</em> SHA-384 d'un script <code>exemple-framework.js</code>, et qu'il existe une copie de ce script hébergée sur <code>https://exemple.com/exemple-framework.js</code>.</p>
+
+<h3 id="Exemple_utiliser_l'élément_script_pour_le_contrôle_d'intégrité">Exemple : utiliser l'élément <code>script</code> pour le contrôle d'intégrité</h3>
+
+<p>Vous pouvez utiliser l'élément {{HTMLElement("script")}} suivant pour dire au navigateur qu'il doit comparer le <em>hash</em> fourni avec celui du fichier et que les deux correspondent avant d'exécuter le script hébergé à <code>https://example.com/exemple-framework.js</code>.</p>
+
+<pre class="brush: html">&lt;script src="https://exemple.com/exemple-framework.js"
+ integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
+ crossorigin="anonymous"&gt;&lt;/script&gt;</pre>
+
+<div class="note">
+<p><strong>Note :</strong> Pour plus de détails sur l'objectif de l'attribut <code><strong>crossorigin</strong></code>, voir <a href="/fr/docs/Web/HTML/Reglages_des_attributs_CORS">les attributs CORS</a>.</p>
+</div>
+
+<h2 id="La_gestion_du_SRI_par_les_navigateurs">La gestion du SRI par les navigateurs</h2>
+
+<p>Les navigateurs gèrent SRI en effectuant les étapes suivantes :</p>
+
+<ol>
+ <li>Lorsqu'un navigateur rencontre un élément {{HTMLElement("script")}} ou {{HTMLElement("link")}} avec un attribut <code><strong>integrity</strong></code>, avant d'exécuter le script ou avant d'appliquer les styles spécifiés par l'élément {{HTMLElement("link")}}, la navigateur doit comparer le script ou la feuille de style à la valeur donnée dans l'attribut <code><strong>integrity</strong></code>.</li>
+ <li>Si le script ou la feuille de styles ne correspond pas à la valeur de l'attribut <code><strong>integrity</strong></code> qui lui est associée, alors le navigateur doit refuser d'exécuter le script ou d'appliquer la feuille de style et doit retourner une erreur indiquant que le chargement de la ressource a échoué.</li>
+</ol>
+
+<h2 id="Spécifications">Spécifications</h2>
+
+<table class="standard-table">
+ <tbody>
+ <tr>
+ <th scope="col">Spécification</th>
+ <th scope="col">État</th>
+ <th scope="col">Commentaires</th>
+ </tr>
+ <tr>
+ <td>{{SpecName('Subresource Integrity')}}</td>
+ <td>{{Spec2('Subresource Integrity')}}</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>{{SpecName('Fetch')}}</td>
+ <td>{{Spec2('Fetch')}}</td>
+ <td> </td>
+ </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilité_des_navigateurs">Compatibilité des navigateurs</h2>
+
+<p>{{CompatibilityTable}}</p>
+
+<div id="compat-desktop">
+<table class="compat-table">
+ <tbody>
+ <tr>
+ <th>Fonctionnalité</th>
+ <th>Chrome</th>
+ <th>Firefox (Gecko)</th>
+ <th>Internet Explorer</th>
+ <th>Opera</th>
+ <th>Safari</th>
+ </tr>
+ <tr>
+ <td>L'attribut <code>integrity</code> pour les éléments <code>&lt;script&gt;</code> et <code>&lt;link&gt;</code></td>
+ <td>{{CompatChrome("45.0")}}</td>
+ <td>{{CompatGeckoDesktop("43")}}</td>
+ <td>{{CompatNo}}</td>
+ <td>{{CompatOpera("32")}}</td>
+ <td>{{CompatNo}}[1]</td>
+ </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+ <tr>
+ <th>Fonctionnalité</th>
+ <th>Chrome pour Android</th>
+ <th>Firefox Mobile (Gecko)</th>
+ <th>IE Mobile</th>
+ <th>Opera Mobile</th>
+ <th>Safari Mobile</th>
+ </tr>
+ <tr>
+ <td>L'attribut <code>integrity</code> pour les éléments <code>&lt;script&gt;</code> et <code>&lt;link&gt;</code></td>
+ <td>{{CompatChrome("45.0")}}</td>
+ <td>{{CompatGeckoMobile("43")}}</td>
+ <td>{{CompatNo}}</td>
+ <td>{{CompatNo}}</td>
+ <td>{{CompatNo}}[1]</td>
+ </tr>
+ </tbody>
+</table>
+</div>
+
+<p>[1] {{WebKitBug(148363)}}</p>
+
+<h2 id="Voir_aussi">Voir aussi</h2>
+
+<ul>
+ <li><a href="https://frederik-braun.com/using-subresource-integrity.html" id="page-title">Un CDN sans risque de XSS : utiliser le contrôle d'intégrité des sous-ressources (en anglais)</a></li>
+</ul>