From fa764544773f6bef13c15c26df944c525f765645 Mon Sep 17 00:00:00 2001 From: julieng Date: Thu, 11 Nov 2021 08:39:18 +0100 Subject: move *.html to *.md --- files/fr/web/security/index.html | 23 --- files/fr/web/security/index.md | 23 +++ .../index.html | 56 -------- .../index.md | 56 ++++++++ .../fr/web/security/same-origin_policy/index.html | 106 -------------- files/fr/web/security/same-origin_policy/index.md | 106 ++++++++++++++ files/fr/web/security/secure_contexts/index.html | 154 --------------------- files/fr/web/security/secure_contexts/index.md | 154 +++++++++++++++++++++ .../web/security/subresource_integrity/index.html | 99 ------------- .../fr/web/security/subresource_integrity/index.md | 99 +++++++++++++ 10 files changed, 438 insertions(+), 438 deletions(-) delete mode 100644 files/fr/web/security/index.html create mode 100644 files/fr/web/security/index.md delete mode 100644 files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.html create mode 100644 files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.md delete mode 100644 files/fr/web/security/same-origin_policy/index.html create mode 100644 files/fr/web/security/same-origin_policy/index.md delete mode 100644 files/fr/web/security/secure_contexts/index.html create mode 100644 files/fr/web/security/secure_contexts/index.md delete mode 100644 files/fr/web/security/subresource_integrity/index.html create mode 100644 files/fr/web/security/subresource_integrity/index.md diff --git a/files/fr/web/security/index.html b/files/fr/web/security/index.html deleted file mode 100644 index edfcb443d5..0000000000 --- a/files/fr/web/security/index.html +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Sécurité Web -slug: Web/Security -tags: - - Landing - - Security - - 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.

- - -

{{LandingPageListSubpages}}

- -

Voir aussi

- - - -

{{QuickLinksWithSubpages}}

diff --git a/files/fr/web/security/index.md b/files/fr/web/security/index.md new file mode 100644 index 0000000000..edfcb443d5 --- /dev/null +++ b/files/fr/web/security/index.md @@ -0,0 +1,23 @@ +--- +title: Sécurité Web +slug: Web/Security +tags: + - Landing + - Security + - 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.

+ + +

{{LandingPageListSubpages}}

+ +

Voir aussi

+ + + +

{{QuickLinksWithSubpages}}

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 deleted file mode 100644 index 0720f09854..0000000000 --- a/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -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' ---- -

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.

- -

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.

- -

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.

- -

Comment régler ce problème ?

- -

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.

- -

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.

- -

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.

- -

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.

- -

Vous pouvez également atténuer ces risques en utilisant :

- - - -

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 :

- - - -

Politique et exigences.

- -

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.

- -

Voir aussi

- - 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 new file mode 100644 index 0000000000..0720f09854 --- /dev/null +++ b/files/fr/web/security/referer_header_colon__privacy_and_security_concerns/index.md @@ -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' +--- +

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.

+ +

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.

+ +

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.

+ +

Comment régler ce problème ?

+ +

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.

+ +

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.

+ +

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.

+ +

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.

+ +

Vous pouvez également atténuer ces risques en utilisant :

+ + + +

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 :

+ + + +

Politique et exigences.

+ +

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.

+ +

Voir aussi

+ + diff --git a/files/fr/web/security/same-origin_policy/index.html b/files/fr/web/security/same-origin_policy/index.html deleted file mode 100644 index 7dd82934f7..0000000000 --- a/files/fr/web/security/same-origin_policy/index.html +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Same-origin policy -slug: Web/Security/Same-origin_policy -translation_of: Web/Security/Same-origin_policy -original_slug: Web/Security/Same_origin_policy_for_JavaScript ---- -

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 :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
URLRésultatMotif
http://store.company.com/dir2/other.htmlSuccès
http://store.company.com/dir/inner/another.htmlSuccès
https://store.company.com/secure.htmlÉchecProtocoles différents
http://store.company.com:81/dir/etc.htmlÉchecPorts différents
http://news.company.com/dir/other.htmlÉchecHôtes différents
- -

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 :

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

- - - -

Voici quelques exemples de ressources qui peuvent être embarqués malgré leur origine incompatible avec la same-origin policy :

- - - -

Autoriser l'accès cross-origin

- -

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

- -

Comment bloquer l'accès cross-origin access

- - - -

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.

- -

Voir aussi

- - \ No newline at end of file diff --git a/files/fr/web/security/same-origin_policy/index.md b/files/fr/web/security/same-origin_policy/index.md new file mode 100644 index 0000000000..7dd82934f7 --- /dev/null +++ b/files/fr/web/security/same-origin_policy/index.md @@ -0,0 +1,106 @@ +--- +title: Same-origin policy +slug: Web/Security/Same-origin_policy +translation_of: Web/Security/Same-origin_policy +original_slug: Web/Security/Same_origin_policy_for_JavaScript +--- +

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 :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
URLRésultatMotif
http://store.company.com/dir2/other.htmlSuccès
http://store.company.com/dir/inner/another.htmlSuccès
https://store.company.com/secure.htmlÉchecProtocoles différents
http://store.company.com:81/dir/etc.htmlÉchecPorts différents
http://news.company.com/dir/other.htmlÉchecHôtes différents
+ +

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 :

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

+ + + +

Voici quelques exemples de ressources qui peuvent être embarqués malgré leur origine incompatible avec la same-origin policy :

+ + + +

Autoriser l'accès cross-origin

+ +

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

+ +

Comment bloquer l'accès cross-origin access

+ + + +

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.

+ +

Voir aussi

+ + \ No newline at end of file diff --git a/files/fr/web/security/secure_contexts/index.html b/files/fr/web/security/secure_contexts/index.html deleted file mode 100644 index 652438d274..0000000000 --- a/files/fr/web/security/secure_contexts/index.html +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: Secure Contexts -slug: Web/Security/Secure_Contexts -translation_of: Web/Security/Secure_Contexts ---- -

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.

- -

 

- -

Pourquoi certaines fonctionnalitées devraient être limitées ?

- -

Certaines APIs du web peuvent donner beaucoup de pouvoir à un attaqueur, lui permettant par exemple:

- - - -

À quel moment un context est-il considéré comme sécurisé ?

- -

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.

- -

Les fichiers servis locallement avec des chemins comme http://localhost et file:// sont considérés sécurisés.

- -

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.

- -

Détection des fonctionnalités

- -

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.

- -
if (window.isSecureContext) {
-  // La page est dans un contexte sécurisé, les services workers sont disponibles.
-  navigator.serviceWorker.register("/offline-worker.js").then(function () {
-    ...
-  });
-}
- -

Quelles APIs requièrent un contexte sécurisé ?

- - - -

Prositions de brouillons

- - - - - -

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 ChromeSafariFirefox
getUserMedia -

Désactivé

- -

Supprimé dans Chrome 47

- 		  -

Accès temporaire uniquement (les utilisateurs ne peuvent pas choisir "Retenir ce choix" dans la selection de permission).

-
Geolocation -

Désactivé

- -

Supprimé dans Chrome 50

- 		-

Désactivé

- -

Suppression ici

- 		-

Suppression en cours

- -

Suppression attendue pour Firefox 55

-
EMEAvertissement de dépréciation  
Device motion / orientationAvertissement de dépréciation  
MIDIDésactivé  
{{SpecName('Web Crypto API')}}est réservé à HTTPS même is la vérification du Secure Context est antérieur  
- -

Pour vérifier le support de votre navigateur, utilisez le site: http://permission.site

- -

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").

- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationÉtatCommentaire
{{SpecName('Secure Contexts')}}{{Spec2('Secure Contexts')}}Brouillon
- -

 

- -

Voir aussi

- -

 

- - diff --git a/files/fr/web/security/secure_contexts/index.md b/files/fr/web/security/secure_contexts/index.md new file mode 100644 index 0000000000..652438d274 --- /dev/null +++ b/files/fr/web/security/secure_contexts/index.md @@ -0,0 +1,154 @@ +--- +title: Secure Contexts +slug: Web/Security/Secure_Contexts +translation_of: Web/Security/Secure_Contexts +--- +

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.

+ +

 

+ +

Pourquoi certaines fonctionnalitées devraient être limitées ?

+ +

Certaines APIs du web peuvent donner beaucoup de pouvoir à un attaqueur, lui permettant par exemple:

+ + + +

À quel moment un context est-il considéré comme sécurisé ?

+ +

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.

+ +

Les fichiers servis locallement avec des chemins comme http://localhost et file:// sont considérés sécurisés.

+ +

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.

+ +

Détection des fonctionnalités

+ +

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.

+ +
if (window.isSecureContext) {
+  // La page est dans un contexte sécurisé, les services workers sont disponibles.
+  navigator.serviceWorker.register("/offline-worker.js").then(function () {
+    ...
+  });
+}
+ +

Quelles APIs requièrent un contexte sécurisé ?

+ + + +

Prositions de brouillons

+ + + + + +

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 ChromeSafariFirefox
getUserMedia +

Désactivé

+ +

Supprimé dans Chrome 47

+ 		  +

Accès temporaire uniquement (les utilisateurs ne peuvent pas choisir "Retenir ce choix" dans la selection de permission).

+
Geolocation +

Désactivé

+ +

Supprimé dans Chrome 50

+ 		+

Désactivé

+ +

Suppression ici

+ 		+

Suppression en cours

+ +

Suppression attendue pour Firefox 55

+
EMEAvertissement de dépréciation  
Device motion / orientationAvertissement de dépréciation  
MIDIDésactivé  
{{SpecName('Web Crypto API')}}est réservé à HTTPS même is la vérification du Secure Context est antérieur  
+ +

Pour vérifier le support de votre navigateur, utilisez le site: http://permission.site

+ +

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").

+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationÉtatCommentaire
{{SpecName('Secure Contexts')}}{{Spec2('Secure Contexts')}}Brouillon
+ +

 

+ +

Voir aussi

+ +

 

+ + diff --git a/files/fr/web/security/subresource_integrity/index.html b/files/fr/web/security/subresource_integrity/index.html deleted file mode 100644 index d777689a8c..0000000000 --- a/files/fr/web/security/subresource_integrity/index.html +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Subresource Integrity -slug: Web/Security/Subresource_Integrity -tags: - - Intro - - Sécurité -translation_of: Web/Security/Subresource_Integrity ---- -

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) sont livrés sans manipulation inattendue. Cela fonctionne en permettant de fournir un hachage cryptographique (« hash ») auquel le fichier récupéré doit correspondre.

- -

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.

- -

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.

- -

Utiliser le SRI

- -

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")}}.

- -

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.

-
- -

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

- -
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
-
- -
-

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.

-
- -

Outil pour générer des hachages SRI

- -

Vous pouvez générer des hashes SRI en ligne de commande avec OpenSSL en utilisant une commande de ce genre :

- -
cat FILENAME.js | openssl dgst -sha384 -binary | openssl enc -base64 -A
- -

Il existe également, SRI Hash Generator : https://srihash.org/ qui est un utilitaire en ligne permettant de générer des hashes SRI. 

- -

Exemples

- -

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.

- -

Exemple : utiliser l'élément script pour le contrôle d'intégrité

- -

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.

- -
<script src="https://exemple.com/exemple-framework.js"
-        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
-        crossorigin="anonymous"></script>
- -
-

Note : Pour plus de détails sur l'objectif de l'attribut crossorigin, voir les 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. -
  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é.
    3. -
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationÉtatCommentaires
{{SpecName('Subresource Integrity')}}{{Spec2('Subresource Integrity')}} 
{{SpecName('Fetch')}}{{Spec2('Fetch')}} 
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.require-sri-for")}}

- -

Voir aussi

- - diff --git a/files/fr/web/security/subresource_integrity/index.md b/files/fr/web/security/subresource_integrity/index.md new file mode 100644 index 0000000000..d777689a8c --- /dev/null +++ b/files/fr/web/security/subresource_integrity/index.md @@ -0,0 +1,99 @@ +--- +title: Subresource Integrity +slug: Web/Security/Subresource_Integrity +tags: + - Intro + - Sécurité +translation_of: Web/Security/Subresource_Integrity +--- +

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) sont livrés sans manipulation inattendue. Cela fonctionne en permettant de fournir un hachage cryptographique (« hash ») auquel le fichier récupéré doit correspondre.

+ +

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.

+ +

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.

+ +

Utiliser le SRI

+ +

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")}}.

+ +

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.

+
+ +

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

+ +
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
+
+ +
+

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.

+
+ +

Outil pour générer des hachages SRI

+ +

Vous pouvez générer des hashes SRI en ligne de commande avec OpenSSL en utilisant une commande de ce genre :

+ +
cat FILENAME.js | openssl dgst -sha384 -binary | openssl enc -base64 -A
+ +

Il existe également, SRI Hash Generator : https://srihash.org/ qui est un utilitaire en ligne permettant de générer des hashes SRI. 

+ +

Exemples

+ +

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.

+ +

Exemple : utiliser l'élément script pour le contrôle d'intégrité

+ +

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.

+ +
<script src="https://exemple.com/exemple-framework.js"
+        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
+        crossorigin="anonymous"></script>
+ +
+

Note : Pour plus de détails sur l'objectif de l'attribut crossorigin, voir les 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. +
  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é.
    3. +
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationÉtatCommentaires
{{SpecName('Subresource Integrity')}}{{Spec2('Subresource Integrity')}} 
{{SpecName('Fetch')}}{{Spec2('Fetch')}} 
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.require-sri-for")}}

+ +

Voir aussi

+ + -- cgit v1.2.3-54-g00ecf