Les outils d'inspection réseau, intégrés aux navigateurs modernes, permettent aux développeurs de surveiller et de déboguer le trafic web, le chargement des ressources et les problèmes de sécurité. Bien qu'ils soient essentiels pour le développement et le débogage, ces outils peuvent également être utilisés par des pirates pour analyser des applications. Les mesures de sécurité doivent tenir compte des informations exposées par ces outils.
Les outils d'inspection réseau sont les panneaux intégrés aux outils de développement d'un navigateur, comme l'onglet Réseau des Chrome DevTools ou de Firefox, qui enregistrent chaque requête émise par une page. Pour chaque requête, ils affichent l'URL, la méthode, le statut, les en-têtes, le timing, la charge utile, les cookies et le corps de la réponse, permettant à un développeur de voir exactement ce que la page a récupéré et dans quel ordre. Ils se conjuguent avec des panneaux connexes pour le DOM, la console, le stockage et le débogage JavaScript. Ces outils ne sont pas privilégiés : ils ne montrent que ce que la page actuelle et la propre session de la personne peuvent déjà atteindre, et ils s'exécutent entièrement côté client. Ils sont indispensables pour construire et déboguer des applications web et pour diagnostiquer les problèmes de performance et de sécurité.
Parce que l'inspecteur expose tout ce que le navigateur voit, c'est aussi un outil de reconnaissance. N'importe qui peut l'ouvrir et lire les points de terminaison d'API qu'un site appelle, la forme de ses requêtes, les jetons et cookies en jeu, ainsi que tout secret qu'un développeur a expédié par erreur au client. C'est une première étape courante lorsqu'on sonde une application web : cartographier le trafic, puis rejouer ou altérer les requêtes. Le point important est que l'inspecteur n'accorde aucun nouvel accès ; il ne fait que révéler ce que le client détient déjà. Le risque n'est donc pas l'outil, mais l'hypothèse selon laquelle le code ou les données côté client seraient cachés. Tout ce qui est envoyé au navigateur, y compris les champs de formulaire masqués et la logique minifiée, est parfaitement visible pour l'utilisateur.
La leçon défensive est de concevoir comme si chaque requête et chaque réponse côté client était publique, car pour l'utilisateur elle l'est. Ne comptez jamais sur l'obscurité : gardez les secrets, les clés de signature et la logique d'autorisation sur le serveur, appliquez chaque contrôle d'accès côté serveur et partez du principe que du JavaScript minifié ou obscurci peut être lu. N'envoyez au navigateur que les données qu'un utilisateur donné a le droit de voir, et limitez étroitement la portée des jetons. L'obfuscation peut augmenter l'effort d'analyse mais ne remplace jamais un véritable contrôle. Rien de tout cela n'est quelque chose qu'un tiers peut verrouiller à votre place : c'est une propriété de la façon dont vous construisez l'application. Traiter l'inspecteur réseau comme une partie permanente et légitime du navigateur de chaque visiteur conduit à des conceptions plus honnêtes et plus sûres.
Pas efficacement. Les scripts qui tentent de détecter ou de bloquer les DevTools sont facilement contournés et ne font surtout que frustrer les utilisateurs légitimes. Comme ces outils s'exécutent dans le propre navigateur de l'utilisateur, vous ne pouvez pas les désactiver de façon fiable. La réponse durable est de construire de sorte que rien de sensible ne soit exposé au client dès le départ.
Non. Les requêtes de toute application web sont visibles dans l'inspecteur par conception, et cela seul n'est pas une faille. Cela ne devient un problème que si ces requêtes révèlent des secrets ou si le serveur fait confiance au client pour appliquer ses propres autorisations. Une API bien conçue reste sûre même lorsqu'elle est entièrement observée.
We answer client-side security questions every day. Bring yours.