Come scoprire l'API nascosta di un'app mobile: mitmproxy, Frida e proxy nel 2026

```html

Il sito è chiuso da Cloudflare, Turnstile appare a ogni secondo tentativo, e il layout cambia ogni due settimane. Tuttavia, lo stesso servizio ha un'app mobile che accede direttamente al backend e riceve un JSON pronto — senza sfide, senza markup, con uno schema di campi stabile. Questo è il "API nascosto": un'interfaccia non documentata, ma completamente funzionante, utilizzata dal client ufficiale.

Analizziamo passo dopo passo come trovarlo utilizzando mitmproxy, cosa fare con il certificate pinning e perché, nella fase di scalabilità della raccolta senza proxy, tutto si rompe.

Perché entrare nel traffico dell'applicazione

Lo scraping della versione web e la chiamata a un API privata sono compiti di costo diverso. Confrontiamo:

• Web. Serve un browser headless, bypassare l'antibot, parsing HTML, riparazione regolare dei selettori. Una richiesta = megabyte di traffico e secondi di tempo di CPU.
• API privata. Una normale richiesta HTTP con un paio di intestazioni, la risposta è un JSON compatto con campi tipizzati. Spesso restituisce più dati di quanto mostri l'interfaccia: identificatori interni, flag, campi di servizio.

I backend mobili storicamente sono meno protetti rispetto al web. La ragione è prosaica: le piattaforme antibot sono progettate per il traffico del browser (sfide JS, canvas, segnali comportamentali), e il client mobile semplicemente non passerebbe attraverso di esse. Invece, gli sviluppatori si affidano a una chiave statica dell'app e al TLS pinning — entrambi vengono rimossi sul dispositivo locale.

Cosa sarà necessario

1. mitmproxy — un proxy HTTPS open-source (oltre 44.000 stelle su GitHub, la versione attuale 12.2.2 è stata rilasciata ad aprile 2026, richiede Python 3.12+). Si installa con un solo comando: pip install mitmproxy. Supporta HTTP/1, HTTP/2, HTTP/3, WebSocket e TCP raw, funziona con TLS 1.2 e 1.3.
2. Dispositivo Android o emulatore con root. La pratica dimostra che i modelli Android 7–11 sono i più comodi: le nuove versioni hanno reso molto più difficile lavorare con i certificati.
3. ADB per comunicare con il dispositivo e Frida (pip install frida-tools) — sarà necessario se l'app pinna il certificato.

Mitmproxy ha tre interfacce sopra un unico motore: mitmproxy (TUI terminale), mitmweb (interfaccia web, più comoda per i principianti) e mitmdump (headless, per script e automazione).

Passo 1. Avviare il proxy

Avviamo l'interfaccia web in modo che ascolti le connessioni esterne, non solo localhost:

mitmweb --web-host 0.0.0.0

Per impostazione predefinita, il proxy si avvia sulla porta 8080. Al primo avvio, mitmproxy crea la propria autorità di certificazione e posiziona le chiavi nella cartella ~/.mitmproxy. Qui appariranno quattro file: mitmproxy-ca.pem (certificato insieme alla chiave privata), mitmproxy-ca-cert.pem (solo certificato), mitmproxy-ca-cert.p12 per Windows e mitmproxy-ca-cert.cer — formato per Android.

Passo 2. Inoltrare il dispositivo tramite proxy

Nelle impostazioni Wi-Fi del telefono, selezioniamo il proxy manuale: l'IP del computer nella rete locale e la porta 8080. Poi apriamo nel browser del dispositivo un dominio speciale mitm.it — questa è una pagina integrata in mitmproxy che identifica automaticamente la piattaforma e restituisce il formato corretto del certificato con le istruzioni.

Su iOS, la procedura consiste in tre parti, e la seconda metà viene spesso dimenticata: scaricare il profilo tramite Safari, installarlo in "Impostazioni → Generali → VPN e gestione dispositivo", e poi attivare separatamente la fiducia totale in "Impostazioni → Generali → Informazioni su questo dispositivo → Fiducia nei certificati". Senza quest'ultimo passaggio, il certificato è installato, ma non funziona.

Se non si desidera armeggiare con le impostazioni Wi-Fi, mitmproxy ha una modalità server VPN: mitmweb --mode wireguard. Il dispositivo si connette tramite il client WireGuard standard, e il traffico viene intercettato in modo trasparente, senza configurazione manuale del proxy nel sistema.

Passo 3. Il principale ostacolo — fiducia nel certificato

Qui si rompono la maggior parte dei tentativi. Ci sono esattamente due problemi, e sono problemi diversi.

CA personalizzati non sono apprezzati dal 2016

A partire da Android 7 Nougat (API 24), le applicazioni per impostazione predefinita si fidano solo dello store di certificati di sistema. Il CA personalizzato viene ignorato se lo sviluppatore non lo ha esplicitamente autorizzato nella Network Security Config — attraverso il blocco <certificates src="user" /> negli trust anchors. Questa è stata una decisione consapevole di Google per ridurre la superficie di attacco, e non può essere aggirata con le impostazioni del telefono. Chrome, tra l'altro, non si fida nemmeno dei certificati personalizzati. In Android 11, le restrizioni sono state ulteriormente inasprite.

Conclusione pratica: sul dispositivo con root, il certificato mitmproxy deve essere posizionato nello store di sistema, non in quello utente. Ecco perché il root è nella lista dei requisiti, e non "preferibile".

Certificate pinning

Il secondo ostacolo è il pinning: l'applicazione contiene l'impronta del certificato server atteso e rifiuta di comunicare con chiunque altro. Nemmeno il CA di sistema aiuta qui. Uno studio dell'ACM del 2022 ha dimostrato che il pinning è comune in verticali "ad alto rischio" (banche, taxi, criptovalute), ma spesso è implementato in modo incompleto e quindi può essere aggirato.

Ci sono diversi strumenti per il compito, e risolvono il problema in modi diversi:

• Frida — modifica del comportamento in runtime: si agganciano le funzioni di verifica del certificato e le si costringe a restituire successo. L'applicazione non viene modificata — è l'opzione più flessibile. Un avvio tipico: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
• apk-mitm — rimuove automaticamente il pinning dal file APK in modo statico.
• android-unpinner — ricompone l'APK, integrando Frida e gli script di rimozione del pinning.
• objection — toolkit sopra Frida, funziona sia su iOS che su Android.
• ssl-kill-switch2 — disabilita il pinning nelle applicazioni iOS e macOS.

Se un dominio specifico è pinning in modo rigido e ostacola il lavoro, può essere semplicemente escluso dall'intercettazione con l'opzione ignore_hosts (accetta espressioni regolari) — il traffico passerà oltre mitmproxy senza decrittazione.

Passo 4. Trovare la richiesta necessaria

Da qui in poi è routine. Apriamo l'app, eseguiamo esattamente un'azione significativa (aprire la scheda di un prodotto, scorrere il feed, applicare un filtro) e vediamo quali richieste sono apparse. Nell'interfaccia terminale, questo si fa rapidamente: Z pulisce l'elenco dei flussi, Enter apre la richiesta selezionata, E la esporta — inclusa la comanda pronta curl.

Cosa cercare nella richiesta intercettata:

• Endpoint e parametri. Spesso ce ne sono molti di più di quanti ne utilizzi l'interfaccia dell'app.
• Chiave cliente. Classico del genere — un identificatore statico, incorporato nell'app. In un noto studio dell'API pubblica MyAnimeList, questa chiave si è rivelata essere l'intestazione x-mal-client-id con valore 6591a087c62b3e94d769cd8e35ffe909, che apriva l'accesso agli endpoint api.myanimelist.net/v3/anime/season e /v3/anime con una ventina di parametri.
• User-Agent. Nei client mobili è specifico e funge da parte del "pass" — nello stesso esempio è MAL (ios, 139).
• Token e la loro durata. Controlla subito se la chiave è statica o si aggiorna: da questo dipende tutta l'architettura successiva del raccoglitore.

È comodo trasformare la curl esportata in codice tramite curlconverter — otterrai una richiesta pronta per requests, e poi lavorerai con un normale client HTTP, senza alcun browser.

Passo 5. Scalabilità — e dove tutto si rompe

In questo punto arriva la delusione, familiare a chi ha provato: da un IP domestico, l'API privata risponde perfettamente per i primi trenta minuti, e poi inizia a restituire 429 e 403. I backend mobili sono meno protetti contro la falsificazione del client, ma i limiti per IP sono più severi — il server presume che dietro l'indirizzo ci sia un telefono, non un parser in venti flussi.

Da qui le conclusioni pratiche.

1. Mantenere il profilo delle richieste plausibile. Un'app reale non fa 50 richieste al secondo e non segue un programma rigoroso. Anche l'ordine delle chiamate è importante: un client reale prima richiede la configurazione della sessione, poi il contenuto.
2. Distribuire il carico su indirizzi diversi. Un IP = un "telefono". Le strategie di rotazione, ritardi con jitter e backoff esponenziale sono state dettagliatamente analizzate nel materiale come aggirare il rate limiting dell'API durante lo scraping tramite proxy.
3. Considerare la geolocalizzazione. Molti API mobili restituiscono contenuti e prezzi diversi a seconda del paese dell'indirizzo — questo è sia un limite che un'opportunità.

È comodo fare il debug senza uscire da mitmproxy: può collegarsi a un proxy upstream. Il comando mitmdump --mode upstream:http://example.com:8081 instrada tutto il traffico verso l'upstream, e l'autenticazione per esso viene impostata con l'opzione --upstream-auth nel formato username:password. In questo modo vedrai le stesse richieste di prima, ma andranno già da un indirizzo esterno — puoi subito controllare come l'API reagisce a un paese specifico o a un tipo di IP.

Quale tipo di proxy scegliere per un API mobile

La scelta qui non è astratta, deriva da chi ti fingi di essere.

• Proxy mobili — l'opzione prioritaria. Stai imitando il traffico dell'applicazione, e l'indirizzo dell'operatore mobile appare al backend in modo assolutamente organico: dietro un solo indirizzo, grazie al CGNAT, ci sono realmente centinaia di abbonati, quindi i limiti per tali IP sono più morbidi. Adatti proxy mobili 4G/LTE.
• Proxy residenziali — una via di mezzo funzionante, se i volumi sono grandi e il legame con l'operatore non è critico: gli IP domestici dei provider offrono una copertura geografica ampia a un prezzo adeguato. Questi sono proxy residenziali.
• Proxy di data center — solo per endpoint senza un serio controllo della reputazione dell'indirizzo. Il loro ASN viene riconosciuto immediatamente, e su un backend mobile appare strano: nei data center non ci sono telefoni.

Insidie che si scoprono tardi

• HTTP/3. Il supporto per QUIC in mitmproxy è presente ed è attivato per impostazione predefinita, ma sul traffico mobile reale è limitato: spesso la connessione deve essere forzatamente retrocessa a HTTP/2 tramite manipolazioni con ALPN. QUIC funziona meglio nelle modalità reverse e WireGuard.
• API privata cambia senza preavviso. Non ha obblighi di retrocompatibilità — è un'interfaccia interna. La versione dell'app nel User-Agent smetterà di essere supportata e il raccoglitore inizierà silenziosamente a ricevere risposte vuote. Monitora non solo i codici di risposta, ma anche la struttura del JSON.
• Non confondere "trovato la chiave" e "ottenuto il permesso". Una chiave cliente statica non è un'autorizzazione per una raccolta illimitata.

Sulla questione legale

Intercettare il traffico sul proprio dispositivo è una pratica legale e quotidiana di debug, utilizzata da sviluppatori mobili e specialisti della sicurezza. I confini iniziano più in là: rispetta i termini di utilizzo del servizio, non raccogli dati personali senza una base legale (nell'UE è direttamente regolato dal GDPR), non toccare gli endpoint che richiedono autorizzazione di terzi, e mantieni il carico a un livello che non ostacola il funzionamento del servizio. Un orientamento pratico: se i dati sono visibili nell'app a qualsiasi utente senza accesso all'account — sei in una zona relativamente tranquilla; se per accedervi è necessaria una registrazione di terzi — sei già oltre il limite.

In breve

Lo schema funziona e fa risparmiare settimane di lavoro con l'antibot: avviamo mitmproxy, posizioniamo il certificato nello store di sistema del dispositivo con root, se necessario rimuoviamo il pinning tramite Frida, catturiamo una richiesta significativa, la esportiamo in curl e la riscriviamo in Python. Da lì, il compito di "aggirare la protezione" si trasforma in un compito di "distribuire il carico con attenzione" — e si risolve con rotazione degli indirizzi, pause ragionevoli e il giusto tipo di proxy. È più semplice iniziare con proxy mobili: sono i più vicini al traffico che il backend si aspetta di vedere.