Blog

le 05/02/2018
Guillaume
SOA & Urbanisation

Sécurisation des API

Aujourd’hui, de plus en plus de sociétés souhaitent ouvrir leur système vers l’extérieur.

Cela s’explique par plusieurs facteurs :

L’explosion des devices et objets connectés en tous genres sur la marché.
La migration des applications lourdes vers le cloud.
Et surtout une volonté de multiplier les partenariats externes de façon rapide.

Alors que les premières API web créées par Salesforce ont vu le jour à la fin des années 90, elles n’ont cessé d’évoluer et de se standardiser.

Le standard REST qui a émergé au cours de ces années et qui est largement adopté aujourd’hui, propose un formalisme facilement compréhensible et rapide à mettre en œuvre, notamment par les équipes de développement.

En cela, les API répondent à de nombreux besoins : elles permettent d’exposer de façon rapide, centralisée et contrôlée tout ou partie des fonctionnalités d’un SI.

Mais qui dit « ouverture des systèmes vers l’extérieur » dit également « failles de sécurité potentielles ».

On constate aujourd’hui que la rapidité de mise à disposition de tous ces services via API se fait parfois au détriment des règles les plus basiques de la sécurité.

Pour reprendre une étude du site Wavestone réalisée sur la sécurité de 155 sites internet dans divers domaines (banque, assurance, vente, transport…), on constate que 56% des sites ont au moins une faille de sécurité grave et les API en tant que porte d’entrée du système n’en sont pas en reste.

Bien sûr, un ensemble de travaux de sécurisation a accompagné l’évolution du REST et il existe aujoud’hui tout une palette de méthodes et de bonnes pratiques afin de sécuriser au mieux ses API.

1- Les bonnes pratiques de base

Comme pour tout service exposé sur le web, il existe un certain nombre de points sur lesquels il faut rester vigilant :

Authentification et utilisation des sessions utilisateurs avec éventuellement réauthentification pour les actions les plus critiques (exemple : réalisation de virement bancaire depuis son compte bancaire en ligne).
Gérer ses exceptions et erreurs : intercepter et retraiter ses erreurs afin de ne pas laisser remonter des informations techniques compromettantes.
Gérer les données sensibles : mot de passe, données financières, données RH.
Utiliser des profils d’accès et privilèges différents en fonction des besoins.
Maitriser ses entrées et sorties en utilisant par exemple de l’encodage des flux pour éviter les injection de données.

2 – Utilisation de Oauth2 et OpenId Connect

Oauth, et aujourd’hui Oauth2 est un protocole qui permet l’utilisation d’API sécurisées par une application tierce pour le compte d’un utilisateur de cette application. Il ne s’agit donc pas d’un framework de sécurisation mais de délégation d’autorisations.

Basé sur un serveur d’autorisations, il permet à la fois le génération de jetons d’accès (RFC-6749) ainsi que leur validation lors de l’utilisation (RFC-6750).

OpenId, quant à lui, est une couche d’identification basée sur Oauth2. Il permet aux clients de récupérer un ensemble d’informations concernant l’utilisateur final.

Mais attention, mal utilisé ou mal implémenté, Oauth peut également devenir à son tour une faille de sécurité (usurpation d’identité, récupération des informations utilisateurs, vol de token…).

Conclusion

Même si tous les outils sont à notre disposition dans le but de sécuriser nos API, il n’en reste pas moins qu’il faut rester vigilant lors de l’implémentation de nos projets.

Cela passe par différents axes :

la formation et la sensibilisation des développeurs sur les différents principes énoncés.
faire intervenir des experts en sécurité, soit en amont des projets soit en tant qu’auditeurs externes. Mais également dans les équipes projets en tant que telles.
s’appuyer sur des outils du marché existants, du type « API manager » (Oracle, Axway, WSO2…) afin de bénéficier de leur expérience et ne pas réinventer la roue.