OWASP API Security Top 10: 0x11 t10

# OWASP Top 10 API Security Risks – 2023

| Risque | Description |
| ------ | ----------- |
| [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 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. |
| [API9:2023 - Improper Inventory Management][api9] | Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, ce qui rend une documentation propre et à jour très importante. Un inventaire correct des hôtes et des versions d'API déployées est également important pour atténuer les problèmes tels que les versions d'API obsolètes et les points d'accès de débuggage exposés. |
| [API10:2023 - Unsafe Consumption of APIs][api10] | Les développeurs ont tendance à faire plus confiance aux données reçues des API tierces qu'aux entrées des utilisateurs, et adoptent donc souvent des normes de sécurité plus faibles. Afin de compromettre les API, les attaquants s'attaquent aux services tiers intégrés plutôt que de tenter de compromettre directement l'API cible. |

[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/
[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/
[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/
[api1]: 0xa1-broken-object-level-authorization.md
[api2]: 0xa2-broken-authentication.md
[api3]: 0xa3-broken-object-property-level-authorization.md
[api4]: 0xa4-unrestricted-resource-consumption.md
[api5]: 0xa5-broken-function-level-authorization.md
[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md
[api7]: 0xa7-server-side-request-forgery.md
[api8]: 0xa8-security-misconfiguration.md
[api9]: 0xa9-improper-inventory-management.md
[api10]: 0xaa-unsafe-consumption-of-apis.md