Le site Programmable Web recense plus de 10000 APIs qui se trouvent au centre du web moderne. Ces APIs permettent d’intégrer différents services allant des réseaux sociaux à la cartographie en passant par des flux d’information, de l’analyse de données, de flux le multimédia …
Fort heureusement, le simple respect des bonnes pratiques de l’architecture du Web permettent d’en lever certains. Mais créer des API ouvertes (utilisables depuis n’import quel site web) comporte tout de même certains risques de sécurité qu’il faut prendre en compte.
Considérations de sécurité
L’attaque la plus typique que peuvent subir les API REST ouvertes et applé le “Cross Site Request Forgery”. Il s’agit du fait qu’un site utilise les données d’authentification stockées dans le navigateur pour appeler des APIs sécurisées à l’insu de l’utilisateur lui même. Voir exemple sur la page wikipedia dédie au Cross Site Request Forgery
De fait, les navigateurs web limitent fortement les possibilités qu’a une page HTML a faire appel à une URL ou une API qui n’est pas sur le même serveur source que la page HTML elle même. De fait, par défaut, si je suis sur la page www.toto.com/unepage.html, je ne pourrait lire www.mesinfosprivees.com/mes_secrets/list.html ni executer www.mesinfosprivees.com/mes_secrets/api/publier. Ce qui est une bonne chose.
CORS un vrai enabler pour les API ouvertes
L’approche se sécurité citée plus haut permet de protéger les informations et services privés de la CSRF, cependant, cela limite la possibilité de mettre en place des services ouverts qui peuvent être appelés par des domaines tiers. Ainsi, je ne pourrais pas dans www.toto.com/unepage.html afficher www.mesinfospubliques.com/mesannonces.html or c’est exactement ce que je souhaite pour les API ouverte.
Le CORS (Cross Origin Resource Sharing) est une norme, implémentée par la quasi totalité des navigateurs modernes et qui permet aux site qui héberge l’API d’autoriser l’accès aux APIs depuis d’autres domaines tout en gardant un certain niveau de contrôle.
Avant d’activer CORS : regarder la sécurité
Mettre en oeuvre CORS coté serveur est en soit relativement simple, le plus complexe est de s’assurer de la maîtrise de la sécurité contre le CSRF. Pour cela :
- Ignorer coté serveur d’API toute authentification implicite basée sur les Cookies.
- De forcer chaque appel d’API à comporter les informations d’authentification s’il n’est pas public.
Pour ce second point, le pattern le plus pratique est le Synchronizer Token Pattern, il s’agit de :
- Générer à l’issue de l’authentification une chaine aléatoire dite (token)
- Transmettre à chaque appel d’API se token. (Dans un header http, dans l’URL, dans le corps)
Par contre il est extrêmement important de protéger ce token correctement :
- Il ne faut pas qu’il apparaisse dans le DOM (c’est à dire dans le HTML de la page statique ou dynamique)
- Qu’il ne soit pas accessible depuis une variable globale.
L’idéal est de le stocker dans un module javascript.
Quelques liens utiles
- API Ebay pour mettre en place CORS sur un serveur J2EE
- Cet article décrit certaines bonnes partiques de codage javascript propre.
- Cross Site Request Forgery sur Wikipedia