API caché de l'application mobile : mitmproxy et proxy

```html

Le site est fermé par Cloudflare, Turnstile apparaît à chaque deuxième requête, et la mise en page change toutes les deux semaines. Pourtant, le même service dispose d'une application mobile qui accède directement au backend et reçoit un JSON prêt — sans défis, sans balisage, avec un schéma de champs stable. C'est ce qu'on appelle une « API cachée » : une interface non documentée, mais entièrement fonctionnelle, utilisée par le client officiel.

Analysons étape par étape comment la trouver à l'aide de mitmproxy, que faire avec le certificate pinning et pourquoi, à l'étape de mise à l'échelle de la collecte sans proxy, tout s'effondre.

Pourquoi s'intéresser au trafic de l'application

Le scraping de la version web et l'appel d'une API privée sont des tâches de coût différent. Comparez :

Web. Un navigateur sans interface est nécessaire, contournement de l'anti-bot, parsing HTML, réparation régulière des sélecteurs. Une requête = mégaoctets de trafic et secondes de temps processeur.
API privée. Une requête HTTP classique avec quelques en-têtes, la réponse — un JSON compact avec des champs typés. Elle renvoie souvent plus de données que ce que montre l'interface : identifiants internes, drapeaux, champs de service.

Les backends mobiles sont historiquement moins protégés que le web. La raison est prosaïque : les plateformes anti-bot sont conçues pour le trafic de navigateur (défis JS, canvas, signaux comportementaux), et le client mobile ne passerait tout simplement pas par elles. Au lieu de cela, les développeurs s'appuient sur une clé d'application statique et le TLS pinning — les deux étant retirés sur l'appareil local.

Ce dont vous aurez besoin

mitmproxy — un proxy HTTPS open source (plus de 44 000 étoiles sur GitHub, la branche actuelle 12.2.2 est sortie en avril 2026, nécessite Python 3.12+). S'installe avec une seule commande : pip install mitmproxy. Comprend HTTP/1, HTTP/2, HTTP/3, WebSocket et TCP brut, fonctionne avec TLS 1.2 et 1.3.
Un appareil Android ou un émulateur avec root. La pratique montre que les versions Android 7 à 11 sont les plus pratiques : les nouvelles versions ont considérablement durci le travail avec les certificats.
ADB pour communiquer avec l'appareil et Frida (pip install frida-tools) — nécessaire si l'application pinne le certificat.

mitmproxy a trois interfaces au-dessus d'un seul moteur : mitmproxy (TUI terminal), mitmweb (interface web, plus pratique pour les débutants) et mitmdump (headless, pour les scripts et l'automatisation).

Étape 1. Lancer le proxy

Nous lançons l'interface web de manière à ce qu'elle écoute les connexions externes, et non seulement localhost :

mitmweb --web-host 0.0.0.0

Par défaut, le proxy est lancé sur le port 8080. Lors de son premier démarrage, mitmproxy crée son propre centre de certification et place les clés dans le répertoire ~/.mitmproxy. Quatre fichiers apparaîtront : mitmproxy-ca.pem (certificat avec clé privée), mitmproxy-ca-cert.pem (certificat uniquement), mitmproxy-ca-cert.p12 pour Windows et mitmproxy-ca-cert.cer — format pour Android.

Étape 2. Diriger l'appareil via le proxy

Dans les paramètres Wi-Fi de votre téléphone, sélectionnez un proxy manuel : l'IP de votre ordinateur dans le réseau local et le port 8080. Ensuite, ouvrez dans le navigateur de l'appareil un domaine spécial mitm.it — c'est une page intégrée dans mitmproxy qui détecte automatiquement la plateforme et fournit le format de certificat nécessaire avec des instructions.

Sur iOS, la procédure se compose de trois parties, et tout le monde oublie la seconde moitié : téléchargez le profil via Safari, installez-le dans « Réglages → Général → VPN et gestion de l'appareil », puis activez séparément la confiance complète dans « Réglages → Général → À propos de cet appareil → Confiance des certificats ». Sans cette dernière étape, le certificat est installé mais ne fonctionne pas.

Si vous ne souhaitez pas vous embêter avec les paramètres Wi-Fi, mitmproxy dispose d'un mode serveur VPN : mitmweb --mode wireguard. L'appareil se connecte avec le client WireGuard standard, et le trafic est intercepté de manière transparente, sans configuration manuelle du proxy dans le système.

Étape 3. Le principal obstacle — la confiance au certificat

C'est ici que la plupart des tentatives échouent. Il y a exactement deux problèmes, et ce sont des problèmes différents.

Les CA personnalisés ne sont pas à la mode depuis 2016

Depuis Android 7 Nougat (API 24), les applications font par défaut confiance uniquement au magasin de certificats système. Un CA personnalisé est ignoré, sauf si le développeur l'a explicitement autorisé dans la configuration de sécurité réseau — via le bloc <certificates src="user" /> dans les trust anchors. C'était une décision consciente de Google pour réduire la surface d'attaque, et il n'est pas possible de contourner cela avec les paramètres du téléphone. Chrome, d'ailleurs, ne fait pas confiance aux certificats personnalisés non plus. Dans Android 11, les restrictions ont été encore renforcées.

Conclusion pratique : sur un appareil avec root, le certificat mitmproxy doit être placé dans le magasin de certificats système, et non dans le magasin utilisateur. C'est pourquoi le root figure dans la liste des exigences, et non comme « souhaitable ».

Certificate pinning

Le deuxième obstacle — le pinning : l'application contient l'empreinte du certificat serveur attendu et refuse de communiquer avec quiconque d'autre. Même le CA système ne sauve pas ici. Une étude de l'ACM de 2022 a montré que le pinning est répandu dans les secteurs « à haut risque » (banques, taxis, crypto), mais souvent mal implémenté et donc contournable.

Il existe plusieurs outils pour cette tâche, et ils la résolvent de différentes manières :

Frida — modification du comportement en temps réel : nous hookons les fonctions de vérification du certificat et les forçons à retourner un succès. L'application n'est pas modifiée — c'est l'option la plus flexible. Lancement typique : frida -U -f com.target.app -l ssl_bypass.js --no-pause.
apk-mitm — supprime automatiquement le pinning du fichier APK de manière statique.
android-unpinner — reconstruit l'APK en intégrant Frida et des scripts de contournement du pinning.
objection — une boîte à outils au-dessus de Frida, qui fonctionne aussi bien sur iOS que sur Android.
ssl-kill-switch2 — désactive le pinning dans les applications iOS et macOS.

Si un domaine spécifique est piné de manière rigide et empêche le fonctionnement, il peut simplement être exclu de l'interception avec l'option ignore_hosts (accepte une expression régulière) — le trafic passera à côté de mitmproxy sans décryptage.

Étape 4. Trouver la requête nécessaire

Ensuite, c'est la routine. Ouvrez l'application, effectuez une seule action significative (ouvrir la fiche produit, faire défiler le fil d'actualité, appliquer un filtre) et regardez quelles requêtes sont apparues. Dans l'interface terminale, cela se fait rapidement : Z vide la liste des flux, Enter ouvre la requête sélectionnée, E l'exporte — y compris avec la commande curl prête à l'emploi.

Que chercher dans la requête interceptée :

Endpoint et paramètres. Souvent, il y en a beaucoup plus que ce que l'interface de l'application utilise.
Clé client. Classique — un identifiant statique, intégré dans l'application. Dans une analyse connue de l'API publique de MyAnimeList, cette clé était l'en-tête x-mal-client-id avec la valeur 6591a087c62b3e94d769cd8e35ffe909, donnant accès aux endpoints api.myanimelist.net/v3/anime/season et /v3/anime avec une vingtaine de paramètres.
User-Agent. Pour les clients mobiles, il est spécifique et fait partie du « passeport » — dans le même exemple, c'est MAL (ios, 139).
Tokens et leur durée de vie. Regardez immédiatement si la clé est statique ou mise à jour : cela dépend de toute l'architecture du collecteur.

Il est pratique de transformer le curl exporté en code via curlconverter — vous obtiendrez une requête prête à l'emploi pour requests, et ensuite vous travaillerez avec un client HTTP ordinaire, sans navigateur.

Étape 5. Mise à l'échelle — et où tout se casse

À ce stade, la déception arrive, familière à tous ceux qui ont essayé : depuis une IP domestique, l'API privée répond parfaitement pendant les premières demi-heures, puis commence à renvoyer des 429 et 403. Les backends mobiles sont moins protégés contre la falsification du client, mais les limites par IP y sont plus strictes — le serveur part du principe qu'une seule téléphone est derrière l'adresse, et non un parseur avec vingt flux.

Voici donc des conclusions pratiques.

Gardez le profil des requêtes plausible. Une application réelle ne fait pas 50 requêtes par seconde et ne suit pas strictement un calendrier. L'ordre des appels compte aussi : un vrai client demande d'abord la configuration de session, puis le contenu.
Répartissez la charge sur les adresses. Une IP = un « téléphone ». Les stratégies de rotation, de délais avec jitter et de backoff exponentiel ont été détaillées dans le matériel comment contourner la limitation de taux API lors du scraping via des proxies.
Considérez la géo. De nombreuses API mobiles renvoient un contenu et des prix différents selon le pays de l'adresse — c'est à la fois une restriction et une opportunité.

Il est pratique de déboguer sans quitter mitmproxy : il peut se connecter à un proxy en amont. La commande mitmdump --mode upstream:http://example.com:8081 redirige tout le trafic vers l'amont, et l'autorisation à celui-ci est définie avec l'option --upstream-auth au format username:password. Ainsi, vous voyez les mêmes requêtes qu'auparavant, mais elles partent déjà d'une adresse externe — vous pouvez immédiatement vérifier comment l'API réagit à un pays ou un type d'IP spécifique.

Quel type de proxy choisir pour une API mobile

Le choix ici n'est pas abstrait, il découle de qui vous prétendez être.

Proxies mobiles — option prioritaire. Vous imitez le trafic de l'application, et l'adresse de l'opérateur mobile semble absolument organique pour le backend : derrière une seule adresse, grâce à CGNAT, se trouvent réellement des centaines d'abonnés, donc les limites pour ces IP sont plus douces. Conviennent proxies mobiles 4G/LTE.
Proxies résidentiels — un bon compromis, si les volumes sont importants et que l'attachement à l'opérateur n'est pas critique : les IP domestiques des fournisseurs offrent une large couverture géographique à un prix raisonnable. Ce sont des proxies résidentiels.
Datacenter — uniquement pour les endpoints sans vérification sérieuse de la réputation de l'adresse. Leur ASN est reconnu instantanément, et sur un backend mobile, cela semble étrange : il n'y a pas de téléphones dans les datacenters.

Les pièges dont on découvre tard les conséquences

HTTP/3. Le support de QUIC dans mitmproxy est présent et activé par défaut, mais sur le trafic mobile réel, il est limité : souvent, la connexion doit être rétrogradée de force à HTTP/2 par des manipulations avec ALPN. QUIC fonctionne le mieux en modes reverse et WireGuard.
API privée change sans avertissement. Elle n'a aucune obligation de rétrocompatibilité — c'est une interface interne. La version de l'application dans User-Agent cessera un jour d'être prise en charge, et le collecteur commencera silencieusement à recevoir des réponses vides. Surveillez non seulement les codes de réponse, mais aussi la structure du JSON.
Ne confondez pas « trouvé la clé » et « obtenu le droit ». Une clé client statique n'est pas une autorisation pour une collecte illimitée.

Sur le plan légal

L'interception du trafic sur son propre appareil est une pratique légale et courante de débogage, utilisée par les développeurs mobiles et les spécialistes de la sécurité. Les limites commencent plus loin : respectez les conditions d'utilisation du service, ne collectez pas de données personnelles sans base légale (dans l'UE, cela est directement réglementé par le RGPD), ne touchez pas aux endpoints nécessitant une autorisation d'autrui, et maintenez la charge à un niveau qui ne perturbe pas le fonctionnement du service. Un repère pratique : si les données sont visibles dans l'application pour tout utilisateur sans connexion à un compte — vous êtes dans une zone relativement sûre ; si un compte d'autrui est nécessaire pour accéder — vous êtes déjà au-delà de cette limite.

En résumé

Le schéma fonctionne et économise des semaines de travail avec l'anti-bot : nous lançons mitmproxy, plaçons le certificat dans le magasin de certificats système de l'appareil avec root, si nécessaire, contournons le pinning via Frida, capturons une requête significative, l'exportons en curl et la réécrivons en Python. Ensuite, la tâche de « contourner la protection » se transforme en tâche de « répartir soigneusement la charge » — et se résout par la rotation des adresses, des pauses raisonnables et le bon type de proxy. Il est plus facile de commencer avec des proxies mobiles : ils sont les plus proches du trafic que le backend s'attend à voir.