- TL;DR : au lieu de rediriger les appels d’API de HTTP vers HTTPS, il faut les faire échouer. Désactivez complètement HTTP ou renvoyez une réponse d’erreur HTTP explicite, et révoquez les clés d’API transmises sur une connexion non chiffrée. Malheureusement, de nombreux fournisseurs d’API connus ne le font pas aujourd’hui.
Contexte
- Lorsqu’un navigateur web accède à une URL en HTTP, le service redirige souvent cette requête vers une page HTTPS.
- Le trafic HTTP initial n’est pas chiffré, ce qui l’expose aux attaques de l’homme du milieu (MITM).
- Des technologies comme HSTS (HTTP Strict Transport Security) ont été introduites pour renforcer la sécurité.
Les risques d’une simple faute de frappe
- Lors d’une intégration avec une API tierce, l’URL de base de l’API a été saisie par erreur en
http:// au lieu de https://.
- Le
fetch de Node.js a suivi silencieusement la redirection vers HTTPS.
- La clé d’API a été transmise en clair, créant un risque de sécurité.
- L’erreur a été repérée lors de la revue de code, puis corrigée.
Le principe du fail fast
- Si une API redirige les requêtes HTTP vers HTTPS, une faute de frappe peut facilement passer inaperçue.
- Il est préférable d’appliquer le principe du fail fast : les appels d’API non chiffrés doivent échouer de manière explicite.
- Il est recommandé de désactiver l’interface HTTP du serveur d’API, ou de renvoyer un message d’erreur pour les requêtes HTTP.
Exemples d’autres API
- Plusieurs API connues renvoient une erreur 403 pour les requêtes HTTP ou désactivent complètement leur interface HTTP.
- Cependant, certaines API redirigent encore de HTTP vers HTTPS.
Pourquoi il faut faire évoluer les bonnes pratiques
- Dans les applications destinées aux utilisateurs, la redirection de HTTP vers HTTPS est courante.
- Dans le cas des API, rediriger de HTTP vers HTTPS peut au contraire être nuisible.
- Des projets de sécurité comme OWASP devraient fournir des directives plus claires pour les API.
Conclusion
- Les API ne devraient pas rediriger de HTTP vers HTTPS, mais faire échouer clairement les requêtes non chiffrées.
- Si une clé d’API est transmise via une connexion non chiffrée, elle doit être révoquée immédiatement.
- Il faut mettre à jour les bonnes pratiques de sécurité des API afin de fournir des directives claires.
L’avis de GN⁺
- Nécessité de renforcer la sécurité : la sécurité des API est essentielle, et la redirection de HTTP vers HTTPS peut introduire des vulnérabilités.
- Principe du fail fast : il est important de suivre ce principe afin de détecter et corriger les erreurs dès les premières phases du développement.
- Mise à jour des bonnes pratiques : des projets de sécurité comme OWASP doivent fournir des directives claires sur la sécurité des API.
- Révocation automatique des clés : les clés d’API transmises sur une connexion non chiffrée devraient être automatiquement révoquées.
- S’inspirer d’autres API : il est nécessaire de renforcer la sécurité de sa propre API en s’appuyant sur les pratiques d’autres API.
5 commentaires
On dirait que c’est un domaine qui devrait être encadré par la loi.
Pour commencer, mémo... interdiction des redirections HTTPS dans les API
C’est techniquement exact,
mais dans la plupart des entreprises, les clients ont pour consigne de sécurité de toujours renvoyer une redirection vers HTTPS en cas d’accès en HTTP.
De plus, comme ils n’aiment pas afficher une page d’erreur à leurs propres clients, à moins d’exploiter leur propre service, c’est un peu une autre planète du point de vue de ceux qui livrent la solution, non ?
Oups, l’IA a fait ce genre d’erreur haha. C’est corrigé maintenant.
Commentaires sur Hacker News