Scrivi il software come se fosse già pubblico

Perché “nessuno lo vede” non è più una difesa

Per anni molta sicurezza applicativa ha poggiato su un’ipotesi implicita: il codice è privato, quindi un errore resta nascosto finché qualcuno non lo trova. Oggi un modello capace di leggere un’intera codebase e di ragionare sui suoi percorsi fa in pochi minuti ciò che richiedeva giorni a una persona esperta. Non serve credere a scenari estremi: basta ammettere che trovare un buco costa molto meno di prima, per chi attacca come per chi difende.

La conseguenza pratica è una regola di progetto: nessuna protezione deve dipendere dal fatto che qualcuno non conosca il sistema. Né i nomi delle tabelle, né la struttura delle rotte, né la convinzione che “questo endpoint non lo trova nessuno”.

Un caso reale: l’isolamento che dipendeva da un filtro

A giugno 2025 Asana ha scoperto un bug nel proprio server MCP che poteva far vedere i dati di un cliente ad altre organizzazioni. La funzione è stata messa offline; secondo alcune fonti i clienti coinvolti erano circa mille. Non era un attacco: era un errore di logica, presente fin dal lancio della funzione.

È il caso tipico di un isolamento che vive nel codice applicativo: ogni pagina, ogni endpoint e ogni esportazione deve ricordarsi di aggiungere il filtro sul cliente giusto, e basta una volta in cui non succede.

Cinque regole che non dipendono dal fatto che nessuno guardi

• L’isolamento sta nel database, non nel filtro. Se è il database a mostrare a ciascun utente solo le righe della sua organizzazione, anche una query scritta di fretta restituisce solo ciò che le spetta. Vale per l’interfaccia, per le API, per gli agenti AI e per i job in coda.
• Una copia dei dati non deve dare accesso. Le chiavi di sessione si conservano come impronta (hash), non in chiaro: un backup finito in mani sbagliate non permette di entrare come un altro utente, amministratori compresi.
• Lo storico non si cancella dall’applicazione. L’applicazione può solo aggiungere righe, non modificarle né eliminarle. Chi entra, o un errore nel codice, non può ripulire le proprie tracce.
• Il contesto non è un parametro. L’organizzazione su cui si lavora è scritta nel collegamento e non è un argomento che chi chiama può cambiare. Se un testo nascosto in un documento suggerisse a un agente di guardare un altro cliente, non esisterebbe un modo per farlo.
• Niente strumenti generici. Nessuna funzione tipo “esegui una query” o “scarica questo indirizzo”: ogni operazione esposta ha un nome, un permesso e uno schema. Un perimetro che non esiste non si allarga per sbaglio.

Il costo, e perché lo si paga una volta sola

Non è gratis. Le regole del database vanno scritte nel modo giusto (una forma sbagliata può costare molto in prestazioni) e ogni protezione in più è codice da collaudare. Ma sono costi che si pagano una volta, nelle fondamenta: un modulo nuovo le eredita senza che chi lo scrive debba ricordarsi di niente.

È la stessa logica per cui conviene sistemare i dati prima di comprare strumenti: il lavoro noioso fatto presto rende affidabile tutto ciò che viene dopo. Una dichiarazione di parte: sono le regole su cui stiamo costruendo il nostro nuovo core e che applichiamo ai sistemi per i clienti, in particolare sulle web app e sull’infrastruttura.