Pourquoi la sécurité des API est une menace à croissance rapide pour les entreprises axées sur les données

Alors que les entreprises axées sur les données dépendent fortement de leur architecture d’application logicielle, les interfaces de programmation d’applications (API) occupent une place importante. Les API ont en fait changé la façon dont les applications Web sont utilisées, car elles facilitent les pipelines d’interaction entre plusieurs services. Les développeurs peuvent intégrer toute innovation moderne à leur architecture en utilisant des API, ce qui est extrêmement bénéfique pour inclure les fonctionnalités dont un consommateur a besoin.

Par nature, les API sont susceptibles d’exposer la logique de l’application et des informations sensibles telles que les informations personnelles identifiables (PII), ce qui en fait une cible facile pour les agresseurs. Fréquemment disponibles sur les réseaux publics (accessibles de n’importe où), les API sont généralement bien documentées et peuvent être rapidement rétro-conçues par des acteurs malveillants. Ils sont également sensibles aux événements de rejet de service (DDoS).

Les fuites de données les plus importantes sont dues à des API défectueuses, sensibles ou piratées, qui peuvent révéler des données médicales, financières et personnelles au public. De plus, de nombreuses attaques peuvent se produire si une API n’est pas correctement protégée, ce qui fait de la sécurité des API un élément vital pour les services basés sur les données aujourd’hui.

Pourquoi la sécurité des API est vitale

Le développement des API a a en fait astronomiquement augmenté au cours des deux dernières années, soutenue par l’amélioration numérique et sa fonction principale dans les applications mobiles et le développement de l’IdO. Une telle croissance et une variété d’attaques possibles rendent la sécurité des API extrêmement vitale.

Comme les microservices et les architectures sans serveur sont en fait devenus plus répandus, les attaques incluent le contournement de l’application côté client pour perturber le fonctionnement d’une application pour d’autres utilisateurs ou de violer des informations personnelles. Les API cassées, exposées ou piratées peuvent également entraîner des violations du système backend.

Dans son rapport sur la sécurité et la gestion des API [abonnement requis], Gartner prévoit que d’ici 2023, les abus d’API passeront du vecteur d’attaque irrégulier au vecteur d’attaque le plus régulier, entraînant des violations de données pour les applications Web d’entreprise, et d’ici 2025 , plus de 50 % des vols de données seront dus à des API non sécurisées.

« Chez Gartner, nous discutons régulièrement avec des entreprises qui ont subi des violations de leurs API », a déclaré Mark O’Neill, analyste VP chez Gartner, à VentureBeat. « Les API sont particulièrement sensibles en raison du fait que de nombreux groupes de sécurité sont moins compétents en matière de protection des API. Cela est particulièrement préoccupant pour les types d’API plus récents tels que GraphQL. »

Compte tenu de la fonction vitale qu’elles jouent dans le changement numérique et de l’accès aux données et aux systèmes délicats qu’elles fournissent, les API nécessitent désormais une méthode dédiée à la sécurité et à la conformité.

La sécurité des API par rapport à l’application sécurité

La sécurité de l’API se concentre sur la protection de cette couche d’application et sur ce qui peut arriver si un pirate malveillant communique directement avec l’API. La sécurité des API implique également la mise en œuvre de techniques et de procédures pour atténuer les vulnérabilités et les risques de sécurité.

Lorsque des informations délicates sont déplacées via l’API, une API protégée peut garantir la confidentialité du message en le mettant à la disposition des applications, des utilisateurs et des serveurs avec les approbations appropriées. Il garantit également l’intégrité du contenu en validant que les détails n’ont pas été modifiés après la livraison.

« Toute organisation qui attend avec impatience le changement numérique devrait utiliser des API pour décentraliser les applications et en même temps offrir des services intégrés. Pour cette raison, La sécurité des API doit figurer parmi les principaux domaines prioritaires », a déclaré Muralidharan Palanisamy, responsable des services principaux chez AppViewX.

Parlant de la différence entre la sécurité des API et la sécurité des applications de base, Palanisamy a déclaré que la sécurité des applications est similaire à la sécurisation de la porte principale, qui nécessite des contrôles robustes pour éviter les intrus. Dans le même temps, la sécurité des API consiste à protéger les fenêtres et la cour.

« Un point faible dans de tels emplacements affectera l’application. La sécurité de l’API, par essence, est un sous-ensemble de la sécurité complète de l’application sans laquelle l’application dans son ensemble ne peut pas être protégée », a-t-il déclaré.

Erez Yalon, vice-président de l’étude de recherche sur la sécurité chez Checkmarx, déclare que la sécurité des API n’est pas différente de l’appsec conventionnelle, mais qu’elle inclut plus d’emplacements dont les entreprises doivent tenir compte.

« L’architecture centrée sur l’API a plus de points de terminaison qu’un adversaire potentiel peut tenter d’abuser ; nous appelons cela la ‘croissance de la surface d’attaque' », a-t-il déclaré. « De plus, la manière dont les données sont transférées et partagées via les API simplifie l’exposition involontaire d’informations délicates aux regards indiscrets. »

Yalon a déclaré que les API pourraient être rendues plus sûres lorsque la sécurité est prise en compte dès l’étape initiale et la toute première ligne de code composée, au lieu d’être ajoutée en tant que couche supplémentaire plus tard dans le jeu.

« Chaque point de terminaison d’API doit être documenté, et les entreprises doivent avoir des normes claires sur l’abandon des API anciennes et inutilisées. S’assurer qu’une SBOM [facture logicielle] mise à jour facilite les choses », a déclaré Yalon.

Vulnérabilités et attaques importantes des API

Les API se sont rapidement imposées comme l’approche privilégiée pour structurer les applications modernes, en particulier pour les appareils mobiles et l’Internet des objets (IoT). Néanmoins, face aux approches de développement d’applications en constante évolution et aux pressions de l’innovation, certaines entreprises ont encore besoin de saisir complètement les risques potentiels associés à la mise à disposition de leurs API au grand public. Avant la mise en œuvre publique, les services doivent faire attention à ces erreurs de sécurité typiques :

• Défauts d’authentification : De nombreuses API refusent les demandes d’état d’authentification d’un utilisateur authentique. Un agresseur peut reproduire les demandes d’API en exploitant ces pénuries par diverses méthodes, consistant en le piratage de session et l’agrégation de comptes.

• Manque de cryptage : Beaucoup d’API n’ont pas de couches de chiffrement robustes entre le client et le serveur de l’API. En raison de ces défauts, les agresseurs peuvent intercepter des transactions d’API non cryptées ou mal protégées, voler des données sensibles ou modifier les informations de transaction.

• Sécurité défectueuse des terminaux : Comme la majorité des appareils IoT et des outils de microservices sont créés pour interagir avec le serveur via un canal API, les pirates tentent d’obtenir contrôlez-les via les points de terminaison IoT. Cela peut fréquemment reséquencer la commande de l’API, entraînant une violation de données.

Défis existants en matière de sécurité des API

Selon Yannick Bedard, responsable du filtrage des pénétrations, IBM Security X-Force Red, parmi les difficultés existantes dans la sécurité des API, est leur évaluation de la sécurité, car les flux de raisonnement planifiés peuvent être difficiles à comprendre et à vérifier s’ils ne sont pas clairement définis.

« Dans une application Web, ces flux rationnels sont conviviaux grâce à l’utilisation de l’interface utilisateur Web, mais dans une API, il peut être plus difficile de détailler ces flux de travail », a déclaré Bedard à VentureBeat. « Cela peut conduire à un filtrage de sécurité qui passe à côté de vulnérabilités qui peuvent, à leur tour, être exploitées par des adversaires. »

Bedard a déclaré qu’au fur et à mesure que la canalisation des API devient de plus en plus complexe, il se pose fréquemment des questions sur le service responsable de quel élément de sécurité et à quel moment les données sont considérées comme « propres ».

« Il est courant que les services s’appuient naturellement sur les informations provenant d’autres API comme ordonnées, juste pour qu’elles finissent par ne pas être efficacement stérilisées », a-t-il déclaré.

Bernard dit qu’un exemple de cela était la découverte initiale de la vulnérabilité Log4J, où la plupart des entreprises se concentraient principalement sur ce qu’elles avaient directement accès à Internet.

« Des informations nuisibles finiraient par être transmises aux API principales, souvent derrière de nombreux autres services. Ces API seraient, à leur tour, vulnérables et pourraient fournir à l’agresseur une première emprise sur l’organisation », a-t-il déclaré.

« Le principal défi est la découverte, car de nombreux groupes de sécurité ne sont tout simplement pas sûrs du nombre d’API dont ils disposent », a déclaré Sandy Carielli, expert principal chez Forrester.

Carielli a déclaré que de nombreuses équipes publient sans le savoir des API malveillantes ou qu’il peut y avoir des API non maintenues qui sont encore accessibles au public, ce qui peut entraîner plusieurs menaces de sécurité.

« Les spécifications de l’API peuvent être obsolètes et vous ne pouvez pas protéger ce que vous ne savez pas que vous avez », a-t-elle déclaré. « Commencez par comprendre quels contrôles vous avez déjà dans votre environnement pour sécuriser les API, puis identifiez et résolvez les espaces. Surtout, assurez-vous de résoudre la découverte et l’inventaire des API. »

Meilleures pratiques pour améliorer la sécurité des API

La force de la sécurité des API dépend entièrement de la façon dont l’architecture des données impose des politiques d’authentification et d’autorisation. Grâce aux avancées technologiques telles que les services cloud, les passerelles API et les plates-formes d’intégration permettent désormais aux sociétés d’API de protéger leurs API de manière unique. La pile d’innovation sur laquelle vous choisissez de développer vos API a un impact sur la façon dont vous les sécurisez.

Un certain nombre de méthodes peuvent être utilisées pour protéger efficacement votre système contre les intrus API :

• Passerelle API : Une passerelle API est la base de une structure de sécurité des API étant donné qu’elle rend basique le développement, la maintenance, le suivi et la sécurisation des API. L’entrée API peut résister à de nombreuses menaces et fournir un suivi API, une journalisation et une restriction de débit. Il peut également automatiser la validation des jetons de sécurité et la restriction du trafic en fonction des adresses IP et d’autres informations.

• Pare-feu d’application Web : un pare-feu d’application Web ou WAF, fonctionne comme une couche intermédiaire entre le trafic public et la passerelle API ou l’application. Les WAF peuvent fournir une protection supplémentaire contre les acteurs dangereux, tels que les bots, en offrant une détection des bots malveillants, la capacité de reconnaître les signatures d’attaque et une intelligence IP supplémentaire. Les WAF peuvent être utiles pour obstruer le mauvais trafic avant même qu’il n’atteigne votre entrée.

• Applications de sécurité : produits de sécurité autonomes prenant en charge des fonctionnalités telles que la protection en temps réel, le code fixe et l’analyse des vulnérabilités, la surveillance intégrée et la sécurité le fuzzing peut également être inculqué au sein de l’architecture de sécurité.

• Sécurité dans le code : Le code de sécurité est un type de sécurité mis en œuvre en interne dans l’API ou les applications. Les ressources nécessaires pour garantir que toutes les procédures de sécurité sont correctement exécutées dans votre code API peuvent être difficiles à utiliser régulièrement dans tous vos portefeuilles d’API.

L’avenir de la sécurité des API

Roy Liebermann, responsable de la réussite client chez Browse Security, pense qu’absolument aucune confiance ne peut être une autre option pour résister aux risques internes et externes.

« En ce qui concerne les API, aucune confiance n’est pertinente pour les clients et les serveurs », a-t-il déclaré. « Une application pilotée par API peut avoir une grande variété de microservices, ce qui rend difficile pour les responsables de la sécurité de suivre leur développement et leur effet sur la sécurité. L’adoption des principes de confiance zéro garantit que chaque microservice interagit avec le moindre privilège, en évitant d’utiliser des ports ouverts et permettant l’authentification et l’autorisation sur chaque API. »

Liebermann conseille aux RSSI d’étendre la confiance zéro aux API pour réduire le risque que des pirates utilisent la communication API pour prendre des données.

De même, Palanisamy indique qu’à mesure que la sécurité zéro confiance et les architectures zéro confiance prennent de l’ampleur, la sécurité des API sera l’un des principaux domaines d’intérêt, en particulier avec le SaaS et d’autres services cloud utilisés aujourd’hui.

« La clé est de prendre un regardez cela avec une méthode à l’échelle de l’entreprise. La sécurité des API ne peut pas être résolue en se concentrant simplement sur quelques applications », a-t-il déclaré.

« Nous assistons probablement à un changement de paradigme d’application logicielle varié au cours des cinq prochaines années qui intègre des fonctions de sécurité REST et SOAP. Je pense qu’il y aura un paradigme de développement d’applications logicielles où les fonctions de chaque approche seront utilisées pour créer une approche supérieure combinée », a déclaré Nabil Hannan, directeur général de NetSPI, à VentureBeat. « Ce mélange retirera la sécurité des mains des concepteurs et permettra une bien meilleure adoption de la « sécurité dès la conception ».

Hannan a déclaré que le principe d’identité et d’authentification est en train de changer et que nous devons évoluer loin des noms d’utilisateur et des mots de passe et de l’authentification à deux facteurs, qui dépend de l’absence d’erreurs humaines.

« Le flux de travail d’authentification passera à ce que font des entreprises comme Apple autour de la gestion des identités avec des développements comme le trousseau iOS16. Cela sera développé via des API dans un avenir proche », a-t-il déclaré.