Dati di un altro utente
Il sistema usa un identificativo ricevuto dall'esterno senza controllare che appartenga a chi lo chiede.
home / risorse / vulnerabilità / A01
OWASP Top 10 2025 · posizione 1
Controllo degli accessi interrotto (OWASP A01): IDOR e BOLA
Un utente può fare o vedere ciò che non dovrebbe. È la prima categoria dell'elenco 2025, e comprende anche le richieste che il server fa verso destinazioni scelte dall'esterno (SSRF).
cos'è
La regola esiste, ma non viene applicata.
Il controllo degli accessi decide chi può leggere, modificare o eseguire ogni cosa. Quando è interrotto, il sistema verifica che l'utente sia autenticato, ma non che possa accedere proprio a quell'oggetto, a quella funzione o a quel campo.
È una vulnerabilità che nasce quasi sempre dalla logica dell'applicazione, non da un errore tecnico. Per questo gli scanner automatici la rilevano con difficoltà.
forme comuni
Quattro situazioni in cui succede.
Funzioni riservate
Pagine o interfacce amministrative raggiungibili da ruoli che non dovrebbero vederle.
Campi modificabili
Valori che il client non dovrebbe poter scegliere, come un ruolo, un prezzo o uno stato dell'ordine.
Richieste lato server (SSRF)
Il server esegue richieste verso indirizzi indicati dall'utente, anche quando sono risorse interne che non dovrebbe raggiungere.
impatto tipico
Cosa può succedere all'azienda.
Dati personali esposti
Informazioni di clienti o dipendenti visibili a chi non dovrebbe vederle. Con il GDPR questo può far scattare obblighi di notifica.
Azioni amministrative
Operazioni riservate eseguite da utenti normali: cambi di configurazione, rimborsi, accessi ad altri account.
Frodi su prezzi e ordini
Valori modificabili dal cliente che alterano il conto finale.
Accesso alla rete interna
Un server che raggiunge risorse interne su richiesta esterna può portare oltre il perimetro previsto.
come lo verifichiamo
Un metodo che confronta i ruoli, non solo le pagine.
Matrice dei ruoli
Il cliente indica chi dovrebbe poter fare cosa, ruolo per ruolo.
Confronto controllato
Le stesse operazioni vengono eseguite con ruoli diversi, e il risultato viene confrontato con la matrice.
Prova riproducibile
Ogni caso confermato ha i passi, il risultato atteso e quello ottenuto.
Revisione
Una persona valuta l'impatto e assegna la gravità.
come si corregge
Il controllo va fatto sul server, a ogni richiesta.
Da fare
- Verificare l'autorizzazione sul server a ogni richiesta
- Negare per impostazione predefinita
- Separare chiaramente ruoli e funzioni amministrative
- Non fidarsi di identificativi o campi inviati dal client
- Limitare le richieste che il server fa verso destinazioni esterne
Da evitare
- Nascondere pulsanti o pagine nell'interfaccia
- Controllare i ruoli solo nel browser
- Affidarsi a un valore che l'utente può cambiare
Nascondere un pulsante non è un controllo di accesso. È l'errore più comune in questa categoria. Un report sul controllo degli accessi deve mostrare che il server rifiuta la richiesta, non che l'interfaccia non la mostra.
Vuoi verificare il controllo degli accessi della tua applicazione?
Il servizio Accessi e logica di business parte dalla matrice dei ruoli.
fonti
Da dove vengono i dati.
Categoria e posizione: OWASP Top 10 2025, pubblicato a novembre 2025. Verifica il testo sul sito OWASP per le definizioni ufficiali.
Dati sugli ingressi e sulla correzione: Verizon Data Breach Investigations Report 2026. Dati sulle vulnerabilità sfruttate: catalogo CISA KEV.