A01:2025 Broken Access Control: chi può fare cosa

È la voce numero uno della OWASP Top 10:2025, e non per un pelo: nel 100% delle applicazioni testate è stata trovata una qualche forma di controllo accessi che si è rotto. Il concetto di fondo è semplice: sapere chi sei (autenticazione) non basta, serve anche sapere cosa puoi fare (autorizzazione), e farlo rispettare a ogni singola richiesta.

1. IDOR: cambiare un numero nell'URL

L'Insecure Direct Object Reference (IDOR) è la forma più comune: l'app usa un identificatore fornito dall'utente per recuperare una risorsa, senza verificare che quella risorsa gli appartenga.

GET /app/accountInfo?acct=1042 // il tuo conto 
GET /app/accountInfo?acct=1043 // provi a cambiare il numero e ti accorgi di consultare un altro conto di un altro utente

Fix lato server: prima di restituire o modificare qualsiasi record, controlla sempre che appartenga a chi sta chiedendo. Il modello di accesso deve far rispettare la proprietà del record, non limitarsi a verificare che l'utente sia loggato.

Fonte: OWASP Top 10:2025: A01 Broken Access Control: «insecure direct object references» tra le vulnerabilità comuni.

2. Controlli mancanti a livello di funzione

Qui il problema non è quale record, ma quale funzione: un endpoint amministrativo che dovrebbe richiedere il ruolo admin, ma in realtà risponde a chiunque lo chiami.

https://example.com/app/getAppInfo // pagina normale 
https://example.com/app/admin_getAppInfo // pagina admin: risponde anche senza permessi?

Una variante pericolosa: nascondere il pulsante «admin» solo nell'interfaccia, lasciando l'endpoint raggiungibile. Un attaccante non ha bisogno del pulsante, gli basta utilizzare curl:

$ curl https://example.com/app/admin_getAppInfo #se il server risponde, il controllo esisteva solo nel browser

3. Directory traversal: uscire dalla cartella prevista

Se il nome di un file arriva dall'utente e viene usato per leggere dal filesystem senza controlli, un percorso tipo ../../ può far «risalire» fuori dalla cartella prevista fino a file di sistema.

GET /download?file=fattura.pdf 
GET /download?file=../../../../etc/passwd    //path traversal

Fix lato server: non fidarsi mai del percorso ricevuto. Risolvi il percorso reale (in PHP: realpath()), verifica che resti dentro la cartella consentita, e preferisci basename() per isolare solo il nome del file. Disabilita anche il listing delle directory sul server.

4. SSRF: quando il server è costretto a fare da postino

Novità della Top 10 2025: lo Server-Side Request Forgery (SSRF) è stato assorbito dentro A01, perché è, a conti fatti, un fallimento di controllo accessi: l'attaccante convince il tuo server a fare una richiesta al posto suo verso una rete interna che dall'esterno non potrebbe mai raggiungere.

// L'app scarica l'avatar da un URL fornito dall'utente 
GET /avatar?url=https://esempio.com/foto.jpg      //uso previsto 
GET /avatar?url=http://169.254.169.254/latest/meta-data/      //SSRF verso metadata cloud

Fix lato server, secondo il cheat sheet OWASP dedicato: usa un allowlist di domini/IP consentiti (mai una blacklist, sempre incompleta), blocca le richieste verso indirizzi privati e verso l'endpoint dei metadati cloud, e disabilita il seguire automaticamente i redirect: un URL «pulito» può reindirizzare verso uno vietato.

5. Le regole di fondo, secondo OWASP

• Deny by default: nega l'accesso salvo che sia esplicitamente concesso: mai il contrario.
• Un solo meccanismo, riusato ovunque: implementa il controllo accessi una volta e richiamalo in tutta l'app, invece di riscriverlo endpoint per endpoint.
• Solo lato server: un controllo è efficace solo se vive in codice server-side o in API che l'attaccante non può modificare.
• Logga i fallimenti: registra i tentativi di accesso negati e avvisa in caso di ripetizioni sospette.

Fonte: OWASP Top 10:2025: A01, sezione «How to prevent».

In sintesi

Un solo principio le tiene insieme: non fidarti mai del client. Ogni controllo su un record, una funzione, un file, un URL deve essere rifatto e fatto rispettare sul server, ogni volta.