Torna al Blog
29 aprile 2026

Come mettere in sicurezza i tuoi endpoint API contro gli attacchi BOLA

Hai costruito un'API elegante. È veloce, scalabile e alimenta un'ottima esperienza utente. Probabilmente hai spuntato le caselle per le basi: hai abilitato HTTPS, stai usando JWT o API keys per l'autenticazione e forse hai persino eseguito uno scanner di vulnerabilità. Ti senti al sicuro. Ma c'è un killer silenzioso nel mondo della sicurezza delle API che gli scanner tradizionali spesso mancano, e non richiede un exploit complesso o un payload sofisticato per funzionare.

Si chiama BOLA—Broken Object Level Authorization.

Se non hai familiarità con il termine, BOLA è essenzialmente il trucco dello "scambio di ID". Immagina che un utente acceda alla tua app e veda il suo profilo su api.example.com/user/12345. Nota il numero alla fine. Per capriccio, cambia 12345 in 12346. Se il tuo server restituisce felicemente i dati privati dell'utente 12346 senza verificare se il richiedente abbia effettivamente il permesso di vederli, hai una vulnerabilità BOLA.

Sembra semplice, quasi troppo semplice. Ma questa semplicità è il motivo per cui BOLA è costantemente classificata come la minaccia numero 1 nell'OWASP API Security Top 10. Perché? Perché non è un fallimento dell'autenticazione (sapere chi è l'utente), ma un fallimento dell'autorizzazione (sapere cosa l'utente è autorizzato a fare).

Proteggere i tuoi endpoint API dagli attacchi BOLA non significa aggiungere un firewall più grande; si tratta di cambiare il modo in cui la tua applicazione gestisce la proprietà dei dati. In questa guida, analizzeremo esattamente come funziona BOLA, perché si verifica e i passi concreti che puoi intraprendere per bloccare definitivamente i tuoi endpoint.

Cos'è esattamente BOLA e perché è così pericolosa?

Per capire BOLA, dobbiamo distinguere tra autenticazione e autorizzazione. Questi due termini vengono usati in modo intercambiabile, ma nel contesto della sicurezza delle API, sono mondi a parte.

L'autenticazione è il processo di verifica dell'identità di un utente. "Sei chi dici di essere?" Quando un utente fornisce una password o un token e il tuo sistema dice "Sì", è autenticato.

L'autorizzazione è il processo di verifica dei permessi. "Ora che so chi sei, ti è consentito accedere a questo specifico dato?"

BOLA si verifica quando un'applicazione fornisce accesso a un oggetto (un record di database, un file, un account utente) basandosi su input forniti dall'utente, ma non riesce a verificare che l'utente autenticato sia effettivamente il proprietario o abbia il permesso di accedere a quell'oggetto.

L'anatomia di un attacco BOLA

Un tipico attacco BOLA segue uno schema molto prevedibile:

  1. Osservazione: L'attaccante crea un account legittimo sulla tua piattaforma. Inizia a usare l'app e nota che le richieste API utilizzano identificatori prevedibili (come numeri interi) nell'URL.
  2. Manipolazione: L'attaccante utilizza uno strumento proxy (come Burp Suite o Postman) per intercettare una richiesta. Vede una richiesta come GET /api/v1/orders/9876.
  3. Iterazione: L'attaccante cambia 9876 in 9875, 9874 e così via.
  4. Esfiltrazione: Se il server non verifica la proprietà dell'ordine 9875, restituisce i dati. L'attaccante scrive quindi un semplice script per scorrere migliaia di ID, estraendo l'intero database in pochi minuti.

Perché gli strumenti di sicurezza tradizionali non riescono a rilevare BOLA

Se stai utilizzando un Web Application Firewall (WAF) standard o un semplice scanner di vulnerabilità, potresti chiederti perché non ti abbiano avvertito di questo.

Il problema è che gli attacchi BOLA assomigliano a traffico perfettamente legale. Per un WAF, una richiesta per /api/v1/orders/9875 sembra identica a una richiesta per /api/v1/orders/9876. Entrambe sono richieste HTTP GET valide. Entrambe hanno un token di autenticazione valido. L'"attacco" si verifica nella logica di business del tuo codice, non nella formattazione della richiesta.

È qui che il divario tra "scansione" e "test" diventa evidente. Uno scanner cerca firme note (come stringhe di SQL Injection); un Penetration Test cerca difetti logici. Ecco perché i team si stanno orientando verso la Continuous Threat Exposure Management (CTEM) e utilizzano piattaforme come Penetrify. Hai bisogno di un sistema che comprenda il contesto delle tue chiamate API, non solo se la richiesta è "ben formata".

Scenari Comuni in Cui BOLA si Insinua

BOLA non è limitato a un solo tipo di endpoint. Tende a manifestarsi ovunque venga utilizzato un ID univoco per recuperare dati. Ecco alcuni dei luoghi più comuni in cui si nasconde.

Profili Utente e Impostazioni Account

Questo è l'esempio classico. Endpoint come /api/users/{userId}/settings o /api/me/profile sono obiettivi primari. Se il backend prende semplicemente lo {userId} dall'URL e interroga il database senza verificare se current_user.id == requested_userId, qualsiasi utente autenticato può visualizzare o modificare le impostazioni di qualsiasi altro utente.

E-commerce e Cronologia Ordini

Pensa a una pagina "I miei ordini". L'API potrebbe chiamare /api/orders/{orderId}. Un attaccante può semplicemente incrementare l'orderId per vedere gli acquisti, gli indirizzi e i numeri di telefono di altre persone. Questa è una miniera d'oro per i ladri di identità.

Isolamento del Tenant SaaS

Per le aziende che sviluppano app SaaS multi-tenant, BOLA può essere catastrofico. Se hai una struttura come /api/tenant/{tenantId}/projects, e un utente del Tenant A può accedere ai progetti del Tenant B semplicemente modificando il tenantId, hai una massiccia violazione dei dati. Questo non è solo un bug; è un fallimento fondamentale dell'isolamento del tenant.

Caricamento e Download di File

Molte app archiviano file (fatture, ID, foto) e li servono tramite endpoint come /api/files/download?fileId=5542. Se il sistema non verifica se l'utente ha il permesso di accedere a fileId 5542, un attaccante può estrarre ogni documento caricato sulla tua piattaforma.

Guida Passo-Passo all'Implementazione delle Difese BOLA

Quindi, come si ferma effettivamente tutto questo? Richiede un approccio a più livelli. Non puoi affidarti a un'unica soluzione "miracolosa". Invece, devi integrare l'autorizzazione nel tessuto stesso della progettazione della tua API.

1. Implementare Controlli di Autorizzazione Rigorosi a Livello di Oggetto

Il modo più diretto per fermare BOLA è verificare la proprietà su ogni singola richiesta che accede a una risorsa.

Il modo sbagliato (Pseudo-codice):

app.get('/api/orders/:orderId', async (req, res) => {
  const order = await db.Orders.findOne({ id: req.params.orderId });
  res.json(order); 
  // PERICOLO: Nessun controllo se l'ordine appartiene all'utente!
});

Il modo giusto (Pseudo-codice):

app.get('/api/orders/:orderId', async (req, res) => {
  const userId = req.user.id; // Get ID from the authenticated JWT
  const orderId = req.params.orderId;

  const order = await db.Orders.findOne({
    where: {
      id: orderId,
      userId: userId // MUST filter by the owner's ID
    }
  });

  if (!order) {
    return res.status(404).send('Order not found');
    // Use 404 instead of 403 to avoid leaking that the ID exists
  }
  res.json(order);
});

Includendo lo userId nella query del database, ti assicuri che il database restituisca il record solo se appartiene alla persona che lo richiede. Se l'ID esiste ma non appartiene all'utente, la query restituisce null e invii un 404.

2. Sostituisci gli ID Prevedibili con gli UUID

L'utilizzo di numeri interi sequenziali (1, 2, 3...) per le chiavi primarie è un regalo per gli attaccanti. Rende banali l'"ID walking" o l'"enumeration".

Sebbene l'utilizzo di UUID (Universally Unique Identifiers) non risolva il bug di autorizzazione sottostante, rende quasi impossibile per un attaccante indovinare un ID valido.

  • ID Sequenziale: 1001 $\rightarrow$ il successivo è 1002.
  • UUID: 550e8400-e29b-41d4-a716-446655440000.

Il passaggio agli UUID aumenta il "costo" dell'attacco. Un attaccante non può semplicemente scrivere un ciclo for da 1 a 10.000. Dovrebbe prima trovare un UUID valido. Tuttavia, ricorda: gli UUID sono offuscamento, non sicurezza. Se un attaccante trova un UUID in un log trapelato o in una diversa risposta dell'API, può comunque sfruttare una vulnerabilità BOLA se i tuoi controlli di autorizzazione sono mancanti.

3. Utilizza un Middleware di Autorizzazione Centralizzato

Scrivere la logica di autorizzazione all'interno di ogni singolo controller è una ricetta per il disastro. Te ne dimenticherai uno. Ti sfuggirà un caso limite.

Sposta invece la tua logica di autorizzazione in un middleware o in un servizio dedicato. Ciò garantisce una policy coerente per l'intera API. Puoi implementare un sistema di controllo degli accessi basato su policy in cui definisci chi può eseguire quale azione su quale risorsa.

Ad esempio, un middleware potrebbe controllare: canUserAccessResource(user, resourceType, resourceId, action)

Se lavori in un ambiente complesso con più provider cloud (AWS, Azure, GCP), la gestione di queste autorizzazioni può diventare complicata. È qui che l'orchestrazione automatizzata della sicurezza diventa vitale. Strumenti come Penetrify ti aiutano a mappare la tua superficie di attacco e a simulare questi tipi di attacchi di "scambio di ID" nei tuoi ambienti per trovare le lacune che i tuoi sviluppatori potrebbero aver trascurato.

4. Implementa il Rate Limiting e il Rilevamento delle Anomalie

Un attacco BOLA di solito comporta un elevato volume di richieste in un breve lasso di tempo mentre l'attaccante tenta di estrarre dati. Sebbene il rate limiting non fermerà una singola richiesta BOLA mirata, fermerà un tentativo di esfiltrazione di massa di dati.

  • Limiti di Rate per Utente: Limita il numero di richieste che un singolo utente autenticato può effettuare a endpoint sensibili.
  • Monitoraggio 404: Se un singolo utente attiva 500 errori "Not Found" in un minuto su un endpoint come /api/orders/{id}, sta quasi certamente cercando ID validi. Attiva un avviso o banna temporaneamente l'IP/account.

BOLA in Diverse Architetture API: GraphQL e REST

Il modo in cui combatti BOLA dipende leggermente da come è strutturata la tua API.

BOLA nelle API REST

In REST, BOLA si verifica solitamente nel percorso URL (come abbiamo discusso). La soluzione è semplice: validare sempre che il userId estratto dalla sessione/token abbia una relazione con il resourceId nell'URL.

BOLA in GraphQL

GraphQL è un po' più complesso perché utilizza un singolo endpoint (solitamente /graphql) e un linguaggio di query. Gli attaccanti non modificano l'URL; modificano gli argomenti all'interno della query.

Esempio di Query GraphQL:

query {
  user(id: "12345") {
    email
    phoneNumber
    creditCardLastFour
  }
}

Un attaccante modifica semplicemente l'argomento id. Poiché GraphQL spesso implica il "nesting" (il recupero di un utente, poi dei suoi ordini, poi dei dettagli di spedizione di tali ordini), una singola vulnerabilità BOLA in un resolver può portare a una massiccia cascata di fuga di dati.

La Soluzione per GraphQL: L'autorizzazione deve avvenire a livello di resolver. Ogni resolver che recupera un oggetto dal database deve eseguire lo stesso controllo di proprietà che abbiamo discusso per le API REST. Non si deve presumere che, poiché la query di primo livello è stata autorizzata, lo siano anche gli oggetti nidificati.

Confronto tra Penetration Testing Manuale e Rilevamento BOLA Automatizzato

Se BOLA è così pericolosa, perché non assumere semplicemente un'azienda di Penetration Testing una volta all'anno? Ecco la realtà del modello "una volta all'anno".

Caratteristica Penetration Test Manuale Tradizionale Testing Automatizzato Continuo (es. Penetrify)
Frequenza Annuale o Semestrale Su Richiesta / Continuo
Costo Elevato (Costi di aziende specializzate) Basato su Abbonamento / Scalabile
Copertura Profonda ma istantanea Ampia e si evolve con i cambiamenti del codice
Ciclo di Feedback Settimane dopo il test In tempo reale o quasi in tempo reale
Integrazione CI/CD Nessuna (Consegna manuale) Integrato in DevSecOps

I tester manuali sono eccellenti nel trovare difetti logici complessi, ma non possono essere presenti ogni volta che i vostri sviluppatori inviano un nuovo commit in produzione. Se uno sviluppatore aggiunge un nuovo endpoint /api/v1/user-preferences di martedì, e il vostro ultimo Penetration Test è stato a gennaio, quell'endpoint è una porta aperta per BOLA fino al prossimo gennaio.

Per questo motivo sosteniamo il Penetration Testing as a Service (PTaaS). Automatizzando le fasi di ricognizione e scansione, potete muovervi verso la Gestione Continua dell'Esposizione alle Minacce (CTEM). Non state solo cercando "bug"; state simulando il comportamento di un attaccante che cerca di manipolare gli ID degli oggetti.

Strategie Avanzate per Ambienti ad Alta Sicurezza

Per coloro che gestiscono dati altamente sensibili (cartelle cliniche, transazioni finanziarie, dati governativi), "abbastanza buono" non è sufficiente. Avete bisogno di una strategia di difesa in profondità.

1. Utilizzare Riferimenti Indiretti agli Oggetti (Basati su Mappa)

Se non potete assolutamente fidarvi del client con alcuna versione di un ID di database, utilizzate una mappa specifica per la sessione.

Invece di esporre order_id: 9876 all'utente, il vostro server genera una chiave temporanea casuale per quella sessione:

  • TemporaryKey_A $\rightarrow$ order_id: 9876
  • TemporaryKey_B $\rightarrow$ order_id: 9877

Il client vede solo TemporaryKey_A. Se tenta di indovinare TemporaryKey_C, questo non esiste nella sua mappa di sessione e la richiesta fallisce. Ciò elimina completamente la prevedibilità dell'ID.

2. Controllo degli Accessi Basato sugli Attributi (ABAC)

Man mano che la tua organizzazione cresce, il Controllo degli Accessi Basato sui Ruoli (RBAC), come "Admin" o "User", diventa troppo generico. Hai bisogno di ABAC.

ABAC ti permette di definire policy basate su attributi:

  • Attributo Utente: ClearanceLevel: Level 2
  • Attributo Risorsa: Sensitivity: Level 2
  • Attributo Ambiente: AccessTime: 9am-5pm

Un controllo BOLA in un sistema ABAC sarebbe simile a: "Questo utente può accedere a questo oggetto se il dipartimento dell'utente corrisponde al dipartimento dell'oggetto E l'oggetto non è contrassegnato come 'Privato'?" Questo fornisce un livello di sicurezza molto più granulare.

3. Firme Digitali per gli ID

Alcune API ad alta sicurezza firmano i loro ID. Quando il server invia un ID al client, allega una firma crittografica (un HMAC). Quando il client rimanda l'ID, il server verifica la firma. Se l'utente cambia 123 in 124, la firma diventa non valida e il server rifiuta immediatamente la richiesta, prima ancora che raggiunga il database.

Errori Comuni nel Tentativo di Correggere BOLA

Anche gli sviluppatori esperti commettono questi errori. Se stai effettuando un audit del tuo codice, fai attenzione a questi schemi.

Errore 1: Affidarsi al Frontend per Nascondere i Pulsanti

"L'utente non può accedere alla pagina 'Modifica' perché ho nascosto il pulsante nell'interfaccia utente React." Questa è sicurezza per oscurità. Un attaccante non usa la tua interfaccia utente; usa un terminale o un proxy. Assumi sempre che l'attaccante conosca ogni singolo endpoint API che hai.

Errore 2: Controllare l'Autorizzazione Solo al Punto di Ingresso

Gli sviluppatori spesso controllano se un utente è loggato all'inizio di una richiesta e poi assumono che tutto ciò che è all'interno di quella richiesta sia sicuro.

  • Sbagliato: if (!user.isAuthenticated) return 401; $\rightarrow$ procedere al recupero di qualsiasi ID.
  • Corretto: if (!user.isAuthenticated) return 401; $\rightarrow$ if (!user.owns(resourceId)) return 404;.

Errore 3: Rivelare ID Validi in Altri Endpoint

Potresti aver corretto BOLA sul tuo endpoint /api/orders, ma hai un endpoint /api/search/users che restituisce un elenco di tutti gli ID utente? Se sì, hai appena fornito all'attaccante la mappa di cui ha bisogno per attaccare i tuoi altri endpoint. Riduci sempre al minimo la quantità di dati ID che esponi nelle viste di "elenco" o "ricerca".

Errore 4: Usare 403 Forbidden Invece di 404 Not Found

Quando un utente richiede un oggetto che non possiede, restituire 403 Forbidden dice all'attaccante: "Questo oggetto esiste, ma non ti è consentito vederlo." Restituendo 404 Not Found, dici all'attaccante: "Non ho idea di cosa tu stia parlando." Questo impedisce all'attaccante di confermare se un ID specifico sia valido o meno.

La Checklist per l'Audit BOLA per il Tuo Team

Se stai guidando un team DevOps o di sicurezza, puoi usare questa checklist durante la tua prossima sprint review o audit di sicurezza.

  • Inventario: Abbiamo un elenco completo di tutti gli endpoint API che accettano un ID come parametro?
  • Identità: Stiamo estraendo l'ID Utente da un token sicuro lato server (come un JWT) invece di fidarci di un ID Utente inviato nel corpo della richiesta o nell'URL?
  • Proprietà: Ogni query del database per una risorsa specifica include un filtro per l'ID Utente o l'ID Tenant proprietario?
  • Prevedibilità: Stiamo utilizzando UUID o altri identificatori non sequenziali per le risorse esposte pubblicamente?
  • Coerenza: L'autorizzazione è gestita in un middleware o servizio centralizzato anziché essere duplicata in ogni controller?
  • Gestione degli Errori: Stiamo restituendo 404 invece di 403 per l'accesso non autorizzato agli oggetti?
  • Limitazione della Frequenza: Abbiamo avvisi per gli utenti che attivano un numero insolito di 404 sugli endpoint delle risorse?
  • Test: Stiamo eseguendo test automatizzati di "scambio di ID" come parte della nostra pipeline CI/CD?

Come Penetrify Semplifica il Rilevamento di BOLA

Trovare manualmente le vulnerabilità BOLA è noioso. È necessario mappare ogni endpoint, creare più account utente e testare manualmente ogni combinazione di ID. Per un piccolo team, questo è un compito impossibile. Per un team grande, è un collo di bottiglia.

Questo è esattamente il motivo per cui Penetrify è stato creato. Invece di affidarsi a una scansione statica che cerca "librerie obsolete", Penetrify si concentra sulla superficie di attacco.

Ecco come ti aiuta a risolvere il problema BOLA:

  1. Mappatura Automatica della Superficie di Attacco: Penetrify identifica tutti i tuoi endpoint esposti, inclusi quelli che i tuoi sviluppatori potrebbero aver dimenticato di documentare.
  2. Simulazione Intelligente della Logica: La piattaforma non si limita a inviare stringhe casuali; analizza come sono strutturati i tuoi ID e tenta di simulare il comportamento di "ID walking" utilizzato dai Penetration Tester manuali.
  3. Monitoraggio Continuo: Essendo cloud-native, Penetrify può essere integrato nel tuo flusso di lavoro DevSecOps. Ogni volta che distribuisci una nuova versione della tua API, rivaluta il tuo perimetro di sicurezza.
  4. Rimediazione Azionabile: Non ricevi solo un rapporto che dice "Hai un bug BOLA". Ricevi indicazioni specifiche su quale endpoint è vulnerabile e su come implementare il controllo di autorizzazione per risolverlo.

Colmando il divario tra un semplice scanner di vulnerabilità e un costoso audit manuale, Penetrify consente a PMI e startup SaaS di dimostrare la propria maturità di sicurezza (per la conformità SOC 2 o HIPAA) senza la necessità di un Red Team interno su vasta scala.

Domande Frequenti (FAQ)

D: Non posso semplicemente usare un WAF per fermare BOLA?

Non in modo efficace. Come accennato, gli attacchi BOLA utilizzano sintassi e autenticazione valide. Un WAF esamina la struttura della richiesta, mentre BOLA è un fallimento della logica di business. Sebbene un WAF possa aiutare con la limitazione della frequenza per rallentare un attaccante, non può determinare se l'Utente A debba avere accesso all'Ordine B.

D: L'uso di JWT (JSON Web Tokens) previene BOLA?

No. I JWT gestiscono l'autenticazione (dimostrando chi è l'utente). Non gestiscono l'autorizzazione (a cosa l'utente può accedere). Un utente può avere un JWT perfettamente valido e firmato e usarlo comunque per richiedere un oggetto che non gli appartiene se il tuo backend non esegue il controllo di proprietà.

D: Se utilizzo un database NoSQL come MongoDB, sono comunque a rischio?

Sì. BOLA è indipendente dal tipo di database. Sia che si utilizzi un _id di MongoDB (che sono naturalmente più complessi degli interi) o una sequenza PostgreSQL, la vulnerabilità esiste se l'applicazione consente a un utente di richiedere un record tramite un ID senza verificarne la proprietà.

D: BOLA è la stessa cosa di IDOR?

In sostanza, sì. IDOR (Insecure Direct Object Reference) è il termine più vecchio e più ampio. BOLA è la terminologia moderna specificamente adattata alle API. Nel contesto di un'API, un attacco BOLA è una forma di IDOR.

D: Come si testa la BOLA senza acquistare uno strumento costoso?

Puoi iniziare utilizzando un proxy come Burp Suite (Community Edition). Crea due account utente separati. Accedi come Utente A, cattura una richiesta per una risorsa di tua proprietà e poi sostituisci l'ID della risorsa con un ID che appartiene all'Utente B. Se riesci a vedere i dati dell'Utente B mentre sei loggato come Utente A, hai una vulnerabilità BOLA.

Considerazioni Finali: Andare Oltre la Sicurezza Puntuale

L'errore più grande che un'azienda può commettere nella sicurezza delle API è credere che un singolo report di Penetration Test "pulito" significhi essere sicuri. La sicurezza non è una destinazione; è uno stato di manutenzione costante.

Il tuo codice cambia ogni giorno. La tua infrastruttura si evolve. Nuovi endpoint vengono aggiunti per soddisfare una richiesta del cliente. Ognuno di questi cambiamenti è un'opportunità per una vulnerabilità BOLA di passare inosservata.

La transizione da "audit annuali" a "Continuous Threat Exposure Management" è l'unico modo per rimanere un passo avanti agli attaccanti moderni. Combinando una logica di autorizzazione rigorosa, ID non prevedibili e piattaforme di testing automatizzate come Penetrify, puoi smettere di trattare la sicurezza come una casella da spuntare e iniziare a trattarla come una funzionalità fondamentale del tuo prodotto.

Non aspettare una violazione dei dati per scoprire che la tua logica di autorizzazione è difettosa. Inizia a controllare i tuoi endpoint oggi stesso, implementa i controlli di proprietà che abbiamo discusso e automatizza i tuoi test in modo da poterti concentrare sulla costruzione del tuo prodotto invece di preoccuparti del prossimo attacco di "scambio di ID".

Pronto a scoprire se le tue API sono realmente sicure? Smetti di tirare a indovinare e inizia a testare. Visita Penetrify per scoprire come il testing di sicurezza automatizzato e on-demand può proteggere i tuoi dati e la tua reputazione.

Torna al Blog