(French Translation): Minors corrections for the french translation

Author: Nounoursdestavernes

editions/2023/fr/0x04-release-notes.md

@@ -9,7 +9,7 @@ Avec une industrie de la sécurité des API plus mature, pour la première fois,
 
 Le OWASP API Security Top 10 2023 est un document de sensibilisation tourné vers l'avenir pour une industrie en constante évolution. Il ne remplace pas les autres TOP 10. Dans cette édition :
 
-* Nous avons combiné l' "Excessive Data Exposure" et le "Mass Assignment" en mettant l'accent sur la cause commune : les échecs de validation de l'autorisation au niveau des propriétés de l'objet.
+* Nous avons combiné l' "Excessive Data Exposure" et le "Mass Assignment" en mettant l'accent sur la cause commune : "Broken Object Property Level Authorization".
 * Nous avons mis davantage l'accent sur la consommation de ressources, plutôt que sur le rythme auquel elles sont épuisées.
 * Nous avons créé une nouvelle catégorie "Unrestricted Access to Sensitive Business Flows" pour aborder de nouvelles menaces, comprenant la plupart de celles qui peuvent être atténuées par le biais du rate limiting.
 * Nous avons ajouté "Unsafe Consumption of APIs" pour aborder quelque chose que nous avons commencé à voir : les attaquants ont commencé à chercher à compromettre les services intégrés de la cible, au lieu de viser directement les API. C'est le bon moment pour commencer à sensibiliser à ce risque croissant.

editions/2023/fr/0x11-t10.md

@@ -2,11 +2,11 @@
 
 | Risque | Description |
 | ------ | ----------- |
-| [API1:2023 - Broken Object Level Authorization][api1] | Les API ont tendance à exposer des points d'accès (endpoints) qui gèrent les identifiants d'objets (OID), créant ainsi une large surface d'attaque sur les contrôles de niveau des objets. Des contrôle d'autorisation doivent être effectuées dans chaque fonction qui accède à une source de données en utilisant un ID fourni par l'utilisateur. |
+| [API1:2023 - Broken Object Level Authorization][api1] | Les API ont tendance à exposer des points d'accès (endpoints) qui manipulent des identifiants d'objets (OID), créant ainsi une large surface d'attaque sur les contrôles d'accès aux objets. Des contrôle d'autorisation doivent être effectuées dans chaque fonction qui accède à une source de données en utilisant un ID fourni par l'utilisateur. |
 | [API2:2023 - Broken Authentication][api2] | Les mécanismes d'authentification sont souvent implémentés de manière incorrecte, permettant aux attaquants de compromettre les jetons (token) d'authentification ou d'exploiter des failles d'implémentation afin d'usurper temporairement ou définitivement l'identité d'autres utilisateurs. L'incapacité d'un système à identifier le client/l'utilisateur compromet la sécurité de l'API dans son ensemble. |
 | [API3:2023 - Broken Object Property Level Authorization][api3] | Cette catégorie combine les anciennes catégories [API3:2019 Excessive Data Exposure][1] et [API6:2019 - Mass Assignment][2], en se concentrant sur la cause commune : le manque de validation ou une validation incorrecte dans le processus d'autorisation au niveau des propriétés de l'objet. Cela conduit à une exposition ou une manipulation d'informations par des parties non autorisées. |
 | [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. D'autres ressources telles que les e-mails/SMS/appels téléphoniques ou la validation biométrique sont mises à disposition par les fournisseurs de services via des intégrations API, moyennant un paiement par requête effectuée. Des attaques réussies peuvent entraîner un déni de service ou une augmentation des coûts opérationnels. |
-| [API5:2023 - Broken Function Level Authorization][api5] | Les politiques de contrôle d'accès complexes avec différentes hiérarchies, groupes et rôles, et une séparation floue entre les fonctions normales et administratives, tendent à entraîner des failles d'autorisation. En exploitant ces problèmes, les attaquants peuvent accéder aux ressources d'autres utilisateurs et/ou aux fonctions administratives. |
+| [API5:2023 - Broken Function Level Authorization][api5] | Les politiques de contrôle d'accès complexes avec différentes hiérarchies, groupes et rôles, et une séparation floue entre les fonctions normales et d'administration, tendent à entraîner des failles d'autorisation. En exploitant ces problèmes, les attaquants peuvent accéder aux ressources d'autres utilisateurs et/ou aux fonctions d'administration. |
 | [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | Les API vulnérables à ce risque exposent un flux métier - tel que l'achat d'un billet ou la publication d'un commentaire - sans compenser l'impact potentiellement néfaste pour l'entreprise si la fonctionnalité est utilisée de manière excessive et automatisée. Cela ne provient pas nécessairement de bugs d'implémentation. |
 | [API7:2023 - Server Side Request Forgery][api7] | Les failles de type SSRF (Server-Side Request Forgery) peuvent survenir lorsqu'une API récupère une ressource distante sans valider l'URI fourni par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. |
 | [API8:2023 - Security Misconfiguration][api8] | Les API et les systèmes qui les supportent contiennent généralement des configurations complexes, destinées à rendre les API plus personnalisables. Les ingénieurs logiciels et DevOps peuvent passer à côté de ces configurations, ou ne pas suivre les meilleures pratiques de sécurité en matière de configuration, ouvrant la porte à différents types d'attaques. |

editions/2023/fr/0xa2-broken-authentication.md

@@ -3,7 +3,7 @@
 | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact |
 | - | - | - |
 | Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation |
-| Le mécanisme d'authentification est une cible facile pour les attaquants car il est exposé à tout le monde. Bien que des compétences techniques plus avancées puissent être nécessaires pour exploiter certaines failles d'authentification, des outils d'exploitation sont généralement disponibles. | Les erreurs de conception des ingénieurs logiciels et en sécurité concernant les limites de l'authentification et la complexité de sa mise en œuvre rendent les problèmes d'authentification courants. Les méthodologies de détection des problèmes d'authentification sont disponibles et faciles à créer. | Les attaquants peuvent prendre le contrôle complet des comptes d'autres utilisateurs du système, lire leurs données personnelles et effectuer des actions sensibles en leur nom. Les systèmes sont peu susceptibles de pouvoir distinguer les actions des attaquants de celles des utilisateurs légitimes. |
+| Le mécanisme d'authentification est une cible facile pour les attaquants car il est exposé à tout le monde. Bien que des compétences techniques plus avancées puissent être nécessaires pour exploiter certaines failles d'authentification, des outils d'exploitation sont généralement disponibles. | Les erreurs de conception commises par les ingénieurs logiciels et en sécurité ou la complexité d'implémentation rendent les problèmes courants pour l'authentification des utilisateurs. Les méthodologies de détection des problèmes d'authentification sont disponibles et faciles à créer. | Les attaquants peuvent prendre le contrôle complet des comptes d'autres utilisateurs du système, lire leurs données personnelles et effectuer des actions sensibles en leur nom. Les systèmes sont peu susceptibles de pouvoir distinguer les actions des attaquants de celles des utilisateurs légitimes. |
 
 
 ## L'API est-elle vulnérable ?
@@ -78,7 +78,7 @@ Comme l'API ne demande pas aux utilisateurs de confirmer leur identité en fourn
 * Assurez-vous de connaître tous les flux possibles pour s'authentifier à l'API (mobile/web/liens profonds qui implémentent l'authentification en un clic/etc.). Demandez à vos ingénieurs quels flux vous avez manqués.
 * Documentez-vous sur vos mécanismes d'authentification. Assurez-vous de comprendre ce qu'ils sont et comment ils sont utilisés. OAuth n'est pas une authentification, pas plus que les clés API.
 * Ne réinventez pas la roue en matière d'authentification, de génération de jetons ou de stockage de mots de passe. Utilisez les standards.
-* Les points d'accès de récupération des informations d'identification/mot de passe oublié doivent être traités comme des points d'accès de connexion en termes de protection contre la force brute, de "rate limiting" et de protections de blocage.
+* Les points d'accès de récupération des informations d'identification/mot de passe oublié doivent être traités comme des points d'accès de connexion. Ils doivent être protégés contre les attaques par la force brute : par le blocage de comptes ou la mise en place de "rate limiting" contraignant.
 * Exigez une ré-authentification pour les opérations sensibles (par exemple, changer l'adresse e-mail du propriétaire du compte/le numéro de téléphone 2FA).
 * Utilisez le [Cheat Sheet d'authentification OWASP][1].
 * Là où c'est possible, mettez en œuvre l'authentification multi-facteurs.

editions/2023/fr/0xa4-unrestricted-resource-consumption.md

@@ -3,7 +3,7 @@
 | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact |
 | - | - | - |
 | Spécifique à l'API : Exploitabilité **Moyenne** | Prévalence **Répandue** : Détection **Facile** | Technique **Grave** : Spécifique à l'organisation |
-| L'exploitation de cette faille nécessite des requêtes API simples. Plusieurs requêtes simultanées peuvent être effectuées à partir d'un seul ordinateur local ou en utilisant des ressources cloud. La plupart des outils automatisés disponibles sont conçus pour provoquer un déni de service (DoS) via des charges de trafic élevées, impactant le taux de service des API. | Il est courant de trouver des API qui ne limitent pas les interactions client ou la consommation de ressources. Écrire et tester avec des requêtes API incluant des paramètres qui contrôlent le nombre de ressources à renvoyer et qui effectuent une analyse de l'état/du temps/de la longueur de la réponse, devraient permettre d'identifier le problème. Il en va de même pour les opérations groupées. Bien que les attaquants n'aient pas de visibilité sur l'impact des coûts, cela peut être déduit en fonction du modèle commercial/tarifaire des fournisseurs de services (par exemple, le fournisseur de services cloud). | L'exploitation peut entraîner un déni de service (DoS) en raison de l'épuisement des ressources, mais elle peut également entraîner une augmentation des coûts opérationnels tels que ceux liés à l'infrastructure en raison d'une demande accrue de CPU, augmentant les besoins de stockage sur le cloud, etc. |
+| L'exploitation de cette faille nécessite des requêtes API simples. Plusieurs requêtes simultanées peuvent être effectuées à partir d'un seul ordinateur local ou en utilisant des ressources cloud. La plupart des outils automatisés disponibles sont conçus pour provoquer un déni de service (DoS) via des charges de trafic élevées, impactant le taux de service des API. | Il est courant de trouver des API qui ne limitent pas les interactions client ou la consommation de ressources. Écrire et tester avec des requêtes API incluant des paramètres qui contrôlent le nombre de ressources à renvoyer et qui effectuent une analyse de l'état/du temps/de la longueur de la réponse, devraient permettre d'identifier le problème. Il en va de même pour les opérations groupées. Bien que les attaquants n'aient pas de visibilité sur l'impact des coûts, cela peut être déduit en fonction du modèle commercial/tarifaire des fournisseurs de services (par exemple, le fournisseur de services cloud). | L'exploitation peut entraîner un déni de service (DoS) en raison de l'épuisement des ressources, mais elle peut également entraîner une augmentation des coûts opérationnels tels que ceux liés à l'infrastructure : en raison d'une demande accrue en CPU, l'augmentation des besoins en stockage sur le cloud, etc. |
 
 ## L'API est-elle vulnérable ?
 
@@ -49,7 +49,7 @@ Host: willyo.net
 }
 ```
 
-Le fournisseur tiers, Willyo, facture 0,05 $ par ce type d'appel.
+Le fournisseur tiers, Willyo, facture 0,05 $ par envoi SMS.
 
 Un attaquant écrit un script qui envoie le premier appel API des dizaines de milliers de fois. Le back-end suit et demande à Willyo d'envoyer des dizaines de milliers de SMS, ce qui conduit l'entreprise à perdre des milliers de dollars en quelques minutes.
 
@@ -71,7 +71,7 @@ POST /graphql
 
 Une fois le téléchargement terminé, l'API génère plusieurs miniatures de tailles différentes basées sur l'image téléchargée. Cette opération graphique consomme beaucoup de mémoire.
 
-L'API met en œuvre une protection traditionnelle de limitation du taux - un utilisateur ne peut pas accéder trop de fois à l'endpoint GraphQL en peu de temps. L'API vérifie également la taille de l'image téléchargée avant de générer des miniatures pour éviter de traiter des images trop grandes.
+L'API met en œuvre une protection traditionnelle de "rate limiting" - un utilisateur ne peut pas accéder trop de fois à l'endpoint GraphQL en peu de temps. L'API vérifie également la taille de l'image téléchargée avant de générer des miniatures pour éviter de traiter des images trop grandes.
 
 Un attaquant peut facilement contourner ces mécanismes, en exploitant la nature flexible de GraphQL :
 
@@ -97,10 +97,10 @@ Quand l'un des fichiers est mis à jour, sa taille augmente à 18 Go. Tous les c
 ## Comment s'en prémunir
 
 * Utilisez une solution qui facilite la limitation de la [mémoire][1], du [CPU][2], du [nombre de redémarrages][3], des descripteurs de fichiers et des processus tels que les conteneurs / le code Serverless (par exemple, les Lambdas).
-* Définissez et appliquez une taille maximale de données sur tous les paramètres et payload entrants, telle que la longueur maximale des chaînes, le nombre maximal d'éléments dans les tableaux et la taille maximale des fichiers téléchargés (qu'ils soient stockés localement ou dans un stockage cloud).
-* Mettez en place une limite sur la fréquence à laquelle un client peut interagir avec l'API dans un intervalle de temps défini (limitation du taux).
-* La limitation du taux doit être ajustée en fonction des besoins de l'entreprise. Certains points d'accès API peuvent nécessiter des politiques plus strictes.
-* Limitez/ralentissez le nombre de fois ou la fréquence à laquelle un seul client/utilisateur API peut exécuter une seule opération (par exemple, valider un OTP, ou demander une récupération de mot de passe sans visiter l'URL à usage unique).
+* Définissez et appliquez une taille maximale de données sur tous les paramètres et payloads entrants, telle que la longueur maximale des chaînes, le nombre maximal d'éléments dans les tableaux et la taille maximale des fichiers téléchargés (qu'ils soient stockés localement ou dans un stockage cloud).
+* Mettez en place une limite sur la fréquence à laquelle un client peut interagir avec l'API dans un intervalle de temps défini (rate limiting).
+* Le "rate limiting" doit être ajustée méticuleusement en fonction des besoins de l'entreprise. Certains points d'accès API peuvent nécessiter des politiques plus strictes.
+* Limitez/ralentissez le nombre de fois ou la fréquence à laquelle un client/utilisateur API défini peut exécuter certaines opérations (par exemple, valider un OTP, ou demander une récupération de mot de passe sans visiter l'URL à usage unique).
 * Ajoutez une validation appropriée côté serveur pour les paramètres de la requête et son contenu, en particulier ceux qui contrôlent le nombre d'enregistrements à renvoyer dans la réponse.
 * Configurez des limites de dépenses pour tous les fournisseurs de services/intégrations API. Lorsque cela n'est pas possible, configurez plutôt des alertes de facturation.