Test di Sicurezza delle API: 10 Cose che Ogni Principiante Deve Sapere

Le API alimentano quasi ogni applicazione moderna. Quando apri un'app mobile, controlli il saldo del tuo conto, ordini cibo o aggiorni il tuo profilo, un'API sta lavorando in background. Il sito web e la parte che vedi. L'API e la parte che invia, riceve ed elabora i dati.

Questo e anche il motivo per cui le API sono uno degli obiettivi piu importanti per il test di sicurezza. Un sito web puo sembrare sicuro dall'esterno, ma l'API dietro di esso potrebbe ancora esporre dati privati, portando a una violazione dei dati, o accettare azioni dall'utente sbagliato. Molti bug API gravi non vengono trovati attraverso payload complessi. Vengono trovati leggendo attentamente le richieste, cambiando piccoli valori e ponendosi una domanda: questo utente dovrebbe essere autorizzato a fare questo?

Questa guida ti accompagna attraverso tutto cio di cui hai bisogno per iniziare il test di sicurezza delle API, partendo da zero.

1. Cos'e la sicurezza delle API e perche e importante?

Per gli utenti normali, l'applicazione e la schermata che vedono. Per i tester di sicurezza, la vera applicazione vive nel traffico API. Ogni clic su un pulsante, aggiornamento del profilo, caricamento di file, azione di pagamento e cambio di password genera una richiesta API.

L'API e dove risiedono i dati piu sensibili. Se un'API non e adeguatamente protetta, il frontend non puo salvarla. Un pulsante puo essere nascosto, ma la richiesta puo comunque essere inviata manualmente. Un campo puo essere disabilitato nel browser, ma puo comunque essere modificato in Burp Suite. Un'app mobile puo nascondere i dati dallo schermo, ma la risposta API completa potrebbe comunque contenerli.

La regola e semplice: non fidarti mai solo di cio che mostra l'interfaccia utente. Il frontend e il livello di presentazione. La vera sicurezza deve avvenire lato server. Il server deve verificare chi e l'utente, a cosa e autorizzato ad accedere e se i dati inviati sono affidabili.

Come principiante, questa e una buona notizia. Non hai bisogno di competenze di exploitation altamente avanzate. Se comprendi autenticazione, autorizzazione, risposte API e la modifica base delle richieste, puoi gia iniziare a trovare problemi reali di sicurezza delle API.

2. Come un singolo bug IDOR spiega il test di sicurezza delle API

Erano circa le 11 di sera quando Arjun, un bug bounty hunter alle prime armi, stava testando una piattaforma di recruiting. Stava imparando da soli pochi mesi. Creo un account, fece il login, apri il suo profilo e inizio a osservare le richieste in Burp Suite.

Una richiesta attiro la sua attenzione. L'endpoint API sembrava /api/v1/users/1147/profile. La risposta mostrava i dettagli del suo profilo: nome, indirizzo email, numero di telefono e indirizzo salvato. Tutto sembrava normale. Ma poi noto il numero nell'URL. Sembrava un ID utente.

Per curiosita, cambio 1147 in 1148 e invio di nuovo la richiesta. Si aspettava un errore. Forse 403 Forbidden. Forse 404 Not Found. Invece, l'API restitui il profilo completo di un altro utente. Cambio di nuovo il numero. Un altro profilo torno indietro.

Arjun aveva trovato il Broken Object Level Authorization, noto anche come BOLA o IDOR. L'API stava verificando che fosse autenticato, ma non stava controllando se il profilo richiesto appartenesse effettivamente a lui. Questo e uno degli errori di sicurezza API piu comuni e pericolosi.

La lezione: Arjun non ha usato un exploit complesso. Non ha aggirato un firewall. Ha semplicemente cambiato un valore in una richiesta API, e il server ha restituito dati che avrebbero dovuto essere protetti.

Ho visto questo stesso schema centinaia di volte attraverso i miei oltre 250 riconoscimenti nella Hall of Fame. BOLA e costantemente il primo bug reale che i miei studenti trovano, e rimane la vulnerabilita IDOR piu comune in circolazione. La tecnica e semplice, ma l'impatto e quasi sempre critico.

3. I 6 prerequisiti prima di testare le API

Prima di iniziare a testare le API, hai bisogno di una base. Non devi padroneggiare tutto, ma dovresti capire cosa succede quando invii una richiesta e ricevi una risposta.

1. Hardware e reti informatiche. Comprendi come i dispositivi usano le reti per condividere dati. Impara cosa fanno gli indirizzi IP, il DNS e i router. Familiarizza con il modello OSI.

2. Linea di comando e Linux. Dovresti saperti muovere con i comandi Linux di base e una distribuzione per i test come Kali Linux. Leggi file, esegui strumenti, invia richieste e formatta risposte JSON. Impara le basi dello scripting Bash o Python per l'automazione.

3. Fondamenti HTTP. Le API funzionano attraverso richieste HTTP. Una richiesta ha un metodo, degli header e talvolta un body o dei parametri. Conosci i metodi comuni: GET (lettura), POST (creazione), PUT/PATCH (aggiornamento), DELETE (rimozione). Conosci i codici di stato: 200 (successo), 401 (non autorizzato), 403 (proibito), 404 (non trovato), 500 (errore del server).

4. Autenticazione vs. autorizzazione. L'autenticazione significa dimostrare chi sei, come accedere con una password. L'autorizzazione significa decidere cosa sei autorizzato a fare dopo il login. Un utente normale e un amministratore possono essere entrambi autenticati, ma non dovrebbero avere gli stessi permessi. Molti bug API gravi si verificano perche l'autenticazione esiste ma l'autorizzazione e debole o assente. Impara i tipi comuni: Basic, Token-based, JWT, Session, SSO e OAuth.

5. Tipi e struttura delle API. Un'API e un modo per far comunicare due sistemi. Il client invia una richiesta, il server restituisce i dati, solitamente in JSON. Conosci i tipi principali: REST (il piu comune, usa URL standard e metodi HTTP), GraphQL (endpoint singolo, il client specifica esattamente quali dati vuole), SOAP (piu datato, basato su XML, ancora usato nel settore bancario), WebSockets (comunicazione in tempo reale) e gRPC (veloce, moderno, per comunicazione tra servizi). Inizia con REST, poi passa a GraphQL.

6. Burp Suite e Postman. Questi sono gli strumenti piu importanti per il test delle API. Burp Suite ti permette di catturare richieste, modificare valori e osservare le risposte del server. Postman ti aiuta a costruire e organizzare le richieste API. Dedica tempo a usare questi strumenti direttamente invece di limitarti a guardare tutorial.

4. Le 5 vulnerabilita API che incontrerai piu spesso

Esistono molti tipi di vulnerabilita API, ma alcune appaiono continuamente. Queste sono quelle che ogni principiante dovrebbe imparare per prime.

4.1 Broken Object Level Authorization (BOLA/IDOR)

BOLA si verifica quando un'API ti permette di accedere a un oggetto che non ti appartiene. Un oggetto puo essere un profilo, un ordine, una fattura, un ticket, un file, un messaggio o un metodo di pagamento.

Immagina di aprire i dettagli del tuo ordine. La richiesta API e /api/v1/orders/8842. Il server verifica il tuo token e restituisce l'ordine. Ora cambi 8842 in 8843, e il server restituisce l'ordine di qualcun altro. Questo e BOLA.

L'errore e semplice: l'API ha verificato che eri autenticato, ma non ha controllato se l'ordine 8843 appartenesse al tuo account. BOLA occupa la prima posizione nella OWASP API Security Top 10 dalla prima pubblicazione della lista.

Come testare BOLA:

• Cerca ogni richiesta che contiene un ID (ID utente, ID ordine, ID fattura, ID ticket, UUID, GUID)
• Cambia l'ID e osserva la risposta
• Usa due account e testa se l'account A puo accedere ai dati dell'account B
• Controlla sia gli ID numerici sequenziali che gli UUID

4.2 Broken authentication

Broken authentication significa che il sistema ha una debolezza nel modo in cui verifica gli utenti o gestisce le sessioni. Nel test delle API, questo tipicamente coinvolge token, flussi di reset password, comportamento del logout e sistemi OTP.

Problemi comuni da testare:

• Token di refresh che non scadono mai. Un access token puo scadere in 15 minuti, ma se il refresh token non scade mai, un refresh token rubato significa accesso permanente
• Logout solo lato client. L'app rimuove il token dallo storage, ma il server lo accetta ancora. Un logout corretto deve invalidare la sessione lato server
• Token di reset password riutilizzabili. Un token di reset dovrebbe essere casuale, scadere rapidamente e funzionare una sola volta. Se puo essere riutilizzato o indovinato, l'impatto si estende al takeover dell'account
• Nessun rate limiting sugli OTP. Se l'API consente tentativi OTP illimitati senza protezioni di autenticazione a due fattori, un attaccante puo usare il brute force o il credential stuffing per aggirare il codice

4.3 Broken Object Property Level Authorization

Questa categoria copre due problemi correlati: Excessive Data Exposure e Mass Assignment.

Excessive Data Exposure si verifica quando l'API restituisce piu informazioni di quelle necessarie al frontend. Gli sviluppatori a volte inviano oggetti completi dal database al client e si affidano al frontend per mostrare solo i campi sicuri.

Per esempio, una pagina di recensioni puo mostrare solo il nome del recensore e il commento. Ma la risposta API puo contenere anche l'email del recensore, il numero di telefono, l'ID utente interno e il codice del dipartimento. Il sito web nasconde questi campi, ma chiunque intercetti la risposta li vede.

Mass Assignment si verifica quando l'API accetta piu campi dall'utente di quanti dovrebbe. Gli sviluppatori a volte collegano l'intero corpo della richiesta all'oggetto nel database e dimenticano di bloccare i campi sensibili.

Per esempio, una pagina di aggiornamento profilo puo consentire di cambiare solo nome e numero di telefono. Ma se l'API accetta anche role, isAdmin, isVerified o accountBalance, l'utente potrebbe cambiare valori che non dovrebbe mai controllare.

Come testare:

• Per l'esposizione dei dati: ispeziona ogni risposta JSON grezza in Burp Suite. Cerca campi come email, phone, isAdmin, token, role, internalId
• Per il mass assignment: aggiungi campi extra ai corpi delle richieste. Prova "role": "admin", "isVerified": true, "plan": "enterprise" e controlla se l'API li accetta

4.4 Broken Function Level Authorization

Questo si verifica quando un utente puo eseguire un'azione che solo un altro ruolo dovrebbe poter eseguire. A differenza di BOLA (accedere ai dati di un altro utente), qui si tratta di eseguire una funzione che il tuo ruolo non dovrebbe avere.

Un utente normale non dovrebbe poter chiamare endpoint amministrativi che creano utenti, eliminano account, approvano pagamenti o esportano dati aziendali. Questa e di fatto una forma di privilege escalation. Anche se il pulsante admin e nascosto dall'interfaccia, l'endpoint API ha comunque bisogno di controlli dei permessi lato server.

Approccio al test:

• Mappa tutti gli endpoint e comprendi quali azioni appartengono a quale ruolo
• Cattura una richiesta da un account con privilegi superiori e riproducila con un token a privilegi inferiori
• Cerca campi nella richiesta come role, isAdmin, type, privilege, accessLevel
• Il server non dovrebbe mai fidarsi del ruolo inviato dal client

4.5 Unrestricted Resource Consumption

Questo si verifica quando un'API consente agli utenti di consumare risorse eccessive: memoria, CPU, storage, banda o costi di servizi di terze parti.

Per esempio, un'API prodotto normalmente restituisce 20 risultati per pagina con limit=20. Se lo cambi in limit=999999 e il server tenta di restituire tutto, l'API potrebbe rallentare o bloccarsi. Un endpoint di generazione PDF che accetta pageCount=99999 potrebbe consumare tutta la memoria disponibile.

Parametri da testare: limit, pageSize, batchSize, count, quantity, width, height, duration, fileSize, pageCount.

Attenzione: molti programmi di bug bounty non consentono test denial-of-service. Rimani sempre nello scope e testa con cautela.

5. La OWASP API Top 10 spiegata

La OWASP API Security Top 10 e la lista di riferimento del settore per i rischi di sicurezza delle API. L'aggiornamento del 2023 ha riorganizzato diverse categorie:

Per i principianti, concentratevi su queste per prime:

1. API1 - Broken Object Level Authorization
2. API2 - Broken Authentication
3. API3 - Broken Object Property Level Authorization
4. API4 - Unrestricted Resource Consumption
5. API5 - Broken Function Level Authorization

Le restanti cinque categorie meritano attenzione man mano che le tue competenze di API hacking crescono:

• API6 - Unrestricted Access to Sensitive Business Flows: abuso automatizzato della logica di business (scalping di biglietti, creazione massiva di account)
• API7 - Server-Side Request Forgery (SSRF): forzare il server a effettuare richieste verso servizi interni tramite URL forniti dall'utente
• API8 - Security Misconfiguration: policy CORS permissive, errori verbosi, TLS mancante, endpoint di debug esposti
• API9 - Improper Inventory Management: API shadow, vecchie versioni non aggiornate (testa sempre /api/v1/ quando esiste /api/v2/), e documentazione Swagger esposta
• API10 - Unsafe Consumption of Third-Party APIs: fidarsi delle risposte di API esterne senza validazione

I principianti dovrebbero prima diventare forti su API1 fino ad API5. Una volta compresi controllo degli accessi, autenticazione, esposizione dei dati e limiti delle risorse attraverso la pratica diretta, l'intera lista si collega naturalmente ai bug che hai gia testato.

6. Come configurare il tuo primo laboratorio di test API

Non testare mai siti web a caso senza autorizzazione. I test non autorizzati possono violare leggi come il Computer Fraud and Abuse Act (CFAA) negli Stati Uniti, il Computer Misuse Act nel Regno Unito o la legislazione equivalente nella tua giurisdizione. Usa prima laboratori intenzionalmente vulnerabili cosi puoi imparare senza rischi legali. Per una guida completa alla configurazione dell'ambiente, consulta la nostra guida alla configurazione del laboratorio di cybersecurity domestico.

Configurazione passo dopo passo:

1. Installa Burp Suite Community Edition. Configura il proxy del browser, installa il certificato CA di Burp e conferma che puoi catturare il traffico HTTPS. La Web Security Academy di PortSwigger ha una guida gratuita.

2. Distribuisci crAPI (Completely Ridiculous API). Questo progetto OWASP e costruito specificamente per imparare la sicurezza delle API. Include BOLA, autenticazione debole, esposizione eccessiva dei dati e altre vulnerabilita mappate sulla API Top 10. Questo e il miglior punto di partenza.

3. Prova VAmPI. Un'API REST vulnerabile e semplice per praticare i test di autenticazione e autorizzazione.

4. Passa a DVGA. Una volta acquisita familiarita con le API REST, questo laboratorio insegna problemi specifici di GraphQL come l'abuso dell'introspezione, la manipolazione delle query e l'autorizzazione debole nei resolver.

Il metodo di pratica: apri il laboratorio, usalo normalmente e cattura il traffico in Burp Suite. Invia le richieste al Repeater. Cambia gli ID. Rimuovi i token. Cambia i ruoli. Modifica i corpi delle richieste. Aumenta i limiti. Riproduci vecchi token. Leggi ogni risposta.

Prendi appunti mentre pratichi. Scrivi l'endpoint, cosa hai cambiato, cosa ha restituito il server e perche il comportamento e sbagliato. Questa abitudine si traduce direttamente nello scrivere report di bug reali e nel costruire il tuo portfolio di sicurezza.

7. Gli 8 strumenti essenziali per il test di sicurezza delle API

Non hai bisogno di cento strumenti. All'inizio, comprendi a fondo pochi strumenti.

1. Burp Suite - Il tuo strumento principale. Intercetta, modifica, riproduci e confronta le richieste. Il Repeater e fondamentale per testare una richiesta con piccole modifiche.

2. Postman - Costruisci richieste API manualmente e organizzale in collezioni. Utile quando conosci l'endpoint e vuoi un flusso di lavoro strutturato.

3. jwt.io - Decodifica i token JWT per vedere i claim come ID utente, ruolo, tempo di scadenza e issuer. Non compromette nulla, ma ti aiuta a capire quali informazioni trasporta il token.

4. ffuf - Fuzzer web veloce per scoprire percorsi nascosti, endpoint, parametri e valori.

5. Gobuster - Strumento di scoperta di directory e file. Complementa ffuf per una scansione piu ampia.

6. Kiterunner - Scoperta di route API progettata specificamente per i percorsi API. Piu consapevole delle API rispetto ai brute forcer generici per directory.

7. gau / waybackurls - Raccoglie vecchi URL dagli archivi web per trovare endpoint API storici come /api/ o /graphql.

8. Nmap - Scopri porte aperte e servizi. Usalo per trovare servizi API in esecuzione su porte non standard.

Per l'analisi del traffico API a livello di rete, Wireshark e anch'esso utile, specialmente quando si esegue il debug di TLS e problemi a livello di trasporto.

Gli strumenti fanno risparmiare tempo, ma non sostituiscono il ragionamento. La maggior parte dei buoni bug API viene trovata perche il tester comprende la logica, non perche uno strumento ha stampato un risultato.

8. Come trovare gli endpoint API

Prima di trovare bug, devi trovare la superficie API. Questo significa scoprire il maggior numero possibile di endpoint.

Usa l'applicazione. Accedi, aggiorna il tuo profilo, carica un file, cerca qualcosa, cambia le impostazioni, crea un ordine, annullalo, invita un utente, visualizza le notifiche. Ogni azione puo generare una richiesta API.

Esamina i file JavaScript. Le applicazioni web moderne memorizzano i percorsi API all'interno di JavaScript. Cerca parole come api, v1, v2, graphql, auth, token, upload, admin, payment, settings, internal.

Controlla la documentazione API. Swagger UI o file OpenAPI esposti rivelano endpoint, parametri, corpi delle richieste, requisiti di autenticazione e risposte di esempio. Trovare documentazione esposta puo far risparmiare ore.

Scansiona i sottodomini. Le API spesso risiedono su sottodomini come api.example.com, mobile.example.com, dev.example.com o staging.example.com. Le API piu vecchie o di staging hanno frequentemente una sicurezza piu debole.

Cerca negli archivi web. Strumenti come gau e waybackurls rivelano vecchi endpoint che esistono ancora sul server. Le ricerche su GitHub possono rivelare percorsi API, documentazione o chiavi trapelate nei repository pubblici.

L'obiettivo e costruire una mappa completa prima di testare in profondita. Se non conosci gli endpoint, non sai cosa testare.

Ora che hai capito cosa stai cercando, costruiamo la metodologia per trovare il tuo primo bug reale.

9. Dai laboratori di sicurezza API ai programmi di bug bounty reali

Una volta acquisita familiarita con i laboratori, inizia a testare programmi reali. Non avere fretta in questo passaggio.

Prima di testare:

• Leggi lo scope del programma. Assicurati che il test delle API sia consentito
• Verifica quali domini e app sono nello scope
• Controlla se la scansione automatizzata o i test DoS sono limitati
• Comprendi le aspettative del programma riguardo alla responsible disclosure

La tua metodologia iniziale:

1. Cattura il traffico e mappa tutti gli endpoint API
2. Comprendi i ruoli utente e i permessi
3. Testa l'accesso a livello di oggetto (BOLA/IDOR)
4. Ispeziona tutte le risposte API per l'esposizione eccessiva dei dati
5. Testa il comportamento dell'autenticazione (scadenza token, logout, reset password)
6. Verifica se gli utenti normali possono chiamare le funzioni admin
7. Documenta tutto man mano che procedi

Seguire questa checklist di sicurezza API per ogni target costruisce la consistenza. Il tuo primo report valido ti insegnera piu di qualsiasi corso. Il tuo primo rifiuto ti insegnera qualcosa ugualmente. I rifiuti fanno parte del bug bounty: a volte il problema non ha un impatto sufficiente, a volte e gia noto, a volte i tuoi passaggi non sono chiari. Leggi la risposta, migliora il tuo metodo e continua a testare.

10. Risorse per la pratica e prossimi passi

La pratica diretta e la lettura di report reali dovrebbero procedere insieme. I laboratori ti aiutano a capire il bug. I report reali ti aiutano a capire l'impatto e lo stile di segnalazione.

Laboratori e corsi:

• PortSwigger Web Security Academy - Formazione gratuita e completa sulla sicurezza web con moduli specifici sulle API
• crAPI - Il laboratorio di sicurezza API costruito appositamente da OWASP
• VAmPI - API REST vulnerabile per i test di autenticazione
• Kontra - Spiegazioni interattive delle vulnerabilita
• APIsec University - Corsi dedicati alla sicurezza delle API

Libri:

• Hacking APIs di Corey Ball - La guida pratica definitiva al penetration testing delle API
• Black Hat GraphQL di Nick Aleks e Dolev Farhi - Approfondimento sulla sicurezza GraphQL

Leggi i report divulgati. Cerca su HackerOne e Bugcrowd report taggati API, IDOR, BOLA, broken authentication ed excessive data exposure. Leggere qualche report ogni settimana allena il riconoscimento di pattern.

Google dork examples per trovare report pubblici:

• site:hackerone.com/reports/* intext:API
• site:hackerone.com/reports/* intext:IDOR
• site:hackerone.com/reports/* intext:GraphQL

Il tuo percorso di apprendimento:

Se parti da zero, segui questa sequenza: impara HTTP e JSON, poi Burp Suite. Pratica su crAPI. Comprendi BOLA a fondo. Passa a broken authentication, excessive data exposure, function-level authorization e limiti delle risorse. Leggi report reali. Inizia con i programmi di bug bounty. Valida le tue competenze con le certificazioni cybersecurity per principianti per vedere dove il test di sicurezza delle API si colloca nel panorama piu ampio della sicurezza offensiva.

Il tuo primo bug API potrebbe venire dal cambiare un singolo ID, riprodurre un singolo token o notare un campo nascosto in una risposta JSON. Il test di sicurezza delle API non riguarda la memorizzazione di payload. Riguarda la comprensione della fiducia e l'applicazione delle api security best practices a ogni livello. L'API puo fidarsi di questo utente? Puo fidarsi di questo ID? Puo fidarsi di questo valore di ruolo? La maggior parte dei bug API si verifica quando il server si fida di qualcosa che dovrebbe verificare.

Questo e esattamente il motivo per cui il penetration testing delle API e un punto di partenza cosi potente per la tua carriera nella cybersecurity.