En quoi la sécurité des API est-elle différente de la sécurité générale des applications ?

Publié: 2023-07-19

Bien que parfois confondues, la sécurité des applications et la sécurité des API sont deux disciplines distinctes. La sécurité des applications fait référence à la sécurisation d'applications entières, tandis que la sécurité des API fait référence à la sécurisation des API que les organisations utilisent pour connecter des applications et échanger des données. En tant que telles, les organisations doivent adopter des approches différentes envers les deux disciplines.

Qu’est-ce que la sécurité des applications ?

La sécurité des applications (AppSec) utilise des pratiques d'autorisation, de cryptage et de codage sécurisé pour protéger les données et les systèmes contre les cyberattaques. Les organisations mettant en œuvre AppSec réduisent le risque de violation de données, protègent les données sensibles et garantissent que leurs applications sont conformes aux normes de l'industrie.

L'ISACA définit les cinq composants critiques des programmes AppSec comme :

  1. La sécurité dès la conception
  2. Test de code sécurisé
  3. Nomenclature du logiciel
  4. Formation et sensibilisation à la sécurité
  5. Passerelles de sécurité WAF et API et développement de règles

Qu'est-ce que la sécurité des API ?

La sécurité des API, ou interface de programmation d'applications, protège les API des cyberattaques. L'utilisation des API a explosé ces dernières années, offrant aux organisations des opportunités d'innovation en permettant les transferts de données entre applications. Malheureusement, à mesure que l’utilisation des API a augmenté, les attaques lancées contre elles ont également augmenté. Une étude de Salt Security a révélé que les attaques contre les API ont augmenté de 400 % entre juin et décembre 2022.

Menaces de sécurité des applications et des API

Comprendre la différence entre la sécurité AppSec et la sécurité des API nécessite de comprendre les principales menaces de chaque discipline. Heureusement, l'OWASP, une organisation à but non lucratif cherchant à améliorer la sécurité des logiciels, fournit une liste complète des menaces les plus importantes pour la sécurité des applications et des API. Connues sous le nom de OWASP Top Ten, ces listes rassemblent des informations provenant de la communauté mondiale d'experts en sécurité de l'OWASP pour identifier les menaces les plus critiques pour les applications et les API.

Il est intéressant de noter que même si l'OWASP a publié la liste des dix principaux risques de sécurité des applications Web en 2003, il n'a publié la liste des dix principaux risques de sécurité des API qu'à la fin de 2019. Cet écart représente une autre différence clé entre la sécurité des applications et celle des API : la sécurité des applications est un problème bien établi. discipline faisant l'objet de nombreuses recherches et qui a connu de nombreuses étapes d'évolution, alors que la sécurité des API ne l'est pas.

Bien que nous n'ayons pas le temps de procéder à une analyse approfondie, il vaut la peine d'examiner brièvement chaque liste pour voir en quoi elles diffèrent, ce qui devrait éclairer la manière dont les organisations abordent la sécurité AppSec et API.

Les dix principaux risques de sécurité des applications de l’OWASP (2021)

  1. Contrôle d'accès brisé – Lorsqu'un utilisateur non autorisé peut accéder à des informations ou à des systèmes restreints
  2. Échecs cryptographiques – Lorsqu'un tiers expose des données sensibles sans intention spécifique en raison d'un manque ou de défauts de cryptographie.
  3. Injection – Lorsqu'un attaquant tente d'envoyer des données à une application d'une manière qui modifiera la signification des commandes envoyées à un interprète.
  4. Conception non sécurisée – Risques liés aux défauts d’architecture et de conception
  5. Mauvaise configuration de la sécurité – Lorsque les équipes de sécurité configurent de manière inexacte ou laissent les contrôles de sécurité non sécurisés.
  6. Composants vulnérables et obsolètes – Lorsque les organisations laissent des composants sans correctifs
  7. Échecs d’identification et d’authentification (c’est-à-dire authentification brisée) – Lorsque les applications sont vulnérables aux attaques d’authentification
  8. Défaillances d’intégrité des logiciels et des données – Lorsque le code et l’infrastructure ne parviennent pas à protéger contre les violations d’intégrité
  9. Échecs de journalisation et de surveillance de sécurité (nee journalisation et surveillance insuffisantes) – Lorsque les organisations ne parviennent pas à détecter les violations de données en raison de procédures de journalisation et de surveillance inadéquates.
  10. Forgerie de requêtes côté serveur – Lorsque des attaquants trompent les applications en leur faisant envoyer une requête contrefaite vers une destination inattendue, même lorsqu'elles sont protégées par un pare-feu, un VPN ou un autre type de liste de contrôle d'accès réseau (ACL).

Les dix principaux risques de sécurité des API de l'OWASP (2023)

  1. Autorisation au niveau de l'objet brisé – Lorsqu'un objet API (par exemple, des bases de données ou des fichiers) ne dispose pas de contrôles d'autorisation appropriés, accordant l'accès aux utilisateurs non autorisés.
  2. Authentification brisée – Lorsque les ingénieurs logiciels et de sécurité comprennent mal les limites de l'authentification API et comment la mettre en œuvre
  3. Autorisation au niveau de la propriété d'objet brisé – Une combinaison d'exposition excessive de données et d'affectation massive : lorsque les attaquants exploitent un verrou ou une autorisation inappropriée au niveau de la propriété de l'objet.
  4. Consommation de ressources illimitée – La satisfaction des requêtes API nécessite de la bande passante réseau, du processeur, de la mémoire et du stockage. Les fournisseurs de services mettent à disposition d'autres ressources telles que les e-mails/SMS/appels téléphoniques ou la validation biométrique via des intégrations API et payées à la demande. Des attaques réussies peuvent entraîner un déni de service ou une augmentation des coûts opérationnels.
  5. L'autorisation au niveau de la fonction brisée implique que les attaquants envoient des appels d'API légitimes aux points de terminaison d'API exposés.
  6. Accès illimité aux flux commerciaux sensibles – Les API vulnérables à ce risque exposent un flux commercial – comme l'achat d'un ticket ou la publication d'un commentaire – sans compenser la manière dont la fonctionnalité pourrait nuire à l'entreprise si elle était utilisée de manière excessive et automatisée ; cela ne vient pas nécessairement de bugs d'implémentation.
  7. Forgerie de requête côté serveur – Lorsqu'une API récupère une ressource distante sans valider l'URI fourni par l'utilisateur ; permettant à un attaquant de contraindre l'application à envoyer une requête contrefaite vers une destination inattendue, même lorsqu'elle est protégée par un pare-feu ou un VPN.
  8. Mauvaise configuration de la sécurité – Les API et les systèmes qui les prennent en charge contiennent généralement des configurations complexes pour les rendre plus personnalisables. Les ingénieurs logiciels et DevOps peuvent manquer ces configurations ou ne pas suivre les meilleures pratiques de sécurité en matière de configuration, ouvrant ainsi la porte à différents types d'attaques.
  9. Mauvaise gestion des stocks – Les API exposent plus de points de terminaison que les applications Web traditionnelles, ce qui rend importante une documentation appropriée et mise à jour. Un inventaire adéquat des hôtes et des versions d'API déployées est également essentiel pour atténuer les problèmes tels que les versions d'API obsolètes et les points de terminaison de débogage exposés.
  10. Consommation dangereuse des API – Les développeurs ont tendance à faire davantage confiance aux données reçues d’API tierces qu’aux entrées des utilisateurs et à adopter des normes de sécurité plus faibles. Pour compromettre les API, les attaquants s'attaquent aux services tiers intégrés au lieu d'essayer de compromettre directement l'API cible.

Comme vous pouvez le constater, malgré certains chevauchements, les applications et les API sont principalement soumises à des menaces différentes et uniques, et les organisations doivent réagir en conséquence. La principale différence entre les deux listes est que les organisations peuvent atténuer tous les risques critiques associés à la sécurité des applications grâce à des outils et techniques de sécurité traditionnels et polyvalents, mais la sécurité des API est différente.

La sécurité des API est un problème très moderne qui nécessite une solution tout aussi moderne. Les organisations ne peuvent pas s’attendre à ce que les outils qu’elles utilisent pour protéger leurs applications et autres actifs répondent à la tâche de sécurisation des API. La sécurité des API nécessite des outils de sécurité spécifiques aux API ; les méthodes de protection traditionnelles telles que les passerelles API et les pare-feu d'applications Web (WAF) ne vont pas assez loin.