convert content to md

5 files changed, 271 insertions, 326 deletions

diff --git a/files/fr/web/security/index.md b/files/fr/web/security/index.md
index edfcb443d5..59b6db97fb 100644
--- a/files/fr/web/security/index.md
+++ b/files/fr/web/security/index.md
@@ -7,17 +7,14 @@ tags:
   - Web
 translation_of: Web/Security
 ---
-<p>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.</p>
-</div>
+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.
 
-<p>{{LandingPageListSubpages}}</p>
+{{LandingPageListSubpages}}
 
-<h2 id="Voir_aussi">Voir aussi</h2>
+## Voir aussi
 
-<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>
+- [Liste de diffusion (_mailing list_) (en anglais)](https://lists.mozilla.org/listinfo/dev-security)
+- [Blog](https://blog.mozilla.com/security/)
+- [@mozsec on Twitter](https://twitter.com/mozsec)
 
-<p>{{QuickLinksWithSubpages}}</p>
+{{QuickLinksWithSubpages}}
diff --git a/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.md b/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.md
index 0720f09854..c69dcb0859 100644
--- a/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.md
+++ b/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.md
@@ -1,56 +1,50 @@
 ---
 title: 'Referer header: privacy and security concerns'
-slug: 'Web/Security/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'
+translation_of: Web/Security/Referer_header:_privacy_and_security_concerns
 ---
-<p>L'<a href="/fr/docs/Web/HTTP/Headers/Referer">entête HTTP Referer</a> présente des risques de confidentialité et de sécurité<a href="/fr/docs/Web/HTTP/Headers/Referer">.</a> Cet article les décrit et donne des conseils pour les minimiser.</p>
+L'[entête HTTP Referer](/fr/docs/Web/HTTP/Headers/Referer) présente des risques de confidentialité et de sécurité[.](/fr/docs/Web/HTTP/Headers/Referer) Cet article les décrit et donne des conseils pour les minimiser.
 
-<h2 id="Le_problème...">Le problème...</h2>
+## Le problème...
 
-<p>L'en-tête <code>{{httpheader("Referer")}}</code> (sic)  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. 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.</p>
+L'en-tête `{{httpheader("Referer")}}` (sic) 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. 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.
 
-<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>
+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>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>
+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.
 
-<h2 id="Comment_régler_ce_problème">Comment régler ce problème ?</h2>
+## Comment régler ce problème ?
 
-<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>
+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>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>
+Vous devez utiliser `POST` plutôt que `GET` dans la mesure du possible, pour éviter de transmettre des données sensibles à d’autres emplacements via des URL.
 
-<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>
+Vous devriez toujours utiliser `{{glossary("HTTPS")}}` 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>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>
+De plus, vous devriez envisager de supprimer tout contenu provenant d'un tiers (ex., les widgets de réseautage social inclus dans des `{{htmlelement("iframe")}})` 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>Vous pouvez également atténuer ces risques en utilisant :</p>
+Vous pouvez également atténuer ces risques en utilisant :
 
-<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>
+- L’en-tête `{{httpheader("Referrer-Policy")}}` sur votre serveur pour contrôler quelle information est envoyée par l’en-tête `Referer`. Encore une fois, une directive `no-referrer` omettrait intégralement l’en-tête `Referer`.
+- L’attribut `referrerpolicy` sur les éléments HTML qui présentent des risques de fuite d'informations (comme `<img>` et `<a>`). Cet attribut peut prendre par exemple la valeur  `no-referrer` afin d'empêcher l'envoi de l’en-tête `Referer`.
+- L’attribut `rel` défini à `noreferrer` sur les éléments HTML à risques (comme `<img>` et \<a>). Voir Types de liens et rechercher `noreferrer` pour plus d’informations.
+- La technique de la [page de sortie](https://geekthis.net/post/hide-http-referer-headers/#exit-page-redirect).
 
-<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>
+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 :
 
-<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>
+- La sécurité dans Django (voir notamment Cross Site Request Forgery (CSRF) protection).
+- 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é).
 
-<h2 id="Politique_et_exigences.">Politique et exigences.</h2>
+## Politique et exigences.
 
-<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>
+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 [Réglement Général à la Protection des Données de l'Union Européenne](https://ec.europa.eu/info/law/law-topic/data-protection/eu-data-protection-rules_fr).
 
-<h2 id="Voir_aussi">Voir aussi</h2>
+## Voir aussi
 
-<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>
+- [Lignes directrices de l'équipe de sécurité de Mozilla sur Referrer-Policy](https://infosec.mozilla.org/guidelines/web_security.html#referrer-policy)
diff --git a/files/fr/web/security/same-origin_policy/index.md b/files/fr/web/security/same-origin_policy/index.md
index 7dd82934f7..fa7fc96871 100644
--- a/files/fr/web/security/same-origin_policy/index.md
+++ b/files/fr/web/security/same-origin_policy/index.md
@@ -4,103 +4,67 @@ slug: Web/Security/Same-origin_policy
 translation_of: Web/Security/Same-origin_policy
 original_slug: Web/Security/Same_origin_policy_for_JavaScript
 ---
-<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>http://store.company.com/dir/page.html</code> :</p>
-
-<table class="standard-table">
- <tbody>
-  <tr>
-   <th>URL</th>
-   <th>Résultat</th>
-   <th>Motif</th>
-  </tr>
-  <tr>
-   <td><code>http://store.company.com/dir2/other.html</code></td>
-   <td>Succès</td>
-   <td></td>
-  </tr>
-  <tr>
-   <td><code>http://store.company.com/dir/inner/another.html</code></td>
-   <td>Succès</td>
-   <td></td>
-  </tr>
-  <tr>
-   <td><code>https://store.company.com/secure.html</code></td>
-   <td>Échec</td>
-   <td>Protocoles différents</td>
-  </tr>
-  <tr>
-   <td><code>http://store.company.com:81/dir/etc.html</code></td>
-   <td>Échec</td>
-   <td>Ports différents</td>
-  </tr>
-  <tr>
-   <td><code>http://news.company.com/dir/other.html</code></td>
-   <td>Échec</td>
-   <td>Hôtes différents</td>
-  </tr>
- </tbody>
-</table>
-
-<p>Voir aussi <a href="/fr/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">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>http://store.company.com/dir/other.html</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>http://company.com/dir/page.html</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> entraine 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="/fr/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="/fr/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 incompatible 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 scripts 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">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">IE</a>, <a href="http://www.mozilla.org/security/announce/2010/mfsa2010-46.html">Firefox</a>, <a href="http://code.google.com/p/chromium/issues/detail?id=9877">Chrome</a>, <a href="http://support.apple.com/kb/HT4070">Safari</a> et <a href="http://www.opera.com/support/kb/view/943/">Opera</a>.</li>
- <li>Images avec <a href="/fr/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="/fr/docs/HTML/Element/video"><code>&lt;video&gt;</code></a> et <a href="/fr/docs/HTML/Element/audio"><code>&lt;audio&gt;</code></a>.</li>
- <li>Objets avec <a href="/fr/docs/HTML/Element/object"><code>&lt;object&gt;</code></a>, <a href="/fr/docs/HTML/Element/embed"><code>&lt;embed&gt;</code></a> et <a href="/fr/docs/HTML/Element/applet"><code>&lt;applet&gt;</code></a>.</li>
- <li>Fontes de polices avec <a href="/fr/docs/CSS/@font-face"><code>@font-face</code></a>. Certain navigateurs autorisent les fontes cross-origin, d'autres appliquent la same-origin policy.</li>
- <li>N'importe quoi avec <a href="/fr/docs/HTML/Element/frame"><code>&lt;frame&gt;</code></a> et <a href="/fr/docs/HTML/Element/iframe"><code>&lt;iframe&gt;</code></a>. Un site peut utiliser l'entête<code><a href="/fr/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="/fr/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">Cross-Site Request Forgery (CSRF)</a> token, et interdisez la lecture cross-origin des pages qui connaissent 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 une balise <code>&lt;script&gt;</code> pointant un document HTML, le navigateur va tenter d'interpréter le code HTML comme du JavaScript. Si votre ressource n'est pas un point d'entrée de votre site, vous pouvez également utiliser un jeton CSRF.</li>
-</ul>
-
-<h2 id="Accès_script_cross-origin">Accès script cross-origin</h2>
-
-<p>Les APIs JavaScript comme <a href="/fr/docs/DOM/HTMLIFrameElement"><code>iframe.contentWindow</code></a>, <a href="/fr/docs/DOM/window.parent"><code>window.parent</code></a>, <a href="/fr/docs/DOM/window.open"><code>window.open</code></a> et <a href="/fr/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">Window</a> et <a href="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">permettent l'accès à plus de propriétés</a> que ce que les spécifications permettent. À la place, vous pouvez utiliser <code><a href="/fr/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">Same-origin policy for file: URIs</a></li>
- <li><a href="http://www.w3.org/Security/wiki/Same_Origin_Policy">Same-Origin Policy at W3C</a></li>
-</ul>
\ No newline at end of file
+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.
+
+## Définition de l'origine
+
+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 `http://store.company.com/dir/page.html` :
+
+| URL                                               | Résultat | Motif                 |
+| ------------------------------------------------- | -------- | --------------------- |
+| `http://store.company.com/dir2/other.html`        | Succès   |                       |
+| `http://store.company.com/dir/inner/another.html` | Succès   |                       |
+| `https://store.company.com/secure.html`           | Échec    | Protocoles différents |
+| `http://store.company.com:81/dir/etc.html`        | Échec    | Ports différents      |
+| `http://news.company.com/dir/other.html`          | Échec    | Hôtes différents      |
+
+Voir aussi [origin definition for `file:` URLs](/fr/docs/Same-origin_policy_for_file:_URIs).
+
+Les cookies utilisent une définition de l'origine différente de celle qui vient d'être définie.
+
+## Changer l'origine
+
+Une page peut changer son origine dans une certaine mesure. Un script peut définir la valeur de `document.domain `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 `http://store.company.com/dir/other.html` exécute le code suivant :
+
+    document.domain = "company.com";
+
+Après l'exécution de ce code, la page passerait le test d'origine avec `http://company.com/dir/page.html`. Ceci-dit, il ne serait pas possible de définir `document.domain` à `othercompany.com`.
+
+Le numéro de port est stocké par le navigateur séparément. Tout appel aux setter, y compris `document.domain = document.domain` entraine l'effacement du port par la valeur `null`. Une page située sur `company.com:8080` ne peut donc pas communiquer avec une autre située sur `company.com` en ne définissant que `document.domain = "company.com"` dans la première page. Ceci doit être fait dans les deux pages, ainsi les ports seront à `null` pour les deux.
+
+## Accès réseau cross-origin
+
+La same-origin policy contrôle les interactions entre deux origines différentes, quand vous utilisez [`XMLHttpRequest`](/fr/docs/DOM/XMLHttpRequest) par exemple. Ces interactions sont généralement rangées dans trois catégories :
+
+- _Écritures_ 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 [preflight](/fr/docs/HTTP/Access_control_CORS#Preflighted_requests).
+- _Embarqué_ cross-origin généralement autorisé. Les exemples sont listés ci-après.
+- _Lectures_ cross-origin généralement non autorisées.
+
+Voici quelques exemples de ressources qui peuvent être embarqués malgré leur origine incompatible avec la same-origin policy :
+
+- JavaScript avec `<script src="..."></script>`. Les messages d'erreur de syntaxe ne sont disponibles que pour les scripts ayant la même origine.
+- CSS avec` <link rel="stylesheet" href="...">`. Étant donnée la [souplesse des règles de syntaxe](http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html) du CSS, les CSS d'origine différentes nécessitent une entête `Content-Type` correcte. Les restrictions varient selon les navigateurs : [IE](http://msdn.microsoft.com/en-us/library/ie/gg622939%28v=vs.85%29.aspx), [Firefox](http://www.mozilla.org/security/announce/2010/mfsa2010-46.html), [Chrome](http://code.google.com/p/chromium/issues/detail?id=9877), [Safari](http://support.apple.com/kb/HT4070) et [Opera](http://www.opera.com/support/kb/view/943/).
+- Images avec [`<img>`](/fr/docs/HTML/Element/Img). Les formats d'image supportés, comprenant PNG, JPEG, GIF, BMP, SVG...
+- Fichiers média avec [`<video>`](/fr/docs/HTML/Element/video) et [`<audio>`](/fr/docs/HTML/Element/audio).
+- Objets avec [`<object>`](/fr/docs/HTML/Element/object), [`<embed>`](/fr/docs/HTML/Element/embed) et [`<applet>`](/fr/docs/HTML/Element/applet).
+- Fontes de polices avec [`@font-face`](/fr/docs/CSS/@font-face). Certain navigateurs autorisent les fontes cross-origin, d'autres appliquent la same-origin policy.
+- N'importe quoi avec [`<frame>`](/fr/docs/HTML/Element/frame) et [`<iframe>`](/fr/docs/HTML/Element/iframe). Un site peut utiliser l'entête[` X-Frame-Options`](/fr/docs/HTTP/X-Frame-Options) pour interdire cela depuis une page n'ayant pas la même origine.
+
+### Autoriser l'accès cross-origin
+
+Utiliser [CORS](/fr/docs/HTTP/Access_control_CORS) pour autoriser l'accès cross-origin.
+
+### Comment bloquer l'accès cross-origin access
+
+- 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 [Cross-Site Request Forgery (CSRF)](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) token, et interdisez la lecture cross-origin des pages qui connaissent ce token.
+- Pour interdire la lecture cross-origin d'une ressource, assurez-vous qu'elle ne peut pas être embarquée.
+- 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 `Content-Type`. Par exemple, pour une balise `<script>` pointant un document HTML, le navigateur va tenter d'interpréter le code HTML comme du JavaScript. Si votre ressource n'est pas un point d'entrée de votre site, vous pouvez également utiliser un jeton CSRF.
+
+## Accès script cross-origin
+
+Les APIs JavaScript comme [`iframe.contentWindow`](/fr/docs/DOM/HTMLIFrameElement), [`window.parent`](/fr/docs/DOM/window.parent), [`window.open`](/fr/docs/DOM/window.open) et [`window.opener`](/fr/docs/DOM/window.opener) 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 [Window](http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window) et [Location](http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location).  Certains navigateurs [permettent l'accès à plus de propriétés](https://bugzilla.mozilla.org/show_bug.cgi?id=839867) que ce que les spécifications permettent. À la place, vous pouvez utiliser [`window.postMessage`](/fr/docs/DOM/window.postMessage) pour communiquer entre deux documents.
+
+## Voir aussi
+
+- [Same-origin policy for file: URIs](/en/Same-origin_policy_for_file:_URIs)
+- [Same-Origin Policy at W3C](http://www.w3.org/Security/wiki/Same_Origin_Policy)
diff --git a/files/fr/web/security/secure_contexts/index.md b/files/fr/web/security/secure_contexts/index.md
index 652438d274..cca5cc5c86 100644
--- a/files/fr/web/security/secure_contexts/index.md
+++ b/files/fr/web/security/secure_contexts/index.md
@@ -3,152 +3,164 @@ 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>
+Un navigateur entre dans un **contexte sécurisé** 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>
 
-<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>
+## Pourquoi certaines fonctionnalitées devraient être limitées ?
 
-<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>
+Certaines APIs du web peuvent donner beaucoup de pouvoir à un attaqueur, lui permettant par exemple:
 
-<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>
+- Entrer dans la vie privée d'un utilisateur.
+- Avoir accès à l'ordinateur d'un utilisateur.
+- Avoir accès à des données (comme l'identité de l'utilisateur).
 
-<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>
+## À quel moment un context est-il considéré comme sécurisé ?
 
-<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>
+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>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>
+Les fichiers servis locallement avec des chemins comme *http\://localhost* et *file://* sont considérés sécurisés.
 
-<h2 id="Détection_des_fonctionnalités">Détection des fonctionnalités</h2>
+Les contextes qui ne sont pas servis locallement doivent être servis avec *https\://* ou *wss\://* et les protocoles utilisés ne doivent pas être considérés obsolètes.
 
-<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>
+## Détection des fonctionnalités
 
-<pre class="brush: js">if (window.isSecureContext) {
+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 `isSecureContext `qui est présent dans le scope global.
+
+```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>
+## Quelles APIs requièrent un contexte sécurisé ?
 
-<ul>
- <li>{{SpecName('Service Workers')}}</li>
- <li>{{SpecName('Web Bluetooth')}}</li>
- <li>{{SpecName('EME')}}</li>
-</ul>
+- {{SpecName('Service Workers')}}
+- {{SpecName('Web Bluetooth')}}
+- {{SpecName('EME')}}
 
-<h3 id="Prositions_de_brouillons">Prositions de brouillons</h3>
+### Prositions de brouillons
 
-<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>
+- <https://w3c.github.io/sensors/>
+- <https://w3c.github.io/webappsec-credential-management/>
+- <https://w3c.github.io/geofencing-api/>
+- <https://w3c.github.io/web-nfc/releases/20150925/>
 
-<h3 id="Navigateurs">Navigateurs</h3>
+### Navigateurs
 
-<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>
+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.
 
 <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>
+  <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>
+Pour vérifier le support de votre navigateur, utilisez le site: http\://permission.site
 
-<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>
+_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")._
 
-<h2 id="Spécifications">Spécifications</h2>
+## Spécifications
 
 <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>
+  <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>
+## Voir aussi
+
+
 
-<ul>
- <li>{{domxref("Window.isSecureContext")}}</li>
-</ul>
+- {{domxref("Window.isSecureContext")}}
diff --git a/files/fr/web/security/subresource_integrity/index.md b/files/fr/web/security/subresource_integrity/index.md
index d777689a8c..45de2fed51 100644
--- a/files/fr/web/security/subresource_integrity/index.md
+++ b/files/fr/web/security/subresource_integrity/index.md
@@ -6,94 +6,72 @@ tags:
   - 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>
+**_Subresource Integrity_** (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 [CDN](/fr/docs/Glossaire/CDN)) sont livrés sans manipulation inattendue. Cela fonctionne en permettant de fournir un hachage cryptographique (« _hash_ ») auquel le fichier récupéré doit correspondre.
 
-<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>
+## Comment fonctionne le contrôle d'intégrité des sous-ressources ?
 
-<p>Utiliser un <a href="/fr/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>
+Utiliser un [CDN](/fr/docs/Glossary/CDN) 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>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>
+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.
 
-<h2 id="Utiliser_le_SRI">Utiliser le SRI</h2>
+## Utiliser le SRI
 
-<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>
+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 **`integrity`** de chaque élément {{HTMLElement("script")}} ou {{HTMLElement("link")}}.
 
-<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>
+Une valeur de l'attribut **`integrity`** 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 `sha256`, `sha384` et `sha512`), suivi d'un tiret, et se terminant par le hachage base64 proprement dit.
 
-<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>
+> **Note :** Une valeur de l'attribut **`integrity`** peut contenir plusieurs hachages séparés par des espaces. Une ressource sera chargée si elle correspond à l'un de ces hachages.
 
-<p>Voici un exemple de valeur pour l'attribut <code><strong>integrity</strong></code> avec un hash sha384 encodé en base64 :</p>
+Voici un exemple de valeur pour l'attribut **`integrity`** avec un hash sha384 encodé en base64 :
 
-<pre>sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
-</pre>
+    sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
 
-<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>
+> **Note :** Le « _hash_ » est à proprement parler une **_fonction de hachage cryptographique_** 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 **_hash_** pour indiquer _fonction de hachage cryptographique_, d'où son utilisation dans cet article.
 
-<h3 id="Outil_pour_générer_des_hachages_SRI">Outil pour générer des hachages SRI</h3>
+### Outil pour générer des hachages SRI
 
-<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>
+Vous pouvez générer des _hashes_ SRI en ligne de commande avec OpenSSL en utilisant une commande de ce genre :
 
-<pre class="brush: bash">cat <strong>FILENAME.js</strong> | openssl dgst -sha384 -binary | openssl enc -base64 -A</pre>
+```bash
+cat FILENAME.js | openssl dgst -sha384 -binary | openssl enc -base64 -A
+```
 
-<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>
+Il existe également, **SRI Hash Generator** : <https://srihash.org/> qui est un utilitaire en ligne permettant de générer des _hashes_ SRI.
 
-<h2 id="Exemples">Exemples</h2>
+## Exemples
 
-<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>
+Dans les exemples suivants, supposons que `oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC` est la valeur attendue du _hash_ SHA-384 d'un script `exemple-framework.js`, et qu'il existe une copie de ce script hébergée sur `https://exemple.com/exemple-framework.js`.
 
-<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>
+### Exemple : utiliser l'élément `script` pour le contrôle d'intégrité
 
-<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>
+Vous pouvez utiliser l'élément {{HTMLElement("script")}} suivant pour dire au navigateur qu'il doit comparer le _hash_ fourni avec celui du fichier et que les deux correspondent avant d'exécuter le script hébergé à `https://example.com/exemple-framework.js`.
 
-<pre class="brush: html">&lt;script src="https://exemple.com/exemple-framework.js"
+```html
+<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>{{Compat("http.headers.csp.require-sri-for")}}</p>
-
-<h2 id="Voir_aussi">Voir aussi</h2>
-
-<ul>
- <li><a href="https://frederik-braun.com/using-subresource-integrity.html">Un CDN sans risque de XSS : utiliser le contrôle d'intégrité des sous-ressources (en anglais)</a></li>
-</ul>
+        crossorigin="anonymous"></script>
+```
+
+> **Note :** Pour plus de détails sur l'objectif de l'attribut **`crossorigin`**, voir [les attributs CORS](/fr/docs/Web/HTML/Reglages_des_attributs_CORS).
+
+## La gestion du SRI par les navigateurs
+
+Les navigateurs gèrent SRI en effectuant les étapes suivantes :
+
+1.  Lorsqu'un navigateur rencontre un élément {{HTMLElement("script")}} ou {{HTMLElement("link")}} avec un attribut **`integrity`**, 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 **`integrity`**.
+2.  Si le script ou la feuille de styles ne correspond pas à la valeur de l'attribut **`integrity`** 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é.
+
+## Spécifications
+
+| Spécification                                    | État                                         | Commentaires |
+| ------------------------------------------------ | -------------------------------------------- | ------------ |
+| {{SpecName('Subresource Integrity')}} | {{Spec2('Subresource Integrity')}} |              |
+| {{SpecName('Fetch')}}                     | {{Spec2('Fetch')}}                     |              |
+
+## Compatibilité des navigateurs
+
+{{Compat("http.headers.csp.require-sri-for")}}
+
+## Voir aussi
+
+- [Un CDN sans risque de XSS : utiliser le contrôle d'intégrité des sous-ressources (en anglais)](https://frederik-braun.com/using-subresource-integrity.html)