Merge branch 'translation/fr' of github.com:Nounoursdestavernes/API-Security into translation/fr

Author: Nounoursdestavernes

editions/2023/fr/0xa8-security-misconfiguration.md

@@ -59,7 +59,7 @@ De plus :
   * implémenter une politique Cross-Origin Resource Sharing (CORS) appropriée
   * inclure les en-têtes de sécurité applicables
 * Restreignez les types de contenu/format de données entrants à ceux qui répondent aux exigences commerciales/fonctionnelles.
-* Assurez-vous que tous les serveurs dans la chaîne du serveur HTTP (par exemple, les équilibreurs de charge, les proxies inversés et avant, et les serveurs en aval) traitent les requêtes entrantes de manière uniforme pour éviter les problèmes de désynchronisation.
+* Assurez-vous que tous les serveurs dans la chaîne du serveur HTTP (par exemple, les équilibreurs de charge, les proxies et les proxies inverses, ainsi que les serveurs back-end) traitent les requêtes entrantes de manière uniforme pour éviter les problèmes de désynchronisation.
 * Lorsque cela est applicable, définissez et appliquez tous les schémas de charge utile de réponse API, y compris les réponses d'erreur, pour empêcher les traces d'exception et d'autres informations précieuses d'être renvoyées aux attaquants.
 
 ## Références

editions/2023/fr/0xa9-improper-inventory-management.md

@@ -45,13 +45,13 @@ Une société de conseil crée une application malveillante et parvient à obten
 
 ## Comment s'en prémunir ?
 
-* Inventoriez tous les <ins>hôtes API</ins> et documentez les aspects importants de chacun d'eux, en mettant l'accent sur l'environnement de l'API (par exemple, production, staging, test, développement), qui devrait avoir accès au réseau de l'hôte (par exemple, public, interne, partenaires) et la version de l'API.
+* Inventoriez tous les <ins>hôtes API</ins> et documentez les aspects importants de chacun d'eux, en mettant l'accent sur l'environnement de l'API (par exemple, production, staging, test, développement), qui devrait avoir accès, en réseau, à l'hôte (par exemple, public, interne, partenaires) et la version d'API.
 * Inventoriez les <ins>services intégrés</ins> et documentez les aspects importants tels que leur rôle dans le système, les données échangées (flux de données) et leur sensibilité.
 * Documentez tous les aspects de votre API tels que l'authentification, les erreurs, les redirections, la limitation du taux, la politique de partage des ressources entre origines (CORS) et les points d'accès, y compris leurs paramètres, requêtes et réponses.
 * Générez automatiquement la documentation en adoptant des normes ouvertes. Incluez la génération de documentation dans votre pipeline CI/CD.
 * Rendez la documentation de l'API disponible uniquement aux personnes autorisées à utiliser l'API.
-* Utilisez des mesures de protection externes telles que des solutions de sécurité API spécifiques pour toutes les versions exposées de vos API, pas seulement pour la version de production actuelle.
-* Évitez d'utiliser des données de production avec des déploiements d'API non productifs. Si cela est inévitable, ces points d'accès doivent bénéficier du même traitement de sécurité que les points d'accès de production.
+* Utilisez des mesures de protection externes telles que des solutions de sécurité spécifiques aux APIs pour toutes les versions exposées de vos API, pas seulement pour la version de production.
+* Évitez d'utiliser des données de production avec des déploiements d'API hors production. Si cela est inévitable, ces points d'accès doivent bénéficier du même traitement de sécurité que les points d'accès de production.
 * Lorsque les nouvelles versions des API incluent des améliorations de sécurité, effectuez une analyse des risques pour informer des actions de mitigation requises pour les anciennes versions. Par exemple, s'il est possible de rétroporter les améliorations sans casser la compatibilité de l'API plus ancienne ou si vous devez retirer rapidement l'ancienne version et forcer tous les clients à passer à la dernière version.
 
 

editions/2023/fr/0xaa-unsafe-consumption-of-apis.md

@@ -3,15 +3,15 @@
 | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact |
 | - | - | - |
 | Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Moyenne** | Technique **Grave** : Spécifique à l'organisation |
-| Exploiter ce problème nécessite que les attaquants identifient et compromettent potentiellement d'autres API/services avec lesquels l'API cible est intégrée. Habituellement, ces informations ne sont pas publiquement disponibles ou l'API/service intégré n'est pas facilement exploitable. | Les développeurs ont tendance à faire confiance et ne pas vérifier les points d'accès qui interagissent avec des API/services externes ou tiers, en se basant sur des exigences de sécurité plus faibles telles que celles concernant la sécurité du transport, l'authentification/l'autorisation, et la validation et la désinfection des entrées. Les attaquants doivent identifier les services avec lesquels l'API cible s'intègre (sources de données) et, éventuellement, les compromettre. | L'impact varie en fonction de ce que l'API cible fait avec les données extraites. L'exploitation réussie peut entraîner une exposition d'informations sensibles à des acteurs non autorisés, de nombreux types d'injections, ou un déni de service. |
+| Exploiter ce problème nécessite que les attaquants identifient et compromettent potentiellement d'autres APIs/services avec lesquels l'API cible est intégrée. Habituellement, ces informations ne sont pas publiquement disponibles ou l'API/service intégré n'est pas facilement exploitable. | Les développeurs ont tendance à faire confiance et ne pas vérifier les points d'accès qui interagissent avec des API/services externes ou tiers, en se basant sur des exigences de sécurité plus faibles telles que celles concernant la sécurité du transport, l'authentification/l'autorisation et la validation des entrées. Les attaquants doivent identifier les services avec lesquels l'API cible s'intègre (sources de données) et, éventuellement, les compromettre. | L'impact varie en fonction de ce que l'API cible fait avec les données extraites. L'exploitation réussie peut entraîner une exposition d'informations sensibles à des acteurs non autorisés, de nombreux types d'injections, ou un déni de service. |
 
 ## L'API est-elle vulnérable ?
 
-Les développeurs ont tendance à faire confiance aux données reçues des API tierces plus qu'aux entrées utilisateur. Cela est particulièrement vrai pour les API proposées par des entreprises bien connues. En raison de cela, les développeurs ont tendance à adopter des normes de sécurité plus faibles, par exemple en ce qui concerne la validation et la désinfection des entrées.
+Les développeurs ont tendance à faire confiance aux données reçues des API tierces plus qu'aux entrées utilisateur. Cela est particulièrement vrai pour les API proposées par des entreprises bien connues. En raison de cela, les développeurs ont tendance à adopter des normes de sécurité plus faibles, par exemple en ce qui concerne la validation des entrées et l'analyse en vu de caractères autorisés ou non en entrée (effacés ou échappés).
 
 L'API peut être vulnérable si :
 * Elle interagit avec d'autres API sur un canal non chiffré ;
-* Elle ne valide pas et ne désinfecte pas correctement les données collectées auprès d'autres API avant de les traiter ou de les transmettre à des composants en aval ;
+* Elle ne valide/filtre pas correctement les données collectées auprès d'autres API avant de les traiter ou de les transmettre à des composants en aval ;
 * Elle suit aveuglément les redirections ;
 * Elle ne limite pas le nombre de ressources disponibles pour traiter les réponses des services tiers ;
 * Elle n'implémente pas de délais d'attente pour les interactions avec les services tiers.
@@ -54,7 +54,7 @@ Maintenant, lorsqu'une intégration d'une application attaquée est effectuée a
 
 * Lors de l'évaluation des fournisseurs de services, évaluez leur posture de sécurité API.
 * Assurez-vous que toutes les interactions API se font sur un canal de communication sécurisé (TLS).
-* Validez toujours et désinfectez correctement les données reçues des API intégrées avant de les utiliser.
+* Validez toujours et épurez correctement les données reçues des API intégrées avant de les utiliser.
 * Maintenez une liste blanche des emplacements bien connus vers lesquels les API intégrées peuvent rediriger les vôtres : ne suivez pas aveuglément les redirections.
 
 

editions/2023/fr/0xb1-next-devsecops.md

@@ -1,6 +1,6 @@
 # Perspectives pour les DevSecOps
 
-En raison de leur importance dans les architectures d'applications modernes, la construction d'API sécurisées est cruciale. La sécurité ne peut être négligée et doit faire partie de tout le cycle de développement. Scanner et tester la pénétration une fois par an ne suffit plus.
+En raison de leur importance dans les architectures d'applications modernes, la construction d'API sécurisées est cruciale. La sécurité ne peut être négligée et doit faire partie de tout le cycle de développement. Scanner et réaliser des tests de pénétration une fois par an ne suffit plus.
 
 Les DevSecOps devraient rejoindre l'effort de développement, facilitant les tests de sécurité continus tout au long du cycle de vie du logiciel. Votre objectif devrait être d'améliorer le pipeline de développement avec l'automatisation de la sécurité, sans impacter la vitesse de développement.