Broken Access Control: La Vulnerabilità #1 OWASP Spiegata

Il broken access control si piazza al primo posto nell'OWASP Top 10 2021 per una ragione semplice: è ovunque e può avere conseguenze devastanti. Capire questa vulnerabilità è fondamentale per qualsiasi sviluppatore o tester di sicurezza.

La definizione

Il controllo degli accessi (access control) è il meccanismo che garantisce che ogni utente possa fare solo ciò che gli è permesso. Quando questo meccanismo fallisce — perché è assente, incompleto o aggirabileile — parliamo di broken access control.

In termini pratici: l'applicazione non verifica correttamente "ha questo utente il permesso di fare questa cosa?"

Tipologie principali

Insecure Direct Object Reference (IDOR / BOLA)

La forma più comune. Un'applicazione usa identificatori prevedibili (numeri sequenziali, UUID prevedibili) per accedere alle risorse, e non verifica che l'utente che fa la richiesta sia il proprietario di quella risorsa.

Esempio concreto:

GET /api/orders/12345

Sei loggato e vedi il tuo ordine #12345. Cambio manuale a:

GET /api/orders/12346

Se l'applicazione risponde con l'ordine di un altro utente, c'è una vulnerabilità IDOR. Puoi vedere (o peggio, modificare) dati che non ti appartengono.

Escalazione di privilegi verticale

Un utente normale accede a funzionalità riservate agli amministratori.

Esempio: la pagina /admin/users mostra tutti gli utenti. L'applicazione verifica il login ma non che l'utente sia admin. Un utente normale che conosce l'URL può accedervi.

Escalazione di privilegi orizzontale

Un utente accede a risorse di altri utenti con lo stesso livello di privilegi.

Esempio: due utenti dello stesso tier possono vedere i reciproci profili privati o documenti.

Bypass tramite manipolazione dei parametri

L'applicazione usa parametri nel body della richiesta per determinare i permessi dell'utente, e non li valida lato server.

Esempio:

POST /api/purchase
{"userId": 42, "role": "user", "amount": 100}

Un attaccante modifica "role": "admin" per ottenere uno sconto riservato agli admin, o "userId": 43 per effettuare un acquisto a spese di un altro utente.

Missing Function Level Access Control

L'applicazione nasconde funzionalità nell'interfaccia ma non le protegge lato server. L'utente le trova accedendo direttamente all'API.

Impatto reale

Il broken access control ha causato alcune delle più grandi violazioni di dati della storia:

• Accesso a profili privati di milioni di utenti
• Modifica di ordini e transazioni altrui
• Download di documenti riservati (contratti, dati personali)
• Accesso a funzionalità amministrative

Una singola vulnerabilità IDOR ben sfruttata può permettere l'esfiltrazione di tutti i dati di tutti gli utenti di una piattaforma.

Come si difende

Deny by default — per default, accesso negato. Ogni risorsa deve essere esplicitamente autorizzata, non esplicitamente negata.

Verifica server-side sempre — non fidarti mai di dati inviati dal client (ID utente nel body, ruolo nei cookie, parametri URL). Verifica sempre lato server chi è l'utente autenticato e cosa gli è permesso.

Usa identificatori non prevedibili — UUID v4 invece di numeri sequenziali rende l'IDOR molto più difficile da sfruttare (ma non impossibile — la verifica lato server è sempre necessaria).

Log e monitoring — logga tutti gli accessi a risorse sensibili. Anomalie (un utente che accede a centinaia di ID diversi in pochi secondi) dovrebbero generare alert.

Test sistematico — usa test automatizzati che verificano i controlli di accesso su ogni endpoint. Ogni nuovo endpoint deve avere i test di autorizzazione corrispondenti.

Separazione dei contesti — in applicazioni multi-tenant, isola i dati di ogni tenant a livello di database quando possibile, non solo a livello applicativo.

Il broken access control non è una vulnerabilità difficile da correggere tecnicamente. Il problema è che richiede disciplina sistematica: ogni singolo endpoint, ogni singola risorsa, deve avere il controllo. Basta una dimenticanza per aprire una falla.