Typo and grammatical correction in French ASVS V4 (#1942)

* Update 0x21-V13-API.md

* Update 0x90-Appendix-A_Glossary.md

* Update 0x90-Appendix-A_Glossary.md

* Update 0x20-V12-Files-Resources.md

* Update 0x03-Using-ASVS.md

* Update 0x11-V2-Authentication.md

* Update 0x13-V5-Validation-Sanitization-Encoding.md

* Update 0x14-V6-Cryptography.md

* Update 0x15-V7-Error-Logging.md

* Update 0x16-V8-Data-Protection.md

* Update 0x17-V9-Communications.md

* Update 0x18-V10-Malicious.md

* Update 0x19-V11-BusLogic.md

* Update 0x20-V12-Files-Resources.md

* Update 0x22-V14-Config.md

* Update 0x11-V2-Authentication.md

* Update 0x11-V2-Authentication.md

* Update 0x20-V12-Files-Resources.md

* Update 0x22-V14-Config.md

4.0/fr/0x03-Using-ASVS.md

@@ -19,7 +19,7 @@ Chaque niveau ASVS contient une liste d'exigences de sécurité. Chacune de ces
 
 Figure 1 - Niveaux de vérification de la sécurité des applications OWASP 4.0
 
-Le niveau 1 est le seul qui soit entièrement adéquat pour des tests d'intrusions fait par des humains. Tous les autres niveaux nécessitent l'accès à la documentation, au code source, à la configuration et aux personnes impliquées dans le processus de développement. Cependant, même si le niveau 1 permet de réaliser des tests de "boîte noire" (pas de documentation et pas de source), ce n'est pas une activité d'assurance efficace et doit être activement découragée. Les attaquants malveillants ont beaucoup de temps, la plupart des tests d'intrusions  sont terminés en quelques semaines. Les défenseurs doivent mettre en place des contrôles de sécurité, protéger, trouver et résoudre toutes les faiblesses, et détecter et répondre aux acteurs malveillants dans un délai raisonnable. Les acteurs malveillants disposent essentiellement d'un temps infini et n'ont besoin que d'une seule défense poreuse, d'une seule faiblesse ou d'une détection manquante pour réussir. Les tests de la boîte noire, souvent effectués en fin de développement, rapidement ou pas du tout, sont totalement incapables de faire face à cette asymétrie.
+Le niveau 1 est le seul qui soit entièrement adéquat pour des tests d'intrusions faits par des humains. Tous les autres niveaux nécessitent l'accès à la documentation, au code source, à la configuration et aux personnes impliquées dans le processus de développement. Cependant, même si le niveau 1 permet de réaliser des tests de "boîte noire" (pas de documentation et pas de source), ce n'est pas une activité d'assurance efficace et doit être activement découragé. Les attaquants malveillants ont beaucoup de temps, la plupart des tests d'intrusions  sont terminés en quelques semaines. Les défenseurs doivent mettre en place des contrôles de sécurité, protéger, trouver et résoudre toutes les faiblesses, et détecter et répondre aux acteurs malveillants dans un délai raisonnable. Les acteurs malveillants disposent essentiellement d'un temps infini et n'ont besoin que d'une seule défense poreuse, d'une seule faiblesse ou d'une détection manquante pour réussir. Les tests de la boîte noire, souvent effectués en fin de développement, rapidement ou pas du tout, sont totalement incapables de faire face à cette asymétrie.
 
 Au cours des 30 dernières années, les tests en boîte noire ont prouvé à maintes reprises qu'ils passaient à côté de problèmes de sécurité critiques qui ont directement conduit à des violations de plus en plus massives. Nous encourageons vivement l'utilisation d'un large éventail de mesures d'assurance et de vérification de la sécurité, notamment le remplacement des tests d'intrusions par des tests d'intrusions (hybrides) de niveau 1 basés sur le code source, avec un accès complet aux développeurs et à la documentation tout au long du processus de développement. Les régulateurs financiers ne tolèrent pas les audits financiers externes sans accès aux livres, aux échantillons de transactions ou aux personnes effectuant les contrôles. L'industrie et les gouvernements doivent exiger le même niveau de transparence dans le domaine du génie logiciel.
 
@@ -31,15 +31,15 @@ Les outils automatisés et les scanners en ligne ne permettent pas de réaliser
 
 L'une des meilleures façons d'utiliser le référentiel de vérification de la sécurité des applications est de l'utiliser comme plan directeur pour créer une liste de contrôle de codage sécurisé spécifique à votre application, plate-forme ou organisation. En adaptant l'ASVS à vos cas d'utilisation, vous pourrez mieux vous concentrer sur les exigences de sécurité les plus importantes pour vos projets et vos environnements.
 
-### Niveau 1 - Premières étapes, automatisé, ou vue de l'ensemble du portefeuille
+### Niveau 1 - Premières étapes, automatisation, ou vue de l'ensemble du portefeuille
 
 Une application atteint le niveau 1 de l'ASVS si elle se défend de manière adéquate contre les vulnérabilités de sécurité des applications qui sont faciles à découvrir, et qui figurent dans le Top 10 de l'OWASP et d'autres listes de contrôle similaires.
 
 Le niveau 1 est le strict minimum que toutes les applications devraient s'efforcer d'atteindre. Il est également utile comme première étape dans un effort en plusieurs phases ou lorsque les applications ne stockent pas ou ne traitent pas de données sensibles et n'ont donc pas besoin des contrôles plus rigoureux du niveau 2 ou 3. Les contrôles de niveau 1 peuvent être vérifiés soit automatiquement par des outils, soit simplement manuellement sans accès au code source. Nous considérons que le niveau 1 est le minimum requis pour toutes les applications.
 
 Les menaces pour l'application proviendront très probablement d'attaquants qui utilisent des techniques simples et peu exigeantes pour identifier des vulnérabilités faciles à trouver et à exploiter. En revanche, un attaquant déterminé dépensera une énergie considérable pour cibler spécifiquement l'application. Si les données traitées par votre application ont une valeur élevée, vous voudrez rarement vous arrêter à un examen de niveau 1.
 
-### Niveau 2 - La plupart des demandes
+### Niveau 2 - La majorité des applications
 
 Une application atteint le niveau 2 (ou norme) de l'ASVS si elle se défend adéquatement contre la plupart des risques associés aux logiciels d'aujourd'hui.
 

4.0/fr/0x11-V2-Authentication.md

@@ -32,7 +32,7 @@ Les applications peuvent toujours dépasser les exigences du niveau actuel, surt
 
 ## V2.1 Exigences en matière de sécurité des mots de passe
 
-Les mots de passe, appelés "Memorized Secrets" par NIST 800-63, comprennent les mots de passe, les codes PIN, les motifs de déverrouillage, le choix bu bon chatton ou d'un autre élément d'image, et les phrases de passe. Ils sont généralement considérés comme "quelque chose que vous savez" et sont souvent utilisés comme des authentificateurs à facteur unique. L'utilisation continue de l'authentification à un facteur unique pose des problèmes importants, notamment les milliards de noms d'utilisateur et de mots de passe valides divulgués sur l'internet, les mots de passe par défaut ou faibles, les tables arc-en-ciel et les dictionnaires ordonnés des mots de passe les plus courants.
+Les mots de passe, appelés "Memorized Secrets" par NIST 800-63, comprennent les mots de passe, les codes PIN, les motifs de déverrouillage, le choix du bon chaton ou d'un autre élément d'image, et les phrases de passe. Ils sont généralement considérés comme "quelque chose que vous savez" et sont souvent utilisés comme des authentificateurs à facteur unique. L'utilisation continue de l'authentification à un facteur unique pose des problèmes importants, notamment les milliards de noms d'utilisateur et de mots de passe valides divulgués sur l'internet, les mots de passe par défaut ou faibles, les tables arc-en-ciel et les dictionnaires ordonnés des mots de passe les plus courants.
 
 Les applications devraient fortement encourager les utilisateurs à s'inscrire à l'authentification multi-facteurs, et devraient permettre aux utilisateurs de réutiliser les jetons qu'ils possèdent déjà, tels que les jetons FIDO ou U2F, ou de se relier à un fournisseur de services d'accréditation qui fournit une authentification multi-facteurs.
 
@@ -43,7 +43,7 @@ Les fournisseurs de services d'accréditation (CSP) fournissent une identité f
 | **2.1.1** | Vérifiez que les mots de passe définis par l'utilisateur comportent au moins 12 caractères (après avoir combiné plusieurs espaces). ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
 | **2.1.2** | Vérifiez que les mots de passe de 64 caractères ou plus sont autorisés, mais pas au delà de 128 caractères. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
 | **2.1.3** | Vérifiez que le mot de passe n'est pas tronqué. Toutefois, des espaces multiples consécutifs peuvent être remplacés par un seul espace. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
-| **2.1.4** | Vérifiez que tout caractère Unicode imprimable, y compris les caractères neutres comme les espaces et les Emojis, sont autorisés dans les mots de passe. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
+| **2.1.4** | Vérifiez que tous les caractères Unicode imprimables, y compris les caractères neutres comme les espaces et les Emojis, sont autorisés dans les mots de passe. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
 | **2.1.5** | Vérifier que les utilisateurs peuvent changer leur mot de passe. | ✓ | ✓ | ✓ | 620 | 5.1.1.2 |
 | **2.1.6** | Vérifiez que la fonctionnalité de changement de mot de passe nécessite le mot de passe actuel et le nouveau mot de passe de l'utilisateur. | ✓ | ✓ | ✓ | 620 | 5.1.1.2 |
 | **2.1.7** | Vérifiez que les mots de passe soumis lors de l'enregistrement du compte, de la connexion et du changement de mot de passe sont comparés à un ensemble de mots de passe violés, soit localement (comme les 1 000 ou 10 000 mots de passe les plus courants qui correspondent à la politique de mot de passe du système), soit en utilisant une API externe. En cas d'utilisation d'une API, une preuve de connaissance nulle ou un autre mécanisme doit être utilisé pour garantir que le mot de passe en texte clair n'est pas envoyé ou utilisé pour vérifier l'état de violation du mot de passe. Si le mot de passe est violé, l'application doit demander à l'utilisateur de définir un nouveau mot de passe non violé. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |

4.0/fr/0x13-V5-Validation-Sanitization-Encoding.md

@@ -7,10 +7,10 @@ La faiblesse la plus courante en matière de sécurité des applications web est
 Assurez-vous qu'une application vérifiée satisfait aux exigences de haut niveau suivantes :
 
 * La validation des entrées et l'architecture de codage des sorties ont un pipeline convenu pour prévenir les attaques par injection.
-* Les données d'entrée sont fortement typées, validées, vérifiées en plage ou en longueur ou, au pire, aseptisées ou filtrées.
+* Les données d'entrée sont fortement typées, validées, vérifiées en plage ou en longueur ou au pire, aseptisées ou filtrées.
 * Les données de sortie sont codées ou échappées selon le contexte des données, aussi près que possible de l'interpréteur.
 
-Avec l'architecture moderne des applications web, l'encodage des données de sortie est plus important que jamais. Il est difficile de fournir une validation robuste des entrées dans certains scénarios, de sorte que l'utilisation d'API plus sûres telles que les requêtes paramétrées, les cadres de modélisation à évasion automatique ou un encodage de sortie soigneusement choisi est essentiel pour la sécurité de l'application.
+Avec l'architecture moderne des applications web, l'encodage des données de sortie est plus important que jamais. Il est difficile de fournir une validation robuste des entrées dans certains scénarios, de sorte que l'utilisation d'API plus sûres telles que les requêtes paramétrées, les frameworks de modélisation d'échappement automatique ou un encodage de sortie soigneusement choisi sont essentiels pour la sécurité de l'application.
 
 ## V5.1 Exigences de validation des entrées
 
@@ -20,21 +20,21 @@ Des contrôles de validation des entrées correctement mis en œuvre, utilisant
 | :---: | :--- | :---: | :---:| :---: | :---: |
 | **5.1.1** | Vérifiez que l'application dispose de défenses contre les attaques de pollution des paramètres HTTP, en particulier si le cadre de l'application ne fait aucune distinction quant à la source des paramètres de la requête (GET, POST, cookies, en-têtes ou variables d'environnement). | ✓ | ✓ | ✓ | 235 |
 | **5.1.2** | Vérifiez que les cadriciels protègent contre les attaques par assignation massive de paramètres, ou que l'application dispose de contre-mesures pour protéger contre l'assignation dangereuse de paramètres, comme le marquage des champs privés ou similaires. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 915 |
-| **5.1.3** | Vérifiez que toutes les entrées (champs de formulaire HTML, demandes REST, paramètres URL, en-têtes HTTP, cookies, fichiers batch, flux RSS, etc) sont validées par une validation positive (liste d'autorisation). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 |
+| **5.1.3** | Vérifiez que toutes les entrées (champs de formulaire HTML, requêtes REST, paramètres URL, en-têtes HTTP, cookies, fichiers batch, flux RSS, etc) sont validées par une validation positive (liste d'autorisation). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 |
 | **5.1.4** | Vérifier que les données structurées sont fortement typées et validées par rapport à un schéma défini comprenant les caractères, la longueur et le modèle autorisés (par exemple, numéros de carte de crédit ou de téléphone, ou valider que deux champs connexes sont raisonnables, comme vérifier la correspondance entre la banlieue et le code postal). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 |
-| **5.1.5** | Vérifiez que les redirections et les transferts d'URL n'autorisent que les destinations prévu, ou affichez un avertissement lors d'une redirection vers un contenu potentiellement non fiable. | ✓ | ✓ | ✓ | 601 |
+| **5.1.5** | Vérifiez que les redirections et les transferts d'URL n'autorisent que les destinations prévues, ou affichez un avertissement lors d'une redirection vers un contenu potentiellement non fiable. | ✓ | ✓ | ✓ | 601 |
 
 ## V5.2 Exigences en matière d'assainissement et de « bac à sable »
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---:| :---: | :---: |
-| **5.2.1** | Vérifiez que toutes les entrées HTML non fiables provenant d'éditeurs WYSIWYG ou similaires sont correctement assainit avec une bibliothèque ou une fonction de framework de nettoyage HTML. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 116 |
-| **5.2.2** | Vérifiez que les données non structurées sont assainit afin d'appliquer les mesures de sécurité telles que les caractères et la longueur autorisés. | ✓ | ✓ | ✓ | 138 |
+| **5.2.1** | Vérifiez que toutes les entrées HTML non fiables provenant d'éditeurs WYSIWYG ou similaires sont correctement assainies avec une bibliothèque ou une fonction de framework de nettoyage HTML. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 116 |
+| **5.2.2** | Vérifiez que les données non structurées sont assainies afin d'appliquer les mesures de sécurité telles que les caractères et la longueur autorisés. | ✓ | ✓ | ✓ | 138 |
 | **5.2.3** | Vérifiez que l'application assainit les entrées de l'utilisateur avant de passer aux systèmes de messagerie pour protéger contre l'injection SMTP ou IMAP. | ✓ | ✓ | ✓ | 147 |
-| **5.2.4** | Vérifiez que l'application évite l'utilisation de eval() ou d'autres fonctions d'exécution de code dynamique. Lorsqu'il n'y a pas d'alternative, toute entrée utilisateur incluse doit être assainit ou mise en sandbox avant d'être exécutée. | ✓ | ✓ | ✓ | 95 |
+| **5.2.4** | Vérifiez que l'application évite l'utilisation de eval() ou d'autres fonctions d'exécution de code dynamique. Lorsqu'il n'y a pas d'alternative, toute entrée utilisateur incluse doit être assainie ou mise en sandbox avant d'être exécutée. | ✓ | ✓ | ✓ | 95 |
 | **5.2.5** | Vérifiez que l'application protège contre les attaques par injection de modèles en veillant à ce que toute entrée de l'utilisateur incluse soit aseptisée ou mise en bac à sable. | ✓ | ✓ | ✓ | 94 |
 | **5.2.6** | Vérifier que l'application protège contre les attaques SSRF, en validant ou en assainissant les données non fiables ou les métadonnées de fichiers HTTP, comme les noms de fichiers et les champs de saisie d'URL, utiliser la liste d'autorisation des protocoles, domaines, chemins et ports. | ✓ | ✓ | ✓ | 918 |
-| **5.2.7** | Vérifiez que l'application assainit, désactive ou met en place une isolation (sandbox) pour le contenu scriptable fourni par l'utilisateur (Scalable Vector Graphics - SVG), en particulier en ce qui concerne les XSS résultant de scripts natif au code présent et foreignObject. | ✓ | ✓ | ✓ | 159 |
+| **5.2.7** | Vérifiez que l'application assainit, désactive ou met en place une isolation (sandbox) pour le contenu scriptable fourni par l'utilisateur (Scalable Vector Graphics - SVG), en particulier en ce qui concerne les XSS résultant de scripts natifs au code présent et foreignObject. | ✓ | ✓ | ✓ | 159 |
 | **5.2.8** | Vérifiez que l'application assainit, désactive ou met en sandbox le contenu des scripts ou des modèles d'expression fournis par l'utilisateur, tels que les feuilles de style Markdown, CSS ou XSL, le BBCode ou autres. | ✓ | ✓ | ✓ | 94 |
 
 ## V5.3 Exigences en matière d'encodage de sortie et de prévention des injections