From 1c856577d5b2647641006f73cbe274d2df95956c Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Thu, 11 Nov 2021 08:38:45 +0100 Subject: Fix md conversion errors (#3024) --- files/fr/web/security/index.html | 3 +- .../index.html | 4 +- .../fr/web/security/same-origin_policy/index.html | 52 +++++++++------------- .../web/security/subresource_integrity/index.html | 6 +-- 4 files changed, 27 insertions(+), 38 deletions(-) diff --git a/files/fr/web/security/index.html b/files/fr/web/security/index.html index 7cb67bdad9..edfcb443d5 100644 --- a/files/fr/web/security/index.html +++ b/files/fr/web/security/index.html @@ -7,8 +7,7 @@ tags: - Web translation_of: Web/Security --- -
-

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.

+

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.

{{LandingPageListSubpages}}

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 index cf4e65ea9b..0720f09854 100644 --- 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 @@ -9,11 +9,11 @@ tags: - referrer translation_of: 'Web/Security/Referer_header:_privacy_and_security_concerns' --- -

L'entête HTTP Referer présente des risques de confidentialité et de sécurité. Cet article les décrit et donne des conseils pour les minimiser.

+

L'entête HTTP Referer présente des risques de confidentialité et de sécurité. Cet article les décrit et donne des conseils pour les minimiser.

Le problème...

-

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.

+

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.

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.

diff --git a/files/fr/web/security/same-origin_policy/index.html b/files/fr/web/security/same-origin_policy/index.html index 06808871ec..7dd82934f7 100644 --- a/files/fr/web/security/same-origin_policy/index.html +++ b/files/fr/web/security/same-origin_policy/index.html @@ -8,7 +8,7 @@ original_slug: Web/Security/Same_origin_policy_for_JavaScript

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 :

+

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 :

@@ -18,54 +18,54 @@ original_slug: Web/Security/Same_origin_policy_for_JavaScript - + - + - + - + - +
Motif
http://store.company.com/dir2/other.htmlhttp://store.company.com/dir2/other.html Succès
http://store.company.com/dir/inner/another.htmlhttp://store.company.com/dir/inner/another.html Succès
https://store.company.com/secure.htmlhttps://store.company.com/secure.html Échec Protocoles différents
http://store.company.com:81/dir/etc.htmlhttp://store.company.com:81/dir/etc.html Échec Ports différents
http://news.company.com/dir/other.htmlhttp://news.company.com/dir/other.html Échec Hôtes différents
-

Voir aussi origin definition for file: URLs.

+

Voir aussi origin definition for file: URLs.

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 :

+

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.

+

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 par exemple. Ces interactions sont généralement rangées dans trois catégories :

+

La same-origin policy contrôle les interactions entre deux origines différentes, quand vous utilisez XMLHttpRequest par exemple. Ces interactions sont généralement rangées dans trois catégories :

@@ -74,17 +74,17 @@ original_slug: Web/Security/Same_origin_policy_for_JavaScript

Autoriser l'accès cross-origin

-

Utiliser CORS pour autoriser l'accès cross-origin.

+

Utiliser CORS pour autoriser l'accès cross-origin.

Comment bloquer l'accès cross-origin access

@@ -96,21 +96,11 @@ original_slug: Web/Security/Same_origin_policy_for_JavaScript

Accès script cross-origin

-

Les APIs JavaScript comme iframe.contentWindow, window.parent, window.open et 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 et Location.  Certains navigateurs permettent l'accès à plus de propriétés que ce que les spécifications permettent. À la place, vous pouvez utiliser window.postMessage pour communiquer entre deux documents.

+

Les APIs JavaScript comme iframe.contentWindow, window.parent, window.open et 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 et Location.  Certains navigateurs permettent l'accès à plus de propriétés que ce que les spécifications permettent. À la place, vous pouvez utiliser window.postMessage pour communiquer entre deux documents.

Voir aussi

- -
-

Original Document Information

- - -
- -
{{ languages( {"ja": "Ja/Same_origin_policy_for_JavaScript", "zh-cn": "Cn/JavaScript的同源策略"} ) }}
+ \ No newline at end of file diff --git a/files/fr/web/security/subresource_integrity/index.html b/files/fr/web/security/subresource_integrity/index.html index f0466f235b..d777689a8c 100644 --- a/files/fr/web/security/subresource_integrity/index.html +++ b/files/fr/web/security/subresource_integrity/index.html @@ -10,7 +10,7 @@ translation_of: Web/Security/Subresource_Integrity

Comment fonctionne le contrôle d'intégrité des sous-ressources ?

-

Utiliser un 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.

+

Utiliser un 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.

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.

@@ -21,7 +21,7 @@ translation_of: Web/Security/Subresource_Integrity

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.

-

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.

+

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.

Voici un exemple de valeur pour l'attribut integrity avec un hash sha384 encodé en base64 :

@@ -95,5 +95,5 @@ translation_of: Web/Security/Subresource_Integrity

Voir aussi

-- cgit v1.2.3-54-g00ecf