Prima di pagare per un penetration test dell'app mobile: c'è una checklist di sicurezza che possiamo seguire da soli?

Fate fare subito al team questi tre controlli: 1) Disabilitate i log dell'app, nei log di console non devono mai comparire dati dei clienti o token. 2) Assicuratevi che i dati sensibili copiati negli appunti vengano cancellati automaticamente. 3) Testate il comportamento dell'app sui dispositivi con permessi di root.

Potete integrare strumenti open source di analisi statica direttamente nella pipeline di build. Esistono tool gratuiti che scansionano il codice in pochi minuti e segnalano chiavi nascoste o funzioni di archiviazione non sicure. Vi consiglio di non spendere soldi per test esterni prima di averli usati.

L'anno scorso abbiamo commesso lo stesso errore. Abbiamo speso 4.200 sterline per il test e 9 rilievi su 12 nel report riguardavano chiavi di test dimenticate nel codice e file di cache locale non crittografati. Se avessimo controllato prima, i tester si sarebbero potuti concentrare sul flusso di pagamento, che andava davvero analizzato a fondo.

Avere una propria checklist è un'ottima idea ma non consideratela mai un'alternativa a un penetration test formale. Quando si cercano falle nel codice scritto da sé, l'assuefazione del team è inevitabile. Questi controlli servono per massimizzare il valore del budget speso, non per annullare il test.

noi usiamo un'architettura ibrida quindi l'app gira praticamente dentro una webview ma i controlli che avete citato su storage locale e certificati valgono allo stesso modo anche per le app ibride?

fate molta attenzione alle chiavi api segrete dimenticate nel repository. il nostro team aveva mandato in produzione una chiave temporanea creata per l'ambiente di test, ce ne siamo accorti all'ultimo. si trovano anche con una semplice ricerca nel codice.

Due anni fa, nella prima versione della nostra app di consegne un cliente è riuscito a intercettare il traffico con un semplice proxy e a impostare il totale dell'ordine a 0 sterline. Il motivo? Calcolavamo il prezzo sull'app mobile per poi inviarlo al server. Da quel giorno adottiamo il principio di zero fiducia verso il client mobile.

Siete sulla strada giusta. Le società di sicurezza forniscono indicazioni standard per correggere ogni vulnerabilità, ma spetta comunque a voi sistemare il codice. Se prima completate la vostra checklist e vi presentate con una struttura pulita, la sessione di test sarà molto più efficiente e il report finale diventerà un ottimo biglietto da visita per le vendite enterprise.

non lo sapevo.

Nel nostro caso è andata così. Non abbiate paura di chiedere, chi non chiede paga sempre di più.

Secondo me è difficile essere così netti sul lato checklist sicurezza app mobile. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

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

C'è una trappola qui non posso non segnalarla. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Se cerchi di cambiare tutto insieme niente si stabilizza.

Mi farebbe piacere se scrivesse il risultato.

Grazie per aver scritto.

Il punto più trascurato riguardo a checklist sicurezza app mobile è questo: Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Separiamo i concetti, vengono confusi. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Argomento molto attuale. Non fidatevi di una sola misura di sicurezza; procedete per livelli.

Ha ragione.