| API1:2019 - Broken Object Level Authorization |
Les API ont tendance à exposer des points d'accès (endpoints) qui gèrent les identifiants d'objets (OID), créant une large surface d'attaque des contrôles de niveaux d'accès. Des contrôles d'autorisation doivent être effectués pour toute fonction qui accède à une source de données à partir d'entrées fournies par un utilisateur. |
| API2:2019 - Broken User Authentication |
Les mécanismes d'authentification sont souvent implémentés incorrectement, permettant à des attaquants de compromettre des jetons (tokens) d'authentification ou d'exploiter des failles d'implémentation afin d'endosser temporairement ou de manière permanente l'identité d'autres utilisateurs. L'incapacité, pour un système, à identifier le client / utilisateur de manière fiable compromet la sécurité de l'API dans son ensemble. |
| API3:2019 - Excessive Data Exposure |
En effectuant des implémentations génériques rapides, les développeurs ont tendance à exposer tous les attributs des objets sans prendre en considération leur confidentialité individuelle, se reposant sur les clients d'API pour effectuer un filtrage des données avant présentation à l'utilisateur. |
| API4:2019 - Lack of Resources & Rate Limiting |
Bien souvent, les API n'imposent pas de restrictions sur la taille ou le nombre de ressources qui peuvent être requises par le client / l'utilisateur. Ceci impacte non seulement la performance du serveur d'API, aboutissant à un Déni de Service (DoS), mais cela constitue aussi une porte ouverte pour des failles d'authentification par force brute. |
| API5:2019 - Broken Function Level Authorization |
Les politiques de contrôle d'accès complexes avec des hiérarchies, groupes et rôles différents, et la séparation non claire entre les fonctions normales et d'administration tendent à occasionner des failles d'authentification. En exploitant ces problèmes, les attaquants parviennent à accéder aux ressources d'autres utilisateurs et / ou aux fonctions d'administration. |
| API6:2019 - Mass Assignment |
La connexion de données fournies par le client (ex : JSON) aux modèles de données sans filtrage approprié par une liste de validation conduit généralement à l'assignation massive. En devinant les attributs des objets, en explorant les autres points d'accès de l'API, en lisant la documentation ou en incluant des attributs supplémentaires dans la charge utile (payload) des requêtes, les attaquants parviennent à modifier les attributs d'objets qu'ils ne devraient pas pouvoir modifier. |
| API7:2019 - Security Misconfiguration |
Une mauvaise configuration de sécurité est souvent le résultat de configurations par défauts non sécurisées, de configurations incomplètes ou ad-hoc, de stockages ouverts dans le cloud, d'en-têtes HTTP mal configurés, de méthodes HTTP non nécessaires, de partage de ressources intersites permissives (CORS), et de messages d'erreurs verbeux contenant des informations sensibles. |
| API8:2019 - Injection |
Les failles d'injection telles que SQL, NoSQL, injection de commandes, etc, se produisent lorsque des données non fiables sont transmises à un interpréteur comme partie d'une commande ou d'une requête. Les données malveillantes de l'attaquant peuvent tromper l'interpréteur et lui faire exécuter des commandes non prévues ou accéder à des données sans disposer des autorisations nécessaires. |
| API9:2019 - Improper Assets Management |
Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, rendant très importante la nécessité d'une documentation appropriée et actualisée. Un inventaire précis des hôtes et des versions d'API déployées joue également un rôle important pour prévenir les problèmes tels que les versions obsolètes d'API et l'exposition des points de déboggage. |
| API10:2019 - Insufficient Logging & Monitoring |
L'insuffisance de logging et de monitoring, couplée à une intégration insuffisante ou absente à la réponse aux incidents, permet aux attaquants de poursuivre leurs attaques sur les systèmes, de s'y maintenir de manière persistante, et de rebondir sur d'autres systèmes pour compromettre, extraire ou détruire des données. La plupart des études de failles montrent que le temps nécessaire pour détecter une intrusion est supérieur à 200 jours, typiquement découverte par des tiers externes plutôt que par des processus ou un monitoring interne. |