Come si garantisce la sicurezza delle app mobile e quali controlli sono obbligatori prima del lancio?

Se usate JWT impostate una scadenza brevissima per i token; tipo 15 minuti per l'access token e 7 giorni per il refresh token. Inoltre assicuratevi che nella build dell'app non sia rimasto per sbaglio il file `.env`. A volte gli sviluppatori lasciano le password del database di test o le chiavi API di servizi terzi hardcodate nel client.

Cose urgenti da fare pre-lancio: 1) Inserire il rilevamento di root e jailbreak per bloccare o avvisare l'utente su dispositivi modificati. 2) Disabilitare gli screenshot e oscurare la schermata quando l'app va in background. 3) Evitare che i messaggi di errore restituiscano percorsi del server o log del database.

Fate subito questo test da soli: installate un analizzatore di traffico di rete sul PC, collegate il telefono alla stessa rete Wi-Fi e fate passare il traffico dal computer. Se sullo schermo del PC riuscite a leggere in chiaro i prezzi e il dettaglio delle fatture scambiate dal telefono, significa che non avete fatto l'SSL Pinning.

Ci si concentra così tanto a blindare la parte mobile che ci si dimentica della vera porta d'ingresso: l'API. Anche se create un'app a prova di bomba, un attaccante non userà l'interfaccia, sparerà le richieste dritto al vostro endpoint. Mai considerare l'app mobile come un ambiente sicuro, tutta la logica va validata sul server.

L'anno scorso ci è successa una cosa simile su un'app B2B all'ingrosso. Un rivenditore ha intercettato la richiesta mentre inviava l'ordine e ha mandato all'API il prezzo unitario di un prodotto a 15 TL invece di 150 TL. Sull'app mobile il campo prezzo era bloccato, ma il backend ha confermato l'ordine fidandosi del prezzo ricevuto. Ce ne siamo accorti dopo due settimane con l'inventario in magazzino. Controllate due volte la validazione dei prezzi lato server.

nn dimenticate di disattivare i debug log nell'app a volte su logcat si vedono tutti i dati utente e i token in chiaro pulite i console log prima di mandare sugli store

Poiché la vostra applicazione gestisce dati finanziari che costituiscono segreti commerciali di persone giuridiche e ditte individuali, un'eventuale violazione comporterebbe l'obbligo di notifica di data breach all'autorità per la protezione dei dati (KVKK). È pertanto legalmente obbligatorio documentare e conservare tutte le misure di sicurezza adottate.

cioè con questo reverse engineering i nostri rivenditori o chiunque altro possono scaricare l'app e aprirsi tutto il codice sorgente sul proprio PC? comunque i controlli di approvazione degli store non bloccano questa cosa?

Corretto.

Grazie mille, mi è stato molto utile.

Non trascurare nulla: Se cerchi di cambiare tutto insieme, niente si stabilizza.

Lascio una nota, potrebbe servire.

Racconto cosa mi è successo, magari vi è utile. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

non lo sapevo.

Nel nostro caso è andata così. Cercare di farlo da soli è la strada più costosa.

Spero che le sia utile.

tre cose da controllare mentre lo fai... la sicurezza non è assoluta; signiica rendere l'attacco non conveniente.

non abbiate paura di chiedere chi non chiede paga sempre di più. io seguirei questa strada.

Sono passato da qui, vi racconto. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Correggetemi se sbaglio.

Non trascurare nulla: Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

La risposta sopra ha colto l'essenza della questione. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Le persone difendono le abitudini, non i processi. La resistenza nasce da lì. È tutto, scusate se mi sono dilungato.