Autorizzazione a livello di oggetto (BOLA)
Un utente può leggere o modificare risorse di un altro utente cambiando un ID in una richiesta? È il controllo più frequente e più grave, e lo verifichiamo su ogni endpoint che riceve un identificatore.
API security · OWASP API Security Top 10 · Da €490
Penetration test API REST secondo l'OWASP API Security Top 10
Le API espongono dati e funzioni direttamente, spesso senza un'interfaccia che li filtri. I rischi più frequenti riguardano l'autorizzazione a livello di oggetto (BOLA), l'autenticazione e la gestione dei token, l'esposizione eccessiva di dati e la logica di business. Li verifichiamo uno per uno, con prove riproducibili.
Perché le API richiedono un test specifico
Un'applicazione web ha un'interfaccia che guida l'utente. Un'API no: chiunque può inviare richieste, modificarne i parametri e leggere le risposte. Se il server non controlla bene chi può fare cosa, la falla è spesso invisibile da un browser e facile da sfruttare da uno script.
La lista OWASP API Security Top 10 è separata da quella delle applicazioni web, perché i rischi sono diversi. Al primo posto c'è l'autorizzazione a livello di oggetto: nella pratica, un utente legittimo che modifica un identificatore e legge dati di un altro utente.
I controlli che eseguiamo sulle API
Quattro famiglie di verifiche, con più ruoli di prova per misurare davvero il controllo tra utenti.
Autenticazione e token
Gestione di login, emissione e scadenza dei token, revoca alla disconnessione, protezione delle chiavi, possibilità di accesso con token scaduti o manomessi.
Esposizione dati e limiti
Le risposte restituiscono più campi del necessario? Esistono limiti alle richieste per endpoint sensibili, come login o recupero password, e paginazioni che consentono di estrarre grandi volumi di dati?
Logica di business
Flussi che si possono aggirare: prezzi o quantità modificabili dal client, stati di un ordine saltabili, operazioni eseguibili in ordine errato o più volte.
Come lavoriamo su un'API, passo per passo
Quattro fasi, con il responsabile dell'API informato a ogni passaggio e nessuna azione fuori dal perimetro concordato.
1. Mappatura degli endpoint
Individuiamo endpoint, metodi, parametri, formati e schemi di autenticazione, partendo dalla documentazione quando è disponibile e dall'osservazione del traffico nell'ambiente di test.
2. Verifica dei controlli esistenti
Osserviamo come il sistema risponde a richieste senza credenziali, con credenziali scadute, con ruoli diversi, e a input non previsti. Sono le basi su cui costruire i test successivi.
3. Attacchi specifici per API
Eseguiamo i test mirati su autorizzazione, token, esposizione dati e logica di business, con prove di impatto e senza azioni distruttive.
4. Report e riverifica
Il report arriva al responsabile dell'API con priorità, prove riproducibili e indicazioni di correzione. La riverifica gratuita entro 30 giorni chiude il ciclo.
Cosa ci serve per lavorare bene
Nessuno di questi elementi è obbligatorio, ma ciascuno riduce i tempi e migliora la copertura.
Documentazione delle API
Una specifica OpenAPI o Swagger, anche parziale. Ci permette di coprire più endpoint in meno tempo e di non dimenticare quelli meno evidenti.
Account di prova con ruoli diversi
Almeno due utenti con privilegi differenti, e un profilo amministrativo se l'API ne ha uno. Senza di loro non si verifica il controllo tra utenti.
Un ambiente concordato
Preferiamo un ambiente di test equivalente alla produzione, con dati fittizi. Il test in produzione richiede finestre e autorizzazione scritta.
Un referente tecnico
Chi conosce l'API e può rispondere a domande su comportamenti attesi, eccezioni e flussi di business.
Cosa trovano di solito i test sulle API
Non è una lista di casi eccezionali. Sono i problemi che ricorrono più spesso nelle API di applicazioni reali.
- Un endpoint di dettaglio che restituisce dati di un altro utente se l'identificatore viene cambiato.
- Un token che resta valido dopo il logout o dopo il cambio della password.
- Risposte che includono campi interni, come ruoli, flag di amministrazione o identificatori di sistema, non previsti dall'interfaccia.
- Un endpoint di recupero password senza limiti di tentativi, esposto a enumerazione degli account.
- Un checkout che accetta un prezzo o una quantità inviati dal client senza ricalcolarli sul server.
Cosa il test non fa
Per essere chiari sui confini: il test verifica il comportamento dell'API nell'ambiente concordato. Non sostituisce la revisione del codice, né garantisce che un'API nuova sia sicura dopo una modifica. Per questo serve ripetere il test quando l'API cambia.
Quanto costa un test API
Il piano Perimetro singolo costa €490 una tantum, IVA esclusa, per un dominio o un'API esterna con i suoi sottodomini. API molto estese, più ambienti o test di logica di business particolarmente complessa sono su preventivo. Il listino completo è nella home.
Domande frequenti sul penetration test API
Il test API è diverso dal test di un sito web?
Sì. Le API hanno meno interfaccia e più oggetti e ruoli. Spesso il rischio principale è la BOLA, che non richiede di aggirare l'autenticazione: basta un utente legittimo che cambia un identificatore.
Serve la documentazione delle API?
Non è obbligatoria. Con OpenAPI o Swagger copriamo più endpoint in meno tempo e con minor rischio di lasciarne fuori qualcuno.
Si possono testare API in produzione?
Solo con autorizzazione scritta e finestre concordate. Di norma preferiamo un ambiente di test equivalente alla produzione.
Il test può modificare dati reali?
Nell'ambiente di test sì, per dimostrare l'impatto, e sempre su dati fittizi. Non eseguiamo azioni distruttive né cancelliamo risorse, e ogni modifica di prova viene documentata nel report.
Quanto costa?
Il perimetro singolo costa €490 una tantum, IVA esclusa. API estese o più ambienti sono su preventivo.
Hai API esposte e vuoi verificarne l'autorizzazione?
Mandaci la documentazione o l'elenco degli endpoint: ti rispondiamo per iscritto con il perimetro proposto.
Richiedi il test API