France API, première édition de l’évènement français autour des APIs, s’est tenu le 14 juin dernier. L’équipe Orange Developer s’est rendue sur place.

Le sujet API se développe de plus en plus au sein des entreprises françaises, de l’Etat ou des collectivités, et il est apparu important et naturel au collectif API Thinking en collaboration avec le cabinet Accetal de lancer cette initiative, supportée par plusieurs sponsors, fournisseurs de solutions.

Plusieurs thématiques ont été abordées lors des conférences. Cela nous a permis d’identifier les tendances relatives aux APIs en matière de sécurité, d’éco-responsabilité, d’évolution des architectures, d’usage du No-Code, de l’émergence de nouvelles APIs asynchrones. Dans cet article, nous vous proposons de partager nos retours sur ces sujets.

La sécurité est toujours un enjeu majeur pour les APIs. Les menaces s’accroissent. Fâce à ces menaces, l’Open Web Application Security Project® (OWASP), fondation à but non lucratif qui travaille à améliorer la sécurité des logiciels, référence les principales vulnérabilités uniques et les risques de sécurité des APIs :

• API1: 2019 Broken Object Level Authorization
• API2: 2019 Broken User Authentication
• API3: 2019 Excessive Data Exposure
• API4: 2019 Lack of Resources & Rate Limiting
• API5: 2019 Broken Function Level Authorization
• API6: 2019 Mass Assignment
• API7: 2019 Security Misconfiguration
• API8: 2019 Injection
• API9: 2019 Improper Assets Management
• API10: 2019 Insufficient Logging & Monitoring

Une infrastructure de distribution d’API fait généralement intervenir divers éléments de sécurité tels que FireWall applicatif (WAF), FireWall (FW), API GateWay ou test de sécurité de type boîte noire (DAST) …
Toutefois, ces éléments de sécurité manquent de données de contexte permettant de mettre en évidence, dans le temps, des écarts de comportement des transactions susceptibles de révéler d’autres types de fraude.

L’évènement France API a été l’occasion de découvrir des solutions s’intégrant dans l’environnement (plate-forme d’API management) client. Par analyse continue faite sur une duplication des logs, elles établissent des modèles de trafic de façon à détecter et signaler toute variation d’usage (demande intempestive sur un champ donné, volume de requête inhabituel, activité à horaire décalé, …) susceptible d’être d’origine frauduleuse.

A l’autre bout de la chaine des APIs, des sociétés réalisent des analyses cette fois côté design des API. Ceci permet de détecter en amont les failles potentielles, les données sensibles manipulées, les incohérences entre swagger et documentation. Dans le même esprit de sécuriser les APIs lors de leur création, il est possible d’embarquer les règles de sécurité dans une approche No-Code. Cela rend automatisable et systématique l’application des règles de sécurité sans imposer de processus contraignant au codeur d’API.

Diminuer la génération de CO2 est de nos jours une préoccupation majeure pour toute entreprise. C’est le cas de L’Oréal, qui a mis en place depuis quelques années des mesures pour baisser cette génération au niveau de son processus de production. Or cette baisse a été compensée par la hausse des usages numériques de l’entreprise. Il lui a donc fallu repenser ses usages de bout en bout, c’est-à-dire sur toute la chaîne de valeur. Et les APIs sont un élément central de ces usages. Ce qu’on entend par une API numériquement responsable sur toute la chaîne de valeur, c’est le fait de mettre en place des APIs responsables, éco-conçues mais aussi (et surtout) éco-consommées.
Parmi les axes d’approche – non exclusivement-, il convient de :

• Travailler sur les formats de données utilisées
• Décommissionner les APIs non utilisées
• Encourager l’utilisateur à ne consommer que la ou les données dont il a besoin
• Etablir un catalogue unique, commun d’APIs
• Centraliser la gestion des APIs, ne pas multiplier les points d’accès
• Utiliser un indicateur type « nutri-score » pour promouvoir les APIs les plus responsables sur la consommation de ressources. Cet outil évalue :
  • la consommation d’une API
  • sa conformité
  • son niveau de sécurité
  • l’effort de maintenance requis

Un autre aspect d’une approche éco-responsable concerne le site, sur lequel sont exposées ces APIs. En effet, des bonnes pratiques incluent :

• La possibilité d’activer le mode sombre,
• La possibilité d’activer le mode statique (vidéos désactivées), etc.
• L’utilisation d’un outil tel que Fruggr pour définir la réduction de taille d’image, enlever les javascripts non utilisés, vérifier le « labelling » des boutons, etc.

A noter que ce travail est l’occasion d’un partage avec le collectif API Thinking sur le sujet.

Les organisations et les solutions d’API management tentent de s’adapter pour gouverner au mieux les programmes d’API qui évoluent dans nos entreprises. Au début on peut parler d’anarchie productrice avec des bonnes volontés multiples qui se lancent dans l’aventure. Il n’y a pas de gouvernance centralisée donc chacun fait comme il le veut ou comme il le peut. La productivité est au rendez-vous, mais évidemment cela pose question sur l’application systématique de règles de sécurité ou sur l’homogénéité de l’ensemble produit pour optimiser l’usage ou la réutilisabilité.

Souvent les entreprises réagissent en instaurant justement une gouvernance centralisée qui a pour but de fédérer l’ensemble avec des règles à appliquer. Les règles sont d’abord acceptées mais deviennent vite des contraintes et des processus à adresser pour chaque nouvelle API. Les règles se multiplient, la gouvernance devient un goulot d’étranglement, la productivité baisse…

Comment concilier ces besoins de productivité, de sécurité, de management centralisé pour garantir la qualité et la sécurité des APIs ?
L’enjeu est majeur car selon Gartner, en 2025, plus de 50% des APIs ne seront pas sécurisées ou managées. Comme la demande croît, comme la société « millenials » est moins attachée au process, comme l’IT est souvent un goulot d’étranglement pour bien traiter les demandes, il devient important d’automatiser certaines règles pour les rendre systématiques et plus rapides à appliquer.

L’idée est simple : il faut intégrer, et même masquer, les règles de gouvernance dans les outils de production des APIs !
Une des approches est le No-Code. Plutôt qu’implémenter les règles à chaque fois dans le code de ses API, le développeur manipule des modules intégrant les règles qu’il convient de combiner pour bâtir son API (côté Backend) : l’API n’est plus faite de lignes de code mais de séquences de modules qui vont masquer les règles et diminuer l’effort. L’avantage est une simplification pour le développeur et une systématisation pour l’application des règles. En outre, cette simplification ouvre la porte à un plus grand nombre de personnes: plus et bien !

Les premières plates-formes d’API management s’appuyaient sur une architecture simple (Edge) pour mettre en relation une application consommatrice avec un micro service (dialogue Nord-Sud). Avec le developpement des usages des APIs des architectures plus sophistiquées (Mesh) ont été mises en oeuvre.

• • Architecture Edge

Dans ce type d’architecture, le consommateur accède à un ou plusieurs micro-services, qui ne dialoguent pas entre eux. On parle alors de simple connectivité Nord (consommateur) – Sud (micro-services).

• Architecture Mesh
  Les applications modernes sont composées (dialogue Nord-Sud) à partir de micro-services qui s’exécutent dans des conteneurs distribués sur site et dans le cloud. Ces micro-services peuvent également dialoguer entre eux (dialogue Est-Ouest). Ces micro-services ont besoin de nouveaux outils pour relever les nouveaux défis de connectivité que sont la sécurité des échanges, la haute disponibilité et l’observabilité.

Un service Mesh définit à la fois le Control Plane (pour configurer la connectivité et le comportement de service souhaités) et le Data Plane (pour diriger le trafic et appliquer les règles de sécurité et d’autorisations). Chaque micro-service va bénéficier pour exposer ses ressources d’une petite Gateway, gérée par le Service Mesh, qui vient se placer à côté du micro-service (mode side-car) et rendre possible les échanges sécurisés et autorisés entre micro-services.

Sans le service Mesh, toutes ces fonctionnalités devraient être intégrées directement dans chaque micro-service ce qui l’alourdirait et compliquerait sa maintenabilité et sa durabilité.

Tout le monde connaît OpenApi Specification avec la dernière version 3.0.3 bien utile pour décrire son API à la fois dans un langage compréhensible par l’humain et aussi pour traduire cela vers du code.
De plus en plus d’APIs asynchrones voient le jour pour répondre à des besoins de workflow qui ne peuvent pas être tous séquentiels. Cela amène des nouveaux besoins de description de l’API avec une norme récente qui vient compléter OAS 3.0.3 : AsyncAPI. Il faut effectivement en plus du swagger pouvoir décrire les flux et les échanges sous forme de graphe.

La société Gravitee est très active sur ce domaine et décrit l’arrivée d’une troisième génération d’API.

• La première est bien sûr les APIs classiques pour mettre à disposition une ressource en interne ou vers des partenaires, construit principalement sur le protocole REST pour garantir un certain niveau de design.
• La seconde génération est liée au renouveau et optimisation dans le monde du développement, avec l’arrivée des micro-services et service MESH mais aussi des protocoles comme gRPC.
• Enfin une troisième génération existe depuis quelques années pour traiter des aspects temps réel et asynchrone de l’accès à certaines ressources (validité d’une ressource sur un temps court, changement de statut d’un IOT, streaming temps réel…).

Certes cela existait déjà… avec des mécanismes de polling, avec plusieurs APIs entre deux composants… La démarche est similaire à OAS, et d’ailleurs souhaite rester compatible avec, en élargissant le scope à ces APIs temps réel : rendre plus standardisé, plus simple et plus compréhensible à chacun pour développer l’usage et la réutilisabilité.

Gartner (2021 Gartner API strategy maturity model) indique qu’en 2023, plus de 50% des transactions B2B seront effectuées via des APIs temps réel, plutôt que via l’approche traditionnelle.
Des sociétés s’emparent déjà du sujet avec des suites design compatibles AsyncAPI comme celles de gravitee.io ou Akwatype avec une approche « data flow first » à découvrir.

Site de l’évènement : France API

La sécurité :

• NoName Security 
• 42Crunch
• Salt Security

L’éco-responsabilité

• Collectif API Thinking

Le No-Code

• SnapLogic

L’API management

• What’s a service mesh? (redhat.com)
• Istio

Les APIs asynchrones

• AsyncAPI
• gravitee.io
• Akwatype