Importi decisi dall'interfaccia
Un flusso che si fida del prezzo o dell'importo inviato dall'interfaccia.
home / risorse / vulnerabilità / A06
OWASP Top 10 2025 · posizione 6
Progettazione insicura (OWASP A06)
Il difetto non è nell'implementazione: il progetto non prevede il controllo. Nel 2025 la categoria scende dal quarto al sesto posto, ma è la più difficile da correggere con una patch.
cos'è
Nessuna correzione del codice basta.
Un flusso progettato senza un controllo non si ripara aggiungendo una riga: serve ripensare la sequenza, le regole o i limiti.
È la categoria in cui un test automatico trova meno, perché il difetto è nel comportamento atteso dell'applicazione, non in un singolo punto del codice.
forme comuni
Quattro esempi di progetto debole.
Recupero basato su domande deboli
Il reset dell'account si basa su informazioni facili da conoscere.
Nessun limite alle operazioni
Azioni sensibili ripetibili senza soglie o controlli di frequenza.
Ruoli non modellati
Il progetto non distingue chi può fare cosa, e la distinzione è rimandata all'implementazione.
impatto tipico
Cosa può succedere all'azienda.
Frodi di logica
Ordini, sconti o rimborsi ottenuti seguendo una sequenza non prevista.
Abusi automatici
Operazioni ripetute in massa che il progetto non ha previsto.
Dati esposti per scelta
Informazioni rese disponibili perché il progetto non le considerava sensibili.
Correzioni costose
Un difetto di progetto richiede di rifare il flusso, non di applicare una patch.
come lo verifichiamo
Si verifica il comportamento, non solo il codice.
Modello delle minacce
Si descrive il flusso e si elencano le minacce che lo riguardano.
Casi limite
Si provano i casi che il progetto non ha previsto: sequenze, valori estremi, ripetizioni.
Ruoli e regole di business
Le regole sono confrontate con la matrice dei ruoli e con ciò che il business ha deciso.
Revisione
Una persona valuta cosa cambiare nel progetto, non solo nel codice.
come si corregge
La sicurezza va progettata prima del codice.
Da fare
- Modellare le minacce prima di sviluppare
- Definire i casi limite e le sequenze non ammesse
- Limitare le operazioni sensibili con soglie e controlli
- Verificare le regole di business sul server
Da evitare
- Fidarsi della sequenza che l'interfaccia propone
- Rimandare la sicurezza a dopo il rilascio
- Decidere i prezzi o i ruoli nel browser
La logica di business è il terreno più difficile. Gli scanner automatici trovano difetti tecnici. Le regole di business vanno verificate con chi conosce il processo.
Vuoi verificare la logica del tuo flusso più sensibile?
Il servizio Accessi e logica di business parte dalla matrice dei ruoli e dai flussi.