App Android per i clienti: come capire se lo sviluppatore scrive codice davvero sicuro?

Fate questa semplice domanda allo sviluppatore: "Se un utente con telefono con root apre l'app, o se intercetto il traffico di rete tramite un proxy riesco a vedere i token dei clienti?" Se evitano la risposta, il livello di sicurezza è debole. Inoltre, installando l'app su un dispositivo di test, potete scansionare voi stessi l'APK a livello base con scanner di sicurezza open source gratuiti.

Il server di backend (API) a cui si collega l'app dove risiede e chi ne ha verificato la sicurezza? Perché nelle app mobile i dati di solito non trapelano dal telefono ma dalle falle di autorizzazione sul server di backend da cui l'app preleva le informazioni. La sicurezza delle API è stata testata?

Se gestite dati clinici e ordini commerciali in Germania, ai sensi del DSGVO siete tenuti a documentare il principio di 'privacy by design'. Chiedete allo sviluppatore di compilare una checklist di conformità agli standard OWASP Mobile Security (MASVS). Devono indicare a fronte di ogni voce quale misura hanno adottato e firmare in calce. Capirete subito se sono disposti ad assumersi una responsabilità formale.

Che gli sviluppatori dicano 'è tutto sicuro' non significa assolutamente nulla. Molti freelance fanno copia e incolla di blocchi di codice già pronti presi da internet e ci piazzano dentro le chiavi API in chiaro. Finché non ci butta un occhio un revisore esterno e indipendente, non fidatevi mai della sicurezza di quell'app.

come prima cosa andate nelle impostazioni del telefono a controllare i permessi dell'app. se un'app che prende solo ordini vi chiede accesso ai file alla posizione o alla rubrica vuol dire che lo sviluppatore ha fatto copia-incolla di un template pronto e via. i permessi inutili sono il rischio più grosso.

Ma Google Play Store non fa già dei controlli di sicurezza quando si caricano le app? Se lo store l'ha approvata, dobbiamo comunque far fare dei test di sicurezza extra?

L'anno scorso ci hanno consegnato un'app B2B simile. Gli sviluppatori erano super sicuri di sé, ma noi abbiamo comunque speso 2.500 EUR per un pentest mobile indipendente. Dal report è emerso che le password del server backend erano state lasciate in chiaro dentro l'APK e che i token di sessione non scadevano mai. Se non avessimo speso quei soldi sarebbe scoppiato un casino assurdo.

La strada che sembra economica di solito finisce per costare cara. Un backup non testato non è un backup.

la penso diversamente ma se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

confemrato dall'esperienza.

A me è successo l'esatto contrario, per questo scrivo. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Se scrivete qui il risultato, sarà utile anche ad altri.

lascio un avvertimento ma non fidatevi di una sola misura di sicurezza; procedete per livelli.

se scrivete qui il risultato sarà utile anche ad altri.

Sono d'accordo.

avete ragione, sono passato anch'io per la stessa strada. non abbiate paura di chiedere, chi non chiede paga sempre di più.

Il mio dubbio è stato chiarito, grazie. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Il vero problema non è il numero, ma su cosa si basa quel numero.

Ha ragione. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

C'è un punto che mi incuriosisce. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

È tutto, scusate se mi sono dilungato.

Non lo sapevo. Se la verifica in due passaggi è attiva una password rubata da sola non serve a nulla.

Riassumo quanto detto finora. Se è la prima volta, inizia in piccolo il ridimensionamento viene dopo.

Buon lavoro.