Accesso concesso in caso di errore
Un controllo che non risponde lascia passare la richiesta.
home / risorse / vulnerabilità / A10
OWASP Top 10 2025 · posizione 10
Condizioni eccezionali (OWASP A10)
Quando qualcosa va storto, il sistema può fallire in uno stato non sicuro: aprire un accesso, saltare un controllo o rivelare dettagli interni. È una categoria nuova nel 2025.
cos'è
Gli errori vanno progettati.
Un errore, un timeout o un dato mancante sono situazioni normali. Il punto critico è cosa fa il sistema in quel momento: se nega l'accesso o se lo concede.
Un controllo che non risponde non deve diventare un permesso. Questo è il principio del fallimento sicuro, e il 2025 lo ha reso una categoria a sé.
forme comuni
Quattro comportamenti da verificare.
Eccezioni che rivelano tutto
Messaggi di errore con dettagli tecnici visibili all'utente.
Controlli saltati per timeout
Una verifica che non si completa in tempo viene ignorata invece che bloccare l'operazione.
Stati incoerenti
Un'operazione parzialmente riuscita lascia dati o permessi non allineati.
impatto tipico
Cosa può succedere all'azienda.
Controlli aggirati
Un errore indotto dall'esterno apre una porta che il progetto teneva chiusa.
Informazioni tecniche esposte
Dettagli di sistema visibili a chi non dovrebbe conoscerli.
Dati incoerenti
Operazioni a metà che lasciano saldi, stati o permessi sbagliati.
Interruzioni prolungate
Un sistema che non sa come reagire resta fermo più a lungo.
come lo verifichiamo
Si provano i casi in cui qualcosa non va.
Mappa dei controlli
Si individuano i controlli che possono non rispondere: autorizzazione, pagamento, verifica.
Comportamento in errore
Si verifica cosa accade quando il controllo fallisce o non risponde.
Messaggi e dettagli
Si controlla cosa vede l'utente quando l'applicazione si rompe.
Revisione
Una persona valuta l'impatto di ogni stato non sicuro.
come si corregge
Negare quando c'è un dubbio.
Da fare
- Fallire chiusi: negare in caso di dubbio o di errore
- Gestire ogni eccezione in modo esplicito
- Mostrare all'utente messaggi generici
- Testare i casi di errore come i casi normali
Da evitare
- Permettere l'accesso quando un controllo non risponde
- Lasciare le eccezioni senza gestione
- Mostrare stack trace o dettagli interni agli utenti
Gli errori sono un caso d'uso. Un errore non è un'eccezione rara: è una situazione che il progetto deve prevedere, come qualsiasi altro percorso.
Vuoi verificare cosa fa la tua applicazione quando qualcosa va storto?
I casi di errore sono inclusi nel metodo di revisione del progetto.