Merge branch 'hotfix/2.4.1'

VERSION

@@ -1 +1 @@
-2.4.0
+2.4.1

editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md

@@ -77,23 +77,24 @@ The mitigation planning should be done in two layers:
 * Engineering - choose the right protection mechanisms to mitigate the business
   risk.
 
-  Some of the protection mechanisms are more simple while others are more
-  difficult to implement. The following methods are used to slow down automated
-  threats:
-
-  * Device fingerprinting: denying service to unexpected client devices (e.g
-    headless browsers) tends to make threat actors use more sophisticated
-    solutions, thus more costly for them
-  * Human detection: using either captcha or more advanced biometric solutions
-    (e.g. typing patterns)
-  * Non-human patterns: analyze the user flow to detect non-human patterns (e.g.
-    the user accessed the "add to cart" and "complete purchase" functions in
-    less than one second)
-  * Consider blocking IP addresses of Tor exit nodes and well-known proxies
-
-  Secure and limit access to APIs that are consumed directly by machines (such
-  as developer and B2B APIs). They tend to be an easy target for attackers
-  because they often don't implement all the required protection mechanisms.
+    Some of the protection mechanisms are more simple while others are more
+    difficult to implement. The following methods are used to slow down
+    automated
+    threats:
+
+    * Device fingerprinting: denying service to unexpected client devices (e.g
+      headless browsers) tends to make threat actors use more sophisticated
+      solutions, thus more costly for them
+    * Human detection: using either captcha or more advanced biometric solutions
+      (e.g. typing patterns)
+    * Non-human patterns: analyze the user flow to detect non-human patterns
+      (e.g. the user accessed the "add to cart" and "complete purchase"
+      functions in less than one second)
+    * Consider blocking IP addresses of Tor exit nodes and well-known proxies
+
+    Secure and limit access to APIs that are consumed directly by machines (such
+    as developer and B2B APIs). They tend to be an easy target for attackers
+    because they often don't implement all the required protection mechanisms.
 
 ## References
 

editions/2023/en/0xa7-server-side-request-forgery.md

@@ -132,10 +132,10 @@ can view the credentials of the cloud environment.
 * Isolate the resource fetching mechanism in your network: usually these
   features are aimed to retrieve remote resources and not internal ones.
 * Whenever possible, use allow lists of:
-  * Remote origins users are expected to download resources from (e.g. Google
-    Drive, Gravatar, etc.)
-  * URL schemes and ports
-  * Accepted media types for a given functionality
+    * Remote origins users are expected to download resources from (e.g. Google
+      Drive, Gravatar, etc.)
+    * URL schemes and ports
+    * Accepted media types for a given functionality
 * Disable HTTP redirections.
 * Use a well-tested and maintained URL parser to avoid issues caused by URL
   parsing inconsistencies.

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

@@ -81,8 +81,8 @@ Furthermore:
   HTTP verbs should be disabled (e.g. HEAD).
 * APIs expecting to be accessed from browser-based clients (e.g., WebApp
   front-end) should, at least:
-  * implement a proper Cross-Origin Resource Sharing (CORS) policy
-  * include applicable Security Headers
+    * implement a proper Cross-Origin Resource Sharing (CORS) policy
+    * include applicable Security Headers
 * Restrict incoming content types/data formats to those that meet the business/
   functional requirements.
 * Ensure all servers in the HTTP server chain (e.g. load balancers, reverse

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

@@ -19,10 +19,11 @@ An API has a "<ins>documentation blindspot</ins>" if:
 
 * The purpose of an API host is unclear, and there are no explicit answers to
   the following questions
-  * Which environment is the API running in (e.g. production, staging, test,
-    development)?
-  * Who should have network access to the API (e.g. public, internal, partners)?
-  * Which API version is running?
+    * Which environment is the API running in (e.g. production, staging, test,
+      development)?
+    * Who should have network access to the API (e.g. public, internal,
+      partners)?
+    * Which API version is running?
 * There is no documentation or the existing documentation is not updated.
 * There is no retirement plan for each API version.
 * The host's inventory is missing or outdated.
@@ -35,10 +36,9 @@ An API has a "<ins>data flow blindspot</ins>" if:
 
 * There is a "sensitive data flow" where the API shares sensitive data with a
   third party and
-  * There is not a business justification or approval of the flow
-  * There is no inventory or visibility of the flow
-  * There is not deep visibility of which type of sensitive data is shared
-
+    * There is not a business justification or approval of the flow
+    * There is no inventory or visibility of the flow
+    * There is not deep visibility of which type of sensitive data is shared
 
 ## Example Attack Scenarios
 
@@ -95,7 +95,6 @@ sells the information for malicious purposes.
   breaking API compatibility or if you need to take the older version out
   quickly and force all clients to move to the latest version.
 
-
 ## References
 
 ### External

editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md

@@ -53,14 +53,14 @@ La planification de mitigation doit être effectuée en deux couches :
 * Business - identifier les flux commerciaux qui pourraient nuire à l'entreprise s'ils "taient utilisés de manière excessive.
 * Ingénierie - choisir les bons mécanismes de protection pour atténuer le risque commercial.
 
-Certains mécanismes de protection sont plus simples tandis que d'autres sont plus difficiles à mettre en œuvre. Les méthodes suivantes sont utilisées pour ralentir les menaces automatisées :
+    Certains mécanismes de protection sont plus simples tandis que d'autres sont plus difficiles à mettre en œuvre. Les méthodes suivantes sont utilisées pour ralentir les menaces automatisées :
 
-* Empreinte de l'appareil : refuser le service aux appareils clients inattendus (par exemple, les navigateurs sans interface graphique) tend à inciter les acteurs malveillants à utiliser des solutions plus sophistiquées, donc plus coûteuses pour eux
-* Détection humaine : utiliser soit un captcha, soit des solutions biométriques plus avancées (par exemple : biométrie par modèles de frappe)
-* Modèles non humains : analyser le flux de l'utilisateur pour détecter les modèles non humains (par exemple, l'utilisateur a accédé aux fonctions "ajouter au panier" et "compléter l'achat" en moins d'une seconde)
-* Considérer le blocage des adresses IP des nœuds de sortie Tor et des proxies bien connus
+    * Empreinte de l'appareil : refuser le service aux appareils clients inattendus (par exemple, les navigateurs sans interface graphique) tend à inciter les acteurs malveillants à utiliser des solutions plus sophistiquées, donc plus coûteuses pour eux
+    * Détection humaine : utiliser soit un captcha, soit des solutions biométriques plus avancées (par exemple : biométrie par modèles de frappe)
+    * Modèles non humains : analyser le flux de l'utilisateur pour détecter les modèles non humains (par exemple, l'utilisateur a accédé aux fonctions "ajouter au panier" et "compléter l'achat" en moins d'une seconde)
+    * Considérer le blocage des adresses IP des nœuds de sortie Tor et des proxies bien connus
 
-Sécurisez et limitez l'accès aux API qui sont consommées directement par des machines (comme les API de développeur et B2B). Elles sont souvent une cible facile pour les attaquants car elles n'implémentent souvent pas tous les mécanismes de protection nécessaires.
+    Sécurisez et limitez l'accès aux API qui sont consommées directement par des machines (comme les API de développeur et B2B). Elles sont souvent une cible facile pour les attaquants car elles n'implémentent souvent pas tous les mécanismes de protection nécessaires.
 
 ## Références 
 

editions/2023/fr/0xa7-server-side-request-forgery.md

@@ -110,9 +110,9 @@ Puisque l'application affiche la réponse de la requête de test, l'attaquant pe
 
 * Isoler le mécanisme de récupération des ressources dans votre réseau : ces fonctionnalités sont généralement destinées à récupérer des ressources distantes et non internes.
 * Chaque fois que possible, utilisez des listes d'autorisation :
-  * Les origines distantes à partir desquelles les utilisateurs sont censés télécharger des ressources (par exemple, Google Drive, Gravatar, etc.)
-  * Les schémas d'URL et les ports
-  * Les types de médias acceptés pour une fonctionnalité donnée
+    * Les origines distantes à partir desquelles les utilisateurs sont censés télécharger des ressources (par exemple, Google Drive, Gravatar, etc.)
+    * Les schémas d'URL et les ports
+    * Les types de médias acceptés pour une fonctionnalité donnée
 * Désactivez les redirections HTTP.
 * Utilisez un analyseur d'URL bien testé et maintenu pour éviter les problèmes causés par des incohérences d'analyse d'URL.
 * Validez et assainissez toutes les données d'entrée fournies par le client.

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

@@ -56,8 +56,8 @@ De plus :
 * Assurez-vous que toutes les communications API du client vers le serveur API et tout composant en aval/amont se font sur un canal de communication chiffré (TLS), qu'il s'agisse d'une API interne ou publique.
 * Soyez spécifique sur les verbes HTTP par lesquels chaque API peut être accédée : tous les autres verbes HTTP devraient être désactivés (par exemple, HEAD).
 * Les API s'attendant à être accessibles depuis des clients basés sur un navigateur (par exemple, une interface WebApp) devraient, au moins :
-  * implémenter une politique Cross-Origin Resource Sharing (CORS) appropriée
-  * inclure les en-têtes de sécurité applicables
+    * 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 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.

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

@@ -12,21 +12,23 @@ Les API modernes sont souvent exposées à des risques de sécurité en raison d
 Faire fonctionner plusieurs versions d'une API nécessite des ressources de gestion supplémentaires de la part du fournisseur de l'API et augmente la surface d'attaque.
 
 Une API a un "<ins>angle mort de la documentation</ins>" si :
+
 * Le but de l'hôte de l'API n'est pas clair, et il n'y a pas de réponses explicites aux questions suivantes
-  * Dans quel environnement l'API fonctionne-t-elle (par exemple, production, staging, test, développement) ?
-  * Qui devrait avoir accès au réseau de l'API (par exemple, public, interne, partenaires) ?
-  * Quelle version de l'API est en cours d'exécution ?
+    * Dans quel environnement l'API fonctionne-t-elle (par exemple, production, staging, test, développement) ?
+    * Qui devrait avoir accès au réseau de l'API (par exemple, public, interne, partenaires) ?
+    * Quelle version de l'API est en cours d'exécution ?
 * Il n'y a pas de documentation ou la documentation existante n'est pas mise à jour.
 * Il n'y a pas de plan de retraite pour chaque version de l'API.
 * L'inventaire de l'hôte est manquant ou obsolète.
 
 La visibilité et l'inventaire des flux de données sensibles jouent un rôle important dans le cadre d'un plan de réponse aux incidents, au cas où une violation se produirait du côté du tiers.
 
 Une API a un "<ins>angle mort du flux de données</ins>" si :
+
 * Il y a un "flux de données sensible" où l'API partage des données sensibles avec un tiers et
-  * Il n'y a pas de justification commerciale ou d'approbation du flux
-  * Il n'y a pas d'inventaire ou de visibilité du flux
-  * Il n'y a pas de visibilité approfondie sur le type de données sensibles partagées
+    * Il n'y a pas de justification commerciale ou d'approbation du flux
+    * Il n'y a pas d'inventaire ou de visibilité du flux
+    * Il n'y a pas de visibilité approfondie sur le type de données sensibles partagées
 
 
 ## Exemple de scénarios d'attaque