Ma première règle est valable pour toutes les ressources mises sur le Web : il faut limiter l’exposition, n’exposer que les API strictement nécessaires et surtout que les serveurs n’exposent pas d’autres types de services qui pourraient être exploitables par l’attaquant.
En outre, il est indispensable de traiter l’obsolescence de tous les logiciels impliqués, qu’il s’agisse du serveur http ou des langages mis en œuvre. Il est aussi nécessaire de bien configurer les headers de sécurité. C’est très important pour une API qui peut être appelée à la fois par une application Web et une application mobile. Il ne faut autoriser que les accès souhaités et interdire tous les autres. Parfois, les entreprises laissent l’accès au swagger de l’API, sa documentation, en quelque sorte. C’est très pratique pour l’attaquant et cela ne doit pas être accessible en production. De même, les serveurs de production sont parfois en mode développement. En cas d’exception, beaucoup d’informations de contexte sont remontées à destination des développeurs. C’est très utile pour eux, mais aussi pour les attaquants. Une telle fonctionnalité ne doit pas être activée en production. Enfin, le code de l’API doit s’assurer que chaque endpoint est correctement authentifié et dispose des privilèges nécessaires pour l’opération demandée. On voit encore des endpoints qui ont été oubliés et qui peuvent se connecter à l’API sans autorisation ou qui ont des privilèges qui ne sont pas adéquats. De tels contrôles doivent être réalisés dès la phase de développement et ajoutés avant la mise en production des tests d’intrusion automatisés. »
