Sécurité

La sécurité dans un environnement APIsé est sujette aux mêmes règles que toute application web.

Cela recouvre le transport des données, l'authentification / les droits / l'accès aux ressources qui doit être contrôlé, ainsi que les bonnes pratiques de développement web (injections, sanitization, …).

La communauté OWASP constitue un bon référentiel pour recenser les principales failles applicatives et les bonnes pratiques de contre mesures associées.

SSL

doitToujours privilégier l'utilisation de SSL qui sécurise les échanges sur le plan de la confidentialité, et de l'authenticité du serveur fournissant l'API.

De plus, SSL est maintenant considéré par les moteurs de recherches référents comme un prérequis dans une stratégies SEO.

Authentification et accès

Le simple fait d'exposer une ressource suffit à considérer qu'elle sera consommée, même si à priori on ne connait pas sa localisation.

doitSi la ressource est censée être en accès restreint, il est impératif de faire le nécessaire pour contrôler son accès, et renvoyer une erreur en cas de tentative d'accès irrégulière.

Les erreurs à renvoyer sont généralement de trois types :

1. L'accès est interdit (code statut 401) : cas d'une tentative d'accès sans présentation de l'autorisation nécessaire
2. L'accès est refusé (code statut 403) : cas d'une tentative d'accès avec potentiellement une autorisation valide, mais insuffisante (droits)
3. L'accès est ignoré (code statut 404) : cas plus rare où l'on ne souhaite même pas informer le consommateur que la ressource existe (scope restreint, ressource d'administration)

Les mécanismes d'authentification courants sont : Basic Auth, OAuth2, X.509 ou encore HMAC, voire une simple clé en entête.

Le filtrage IP n'est pas un mécanisme d'authentification : on limite simplement l'exposition, en prenant de gros risques opérationnels (IP de proxy sortant partagée, plan d'IP sujet à évolution, voire non prédictible pour un cloud).

L'authentification par certificat est très efficace, sa mise en oeuvre est adaptée pour un serveur, mais s'avère lourde voire impossible pour le client; elle est par ailleurs potentiellement couteuse.

HMAC est une bonne alternative pour obtenir un niveau relativement équivalent au certificat, et présente l'intérêt d'être relativement light (donc adapté aussi à l'IoT).

OAuth2 est le standard le plus répandu dans le domaine du web, donc à privilégier pour une exposition massive et multi-canale (sauf pour l'IoT).

Le point clé : bien réfléchir aux contraintes induites sur le client qui va consommer l'API.