From f4a8a1f9fbd2e4bb409c36178e01786843ae9c3d Mon Sep 17 00:00:00 2001 From: julieng Date: Thu, 11 Nov 2021 08:39:25 +0100 Subject: convert content to md --- files/fr/web/security/index.md | 17 +- .../index.md | 54 ++--- files/fr/web/security/same-origin_policy/index.md | 164 ++++++-------- files/fr/web/security/secure_contexts/index.md | 242 +++++++++++---------- .../fr/web/security/subresource_integrity/index.md | 120 +++++----- 5 files changed, 271 insertions(+), 326 deletions(-) (limited to 'files/fr') 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 --- -

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}}

+{{LandingPageListSubpages}} -

Voir aussi

+## Voir aussi - +- [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) -

{{QuickLinksWithSubpages}}

+{{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 --- -

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](/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. -

Le problème...

+## 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.

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

+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 ?

+## 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.

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

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

+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 :

+Vous pouvez également atténuer ces risques en utilisant : - +- 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 `` et ``). 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 `` et \). 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). -

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 :

+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 : - +- 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é). -

Politique et exigences.

+## 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.

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

Voir aussi

+## Voir aussi - +- [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 --- -

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 +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 ``. Les messages d'erreur de syntaxe ne sont disponibles que pour les scripts ayant la même origine. +- CSS avec` `. É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 [``](/fr/docs/HTML/Element/Img). Les formats d'image supportés, comprenant PNG, JPEG, GIF, BMP, SVG... +- Fichiers média avec [`