Sélectionner une page

La sécurité des API

Après les pionniers (eBay, Amazon, Salesforce…), de plus en plus d’entreprises et d’organisations s’appuient sur des API publiques, partenaires ou privées. Objectif : gagner en efficacité. Revers de la médaille, les API sont également exploitées par les cybercriminels pour infecter les réseaux. Autre constat : des fuites de données peuvent être engendrées par une mauvaise conception. Avec l’entrée en vigueur du RGPD, les entreprises doivent mettre en place des procédures adaptées.

 

En avril dernier, les dossiers d’environ 37 millions clients directs ou indirects de Panera Bread (une chaîne américaine de boulangeries et de cafés) étaient accessibles en clair : nom, prénom, e-mail, numéro de téléphone, anniversaire, quatre derniers chiffres du numéro de carte de crédit enregistré, préférences et restrictions alimentaires. L’origine de cette fuite de données qui a duré au moins huit mois ? Une faille dans une API qui ne nécessitait pas d’authentification.

Panera Bread n’est pas la seule entreprise à avoir des API ou non sécurisées. Amazon, l’U.S. Postal Service, l’application Venmo (service de paiement mobile appartenant à PayPal qui permet aux utilisateurs d’effectuer des transferts d’argent entre eux)… : la liste des entreprises dont les API présentent des vulnérabilités ne cesse de s’allonger. Les failles de sécurité dues à une mauvaise conception des API se sont multipliées cette année. L’alerte avait pourtant été donnée en 2017. La catégorie des API pas assez sécurisées entrait pour la première fois dans le Top 10 de l’OWASP (Open Web Application Security Project).

Une situation inquiétante, car pour 61 % des entreprises interrogées par Imperva, les API sont essentielles à leur stratégie commerciale. Publiée début 2018, cette étude menée auprès de 250 professionnels de la sécurité informatique, précisait qu’en moyenne, les entreprises gèrent 363 API différentes, et les deux tiers (69 %) exposent les API au public et à leurs partenaires.

Or, la sécurité des API est compliquée à mettre en œuvre. Bien qu’il existe des tendances de conception communes à de nombreuses API, chaque infrastructure d’API fonctionne différemment.

Comprendre et tester les vulnérabilités connues de son code est éminemment important. Mais il est encore plus important de rechercher des failles non connues. Pas simple ! Une étude menée par HP indique qu’un périphérique IoT (Internet of Things) peut comporter jusqu’à 25 vulnérabilités, y compris un chiffrement insuffisant et des interfaces utilisateur non sécurisées. Il y a fort à parier que certaines de ces failles de sécurité seront liées aux API utilisées pour fournir des données et des fonctionnalités auxdits périphériques.

Il est donc indispensable de mettre en place une politique de sécurité adaptée. Mais qui s’en chargera ? Dans étude récente d’Ovum, la moitié (53 %) des personnes interrogées estiment que le service informatique est responsable de la sécurité des API. Mais presqu’autant (47 %) ont déclaré que l’équipe de développement des API en question est responsable. Cette situation n’est donc pas favorable à une gestion optimisée des API. Et elle ne permet pas d’être en conformité avec le RGPD, un règlement européen exécutoire depuis le 25 mai 2018.

Ce règlement impose notamment la notion de Privacy by design. En un mot, dès la conception d’une application, d’un site web, d’un objet connecté et donc d’une API, les développeurs (en étroite relation avec les autres métiers, et en particulier le marketing) doivent limiter le traitement aux seules données personnelles « strictement nécessaire à leur activité ». Il convient également de s’assurer de leur confidentialité.

Il convient aussi d’auditer précisément ces programmes pour vérifier qu’ils respectent les réglementations en vigueur dans chaque pays où ils seront déployés…

Il n’y a pas de « solution miracle » qui fonctionnera pour chaque API. Il faut de la méthode afin de mettre en place des processus de sécurité adaptés en fonction de l’architecture retenue pour accéder à un service web : SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer). Pour la première catégorie qui est plus « stricte », la sécurité passe notamment par la mise en place du WS-Security (Web Services Security). Ce protocole propose nativement des mécanismes d’authentification, de chiffrement voire de signature des messages échangés.

Le fait que WS-Security propose ses propres mécanismes de sécurité, le rend agnostique au protocole de transport. Ainsi un message SOAP sécurisé par WS-Security peut être transporté par tout type de protocoles : https, TLS, voire SSH ou encore IPSec.

Concernant les API REST, naturellement plus flexibles, il n’existe pas vraiment de mesures de sécurité natives malgré quelques initiatives sur le sujet telle que JSON Web Signature (JWS). Les développeurs doivent notamment consulter la documentation de l’OWASP sur le sujet.

De façon globale, il convient de mettre en place les processus suivants :

 

  1. Renforcer l’authentification des utilisateurs

C’est la règle de base : savoir qui utilise votre API afin de la protéger des intrus. Il est donc nécessaire d’enregistrer les utilisateurs en leur fournissant des clés API. Par ailleurs, il convient de bloquer les API anonymes pour qu’elles n’accèdent pas aux données personnelles.

  1. Chiffrer les clés de l’API

Encore trop de développeurs considèrent les clés d’API comme les actifs non critiques. Le chiffrement par HTTPS représente une première étape. Mais elle n’est pas suffisante, notamment contre les attaques dites « man in the middle » qui permettent à un attaquant d’intercepter les communications entre deux systèmes.

  1. Limiter le taux de déploiement

Un nombre inhabituel de requêtes provenant d’un utilisateur au cours d’une période donnée peut indiquer une activité malveillante sous la forme d’une attaque par déni de service. Il est donc important d’identifier quand un tel comportement anormal se produit et de l’arrêter. Par exemple, si le nombre de requêtes provenant d’une adresse IP dépasse 1 000 par minute, cette adresse sera verrouillée pendant 15 minutes.

  1. Identifier toutes les API

Pour être en conformité avec le RGPD, il est indispensable de faire l’inventaire de toutes les API auxquelles se connecte votre site. S’il s’agit d’API américaines, comme MailChimp, quelles garanties avez-vous à propos de la confidentialité des données personnelles ?

 

Les API sont indispensables pour optimiser son activité. Mais il est indispensable d’être proactif, et pas seulement réactif en matière de sécurité. Chaque entreprise qui traite de données à caractère personnel doit faire de la sécurité une préoccupation constante et prioritaire. Il est indispensable d’effectuer des tests de sécurité très stricts sur les vecteurs les plus vulnérables : API, connexions réseau, applications mobiles, sites Web et bases de données.

La sécurité doit être globale pour être efficace.

Share This