Inspecter les requêtes HTTPS avec HTTP Toolkit

Dec 3, 2025 · 4 min read

Inspecter les requêtes HTTPS avec HTTP Toolkit

Lorsque votre appel API échoue silencieusement ou que l’authentification se rompt sans explication, les DevTools du navigateur s’avèrent souvent insuffisants. Vous devez voir le trafic chiffré réel qui quitte votre application. HTTP Toolkit offre précisément cette capacité : un moyen simple d’intercepter le trafic HTTPS et d’inspecter ce qui se passe réellement sur le réseau.

Cet article explique comment HTTP Toolkit fonctionne en tant que proxy local, ce que vous devez savoir sur la prise en charge des protocoles, et les workflows pratiques que les développeurs frontend utilisent pour déboguer les requêtes HTTPS.

Points clés à retenir

HTTP Toolkit fonctionne comme un proxy man-in-the-middle, déchiffrant le trafic HTTPS en utilisant une autorité de certification racine de confiance.
L’outil prend entièrement en charge l’interception HTTP/1.1, HTTP/2 et WebSocket, HTTP/3 basculant vers des protocoles antérieurs.
L’interception du navigateur fonctionne automatiquement via des instances préconfigurées, tandis que les applications mobiles et de bureau nécessitent une configuration manuelle du proxy et du certificat.
Au-delà de l’inspection passive, HTTP Toolkit vous permet de définir des points d’arrêt, de modifier les requêtes et de tester différentes réponses API sans modifier le backend.

Comment HTTP Toolkit fonctionne comme proxy MITM

HTTP Toolkit fonctionne comme un proxy man-in-the-middle (MITM). Il se positionne entre votre client (navigateur, application mobile ou application de bureau) et le serveur, interceptant tout le trafic qui transite.

Pour le trafic HTTP, c’est simple. L’inspection HTTPS nécessite une étape supplémentaire : faire confiance à l’autorité de certification (CA) racine générée par HTTP Toolkit. Lorsque vous faites confiance à ce certificat, l’outil peut déchiffrer le trafic TLS, l’afficher sous forme lisible, puis le rechiffrer avant de le transmettre au serveur de destination.

La confiance au certificat se fait automatiquement pour les navigateurs lancés via HTTP Toolkit. Pour les autres applications, vous devrez configurer les paramètres du proxy et installer le certificat manuellement.

Prise en charge des protocoles et limitations

HTTP Toolkit prend entièrement en charge l’interception HTTP/1.1 et HTTP/2. Ces protocoles couvrent la grande majorité des scénarios de débogage frontend.

HTTP/3 (QUIC) présente une situation différente. Lorsqu’un client utiliserait normalement HTTP/3, HTTP Toolkit force un basculement vers HTTP/2 ou HTTP/1.1. L’interception native QUIC n’est pas encore disponible. Pour la plupart des travaux de débogage frontend, cette limitation importe rarement : les données de requête et de réponse restent identiques quel que soit le protocole de transport.

L’outil gère également les connexions WebSocket, vous permettant d’inspecter la communication en temps réel aux côtés du trafic HTTP standard.

Connexion des navigateurs et applications

Interception du navigateur

Le workflow le plus simple démarre depuis le tableau de bord d’HTTP Toolkit. Cliquez sur l’option navigateur (Chrome, Firefox ou Edge), et HTTP Toolkit lance une instance préconfigurée avec les paramètres de proxy et la confiance au certificat déjà configurés.

Chaque requête depuis cette fenêtre de navigateur apparaît dans l’onglet View d’HTTP Toolkit. Vous voyez la requête complète (méthode, URL, en-têtes et corps) ainsi que la réponse complète.

Trafic des applications mobiles

Le débogage mobile nécessite plus de configuration. Pour les appareils Android, vous avez plusieurs options :

Connexion ADB : Connectez un appareil via USB et laissez HTTP Toolkit le configurer
Proxy manuel : Configurez les paramètres WiFi de votre appareil pour router via HTTP Toolkit
Appareils rootés : Installez le certificat au niveau système pour une couverture plus large

Le modèle de sécurité d’Android crée des frictions ici. Les applications ciblant Android 7+ ne font confiance aux certificats installés par l’utilisateur que si elles sont explicitement configurées pour le faire. De nombreuses applications ignorent complètement les certificats CA utilisateur, ce qui signifie que vous ne verrez que le trafic des applications qui n’ont pas restreint la confiance aux certificats.

Le certificate pinning ajoute une autre couche. Les applications qui épinglent des certificats spécifiques rejetteront le certificat d’HTTP Toolkit quels que soient les paramètres de confiance système. Certaines solutions de contournement existent (scripts Frida, appareils rootés avec installation CA système), mais elles sortent du cadre des fonctionnalités principales d’HTTP Toolkit.

Applications de bureau

Pour les applications Electron et autres logiciels de bureau, configurez l’application pour utiliser HTTP Toolkit comme proxy. La méthode exacte varie selon l’application : certaines respectent les paramètres de proxy système, d’autres nécessitent des variables d’environnement ou des flags en ligne de commande.

Visualisation et modification du trafic

Une fois que le trafic transite par HTTP Toolkit, la page View affiche chaque échange intercepté. L’interface se divise en une liste de requêtes et un panneau de détails.

Le panneau de détails décompose chaque échange en sections repliables : en-têtes de requête, corps de requête, en-têtes de réponse, corps de réponse et informations de timing. Le contenu du corps est automatiquement formaté selon le type de contenu : le JSON bénéficie de la coloration syntaxique, et le JavaScript minifié s’étend pour une meilleure lisibilité.

Pour le débogage frontend, les fonctionnalités les plus utiles incluent :

Filtrage : Restreindre à des hôtes, méthodes ou codes de statut spécifiques
Recherche : Trouver des requêtes par motif d’URL ou contenu
Export : Générer des extraits de code en fetch, axios, curl et autres formats

Au-delà de l’inspection passive, HTTP Toolkit prend en charge les points d’arrêt et les règles. Vous pouvez mettre en pause les requêtes avant qu’elles n’atteignent le serveur, modifier les en-têtes ou les corps, puis transmettre la requête modifiée. Cela aide à tester comment votre application gère différentes réponses API sans modifier le code backend.

Workflows pratiques de débogage frontend

L’inspection HTTPS avec HTTP Toolkit excelle dans plusieurs scénarios :

Débogage d’authentification : Inspecter les en-têtes de token, les valeurs de cookies et les flux OAuth
Problèmes d’intégration API : Voir exactement quelle charge utile votre application envoie par rapport à ce que le serveur attend
Analyse de scripts tiers : Surveiller ce que les scripts d’analyse et de publicité transmettent
Dépannage CORS : Examiner les requêtes preflight et les en-têtes de réponse

L’outil capture le trafic que les DevTools du navigateur pourraient manquer : requêtes provenant de service workers, récupérations en arrière-plan ou scripts qui détectent les outils de développement ouverts.

Conclusion

HTTP Toolkit offre aux développeurs frontend une inspection HTTPS fiable sur les navigateurs, applications mobiles et applications de bureau. L’exigence de confiance au certificat permet le déchiffrement, tandis que le comportement de basculement pour HTTP/3 assure la compatibilité avec l’infrastructure moderne. Pour déboguer les appels API, les flux d’authentification et le comportement réseau, il fournit une visibilité que les outils de navigateur seuls ne peuvent égaler.

FAQ

Les applications ciblant Android 7 et supérieur ne font confiance aux certificats installés par l'utilisateur que si leur configuration de sécurité réseau l'autorise explicitement. De nombreuses applications restreignent la confiance aux certificats système ou utilisent le certificate pinning, qui rejette tout certificat ne correspondant pas à leurs valeurs attendues. Pour ces applications, vous pourriez avoir besoin d'un appareil rooté avec installation CA au niveau système.

HTTP Toolkit n'intercepte pas nativement le trafic HTTP/3 (QUIC). Au lieu de cela, il force les clients à basculer vers HTTP/2 ou HTTP/1.1. Ce basculement est transparent pour la plupart des besoins de débogage puisque les données de requête et de réponse restent les mêmes quel que soit le protocole de transport sous-jacent.

Oui. HTTP Toolkit prend en charge les points d'arrêt et les règles qui vous permettent de mettre en pause les requêtes, de modifier les en-têtes ou le contenu du corps, et de transmettre la requête modifiée. Vous pouvez également intercepter les réponses et les modifier avant qu'elles n'atteignent votre application, ce qui est utile pour tester la gestion des erreurs et les cas limites.

HTTP Toolkit capture le trafic que les DevTools pourraient manquer, y compris les requêtes provenant de service workers, les récupérations en arrière-plan et les scripts qui détectent les outils de développement ouverts. Il fonctionne également sur les navigateurs, applications mobiles et applications de bureau, offrant une vue unifiée de tout le trafic réseau provenant de plusieurs sources.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.