Tra le notizie della settimana, una dovrebbe far riflettere chiunque sviluppi app mobile o servizi web. Secondo un’esclusiva di TechCrunch, un ricercatore di sicurezza ha scoperto che l’app della catena di ristoranti Applebee’s conteneva al suo interno una credenziale del database scritta in chiaro. Quel dettaglio avrebbe permesso di accedere senza restrizioni ai dati personali dei clienti.
Che cosa è successo
Il problema è di quelli che in gergo si chiamano hardcoded credentials: username e password inseriti direttamente nel codice o nei file distribuiti con l’applicazione. Chiunque scarichi l’app può analizzarne il pacchetto con strumenti gratuiti e, se i segreti sono lì dentro, recuperarli in pochi minuti. Non serve essere un attaccante sofisticato: basta curiosità e le competenze di base di reverse engineering.
Le informazioni disponibili al momento arrivano dalla segnalazione giornalistica e non permettono di stabilire con precisione quanti utenti siano coinvolti. Il quadro resta però chiaro: una chiave pensata per l’uso interno è finita in un’applicazione pubblica.
Perché succede ancora
Gli errori di questo tipo sono più comuni di quanto si pensi, e raramente dipendono da cattiva fede. Le cause tipiche sono:
- scorciatoie prese durante lo sviluppo, con credenziali di test che non vengono mai rimosse;
- la convinzione che il codice di un’app sia “nascosto” una volta compilato;
- team che collegano l’app direttamente al database invece di passare da un’API intermedia;
- l’assenza di controlli automatici prima del rilascio.
Come evitarlo
La regola di fondo è semplice: tutto ciò che sta dentro un’app installata sul telefono dell’utente va considerato pubblico. Da qui discendono alcune buone pratiche.
- Mai database esposti al client. L’app dovrebbe parlare con un backend che autentica l’utente e applica regole di accesso, non con il database.
- Gestione dei segreti. Chiavi e password vanno conservate in sistemi dedicati e ruotate con regolarità, soprattutto dopo ogni sospetta esposizione.
- Privilegi minimi. Anche un token legittimo dovrebbe poter fare solo ciò che serve a quel contesto, per esempio leggere i dati del singolo utente e non l’intera tabella.
- Scansione automatica. Strumenti di secret scanning nella pipeline di rilascio bloccano la pubblicazione se trovano credenziali nel codice o negli artefatti di build.
- Test di sicurezza periodici. Un’analisi dell’app finale, fatta da chi si mette nei panni di un attaccante, scova problemi che la revisione del codice può non vedere.
Cosa significa per le aziende
Per un’azienda che offre un’app ai clienti, i dati personali sono una responsabilità legale oltre che reputazionale. In Europa il GDPR richiede misure tecniche adeguate e, in caso di violazione, obblighi di notifica precisi. Una password dimenticata nel posto sbagliato può trasformarsi in un incidente costoso.
La notizia ricorda che la sicurezza non si decide solo con strumenti sofisticati, ma con abitudini di sviluppo disciplinate. Se la tua azienda ha un’app o un portale, vale la pena chiedersi oggi quali segreti contiene davvero il pacchetto che distribuisci.