Sicurezza app mobile: Assessment e testing 2026

Metodologia di riferimento: OWASP MASVS e MASTG

Un assessment mobile strutturato non parte dallo strumento, ma dallo standard. OWASP MASVS (Mobile Application Security Verification Standard) definisce i requisiti di sicurezza attesi per le applicazioni iOS e Android, suddivisi per categorie: archiviazione, crittografia, autenticazione, rete, interazione con la piattaforma e qualità del codice. Il companion MASTG traduce ogni requisito in procedure di test verificabili, con evidenza nella mappatura tra requisito, test eseguito e risultato osservato.

Analisi statica e analisi dinamica

L'analisi statica esamina il pacchetto compilato: manifest, permessi, export dei componenti, configurazione delle reti, segreti o URL hardcoded, ofuscamento e controlli anti-manomissione. È veloce e ripetibile, ma non vede il comportamento a runtime.

L'analisi dinamica esegue l'app su un dispositivo controllato o su un emulatore strumentato, con proxy, e osserva il comportamento reale: traffico di rete, uso delle API di sistema, scrittura su storage, gestione delle sessioni. Richiede un dispositivo adeguato e l'autorizzazione scritta del proprietario dell'app e del backend coinvolto. La statica individua la superficie, la dinamica la conferma con prove: le due tecniche sono complementari.

Trasporto, archiviazione locale e canali IPC

Pinning dei certificati e i suoi limiti

Il certificate pinning lega l'app a una chiave o a una CA attesa e ostacola la lettura passiva del traffico. Non è però una garanzia: un dispositivo con privilegi elevati o una modifica del binario possono aggirarlo. Il test verifica se il pinning è presente, se copre tutti gli endpoint e se è aggirabile. Un TLS con validazione corretta dei certificati resta il requisito primario.

Archiviazione insicura di token e chiavi

Spesso token di sessione, chiavi API o dati personali sono memorizzati in posizioni non protette: preferenze in chiaro, file di log, database locali non cifrati, backup automatici. Il test controlla cosa viene scritto, dove e con quale protezione. Su iOS il riferimento è il Keychain; su Android il Keystore hardware-backed e le API di archiviazione sicura. Le chiavi di firma non devono mai risiedere nel client.

Abuso di IPC e deep link

Componenti esportati, intent, URI scheme e deep link sono vettori di attacco: un'altra app può richiamare un'attività non protetta, iniettare dati o dirottare un flusso di autenticazione. Si verifica l'export dei componenti, la validazione degli input esterni e l'assenza di token o parametri privilegiati nei deep link.

Difese lato dispositivo e test delle API backend

Root e jailbreak detection come controllo, non garanzia

Il rilevamento di root o jailbreak, insieme all'integrità dell'app, alza il costo di un attacco ma può essere aggirato. Va trattato come difesa in profondità e come segnale per limitare funzioni sensibili, non come barriera assoluta. Il test valuta se il controllo esiste e se la sua assenza consente di esporre dati o operazioni riservate.

BOLA e BFLA dall'OWASP API Security Top 10

Gran parte del rischio mobile vive sul backend. Il test di autorizzazione verifica che ogni chiamata controlli identità e permessi dell'utente. BOLA (Broken Object Level Authorization) si manifesta quando un identificatore di risorsa può essere cambiato per accedere a oggetti altrui; BFLA (Broken Function Level Authorization) quando un ruolo inferiore raggiunge funzioni amministrative. Si testano autenticazione, autorizzazione per oggetto e per funzione, rate limiting, validazione degli input e gestione degli errori.

Privacy, report di remediation e cadenza di retest

La verifica di privacy confronta i dati effettivamente raccolti e trasmessi con le dichiarazioni delle store (App Privacy su App Store, Data Safety su Google Play) e con l'informativa GDPR. Coerenza tra dichiarato e osservato, base giuridica, minimizzazione e conservazione sono elementi verificabili.

Il report di remediation ordina i riscontri per gravità e li descrive in modo riproducibile: condizione, prerequisiti, passi di riproduzione, evidenza (richieste, log, screenshot redatti) e raccomandazione tecnica. Ogni riscontro cita la categoria MASVS o ASVS pertinente.

Il retest chiude il ciclo: dopo gli interventi si ripetono i casi critici per confermare la correzione ed evitare regressioni. Una cadenza utile è legata al ciclo di rilascio, almeno a ogni rilascio maggiore, dopo cambiamenti architetturali o dopo un incidente. Per estendere il presidio si può valutare un servizio di ethical hacking autorizzato, consultare il blog o contattare il team tramite la pagina contatti.