API security testing: cosa include e come si fa

Un API security testing è un test offensivo autorizzato sulle interfacce che un'applicazione espone ad app, client e partner. Copre le dieci categorie dell'OWASP API Security Top 10 2023, dall'inventario degli endpoint anche non documentati all'autorizzazione su oggetti, proprietà e funzioni, e si svolge in cinque passi: perimetro, account di test per ruolo, ricognizione, test e sfruttamento, report e retest.

Questa guida è per chi deve commissionarlo: perché le API non si coprono con un test web generico, come si svolge il lavoro, cosa preparare e quali domande fare al fornitore prima di firmare. Per il quadro generale dell'attività c'è la guida al penetration test.

Perché le API meritano un test dedicato

L'interfaccia che vedi nel browser è solo uno dei client. Dietro, dati e logica passano per chiamate HTTP che chiunque abbia un token valido può invocare direttamente, senza passare dalle schermate. Il web application penetration test include le API nel perimetro; un API security testing le mette al centro, ed è la scelta giusta quando le API sono il prodotto o l'integrazione principale.

Il NIST, nella SP 800-228 (Guidelines for API Protection for Cloud-Native Systems, pubblicata nel giugno 2025 e aggiornata il 13 marzo 2026 con due appendici), apre il capitolo sui rischi dalla visibilità. Secondo il documento, la maggior parte delle organizzazioni ha lacune nell'inventario delle API anche quando gestisce bene il resto degli asset. Le cause che elenca:

• API costruite da team diversi, distribuite fra cloud e on-premise, o ereditate con fusioni e acquisizioni;
• shadow API, nate per debug, test o esigenze estemporanee e mai documentate, che spesso saltano la revisione di sicurezza;
• zombie API, sostituite da sistemi nuovi ma ancora accese, perché qualche client non è migrato o perché il team che le gestiva non esiste più.

Il secondo tema è l'autorizzazione. Lo stesso documento osserva che tre dei dieci rischi del catalogo OWASP, il primo, il terzo e il quinto, riguardano l'autorizzazione. Sono difetti in cui la richiesta è formalmente valida: è il controllo su chi può chiedere cosa che manca o guarda la cosa sbagliata.

Cosa include un API security testing

L'OWASP API Security Top 10 2023 è la seconda edizione della lista, quattro anni dopo la prima. Le note di rilascio la presentano come documento di consapevolezza costruito sull'esperienza del team e sulla revisione della comunità, perché alla raccolta pubblica di dati non ha contribuito nessuno. Non è una metodologia, ma è il perimetro minimo che un test serio deve coprire. Ecco le dieci categorie, raggruppate per tipo di verifica.

Inventario e ricognizione

API9:2023, Improper Inventory Management: versioni deprecate ancora raggiungibili, endpoint di debug esposti, host non censiti. La OWASP Web Security Testing Guide, nella versione 5.0 in sviluppo, dedica alla ricognizione delle API uno scenario apposito (WSTG-APIT-01): l'obiettivo è trovare tutti gli endpoint e i parametri che il backend accetta, documentati o no, anche cercando versioni vecchie della documentazione e percorsi noti come /swagger.json o /openapi.json. La versione stabile della guida, la 4.2, per le API prevede solo il test di GraphQL.

Autenticazione

API2:2023, Broken Authentication: token che un attaccante riesce a compromettere e difetti di implementazione che gli permettono di assumere l'identità di un altro utente, per un momento o in modo permanente. Nello stesso capitolo rientra il modo in cui chiavi e token vengono custoditi: una chiave API dimenticata in un repository vale quanto una credenziale rubata, ed è il tema della guida alla gestione dei segreti nel codice e nel cloud.

Autorizzazione, su tre livelli

• Oggetto (API1:2023, Broken Object Level Authorization). L'utente A chiede /api/orders/1002, che appartiene all'utente B, e lo riceve. La WSTG (scenario WSTG-APIT-02) indica di provarlo con due account distinti: con il primo si creano le risorse, con il secondo si tenta di leggerle, modificarle e cancellarle con i diversi metodi HTTP.
• Proprietà (API3:2023, Broken Object Property Level Authorization). L'oggetto è quello giusto, ma la risposta contiene campi che quell'utente non dovrebbe vedere, oppure l'API accetta in scrittura campi che non dovrebbe accettare. La categoria unisce due voci dell'edizione 2019, Excessive Data Exposure e Mass Assignment.
• Funzione (API5:2023, Broken Function Level Authorization). Un utente ordinario invoca una funzione amministrativa, perché ruoli e gruppi sono complessi e la separazione fra funzioni ordinarie e di amministrazione non è chiara.

La SP 800-228 aggiunge una griglia utile anche per leggere il report: l'autorizzazione può essere assente, sbagliata (controlla l'identità, il permesso o la risorsa sbagliati) oppure insufficiente (il controllo sulla risorsa passa, ma la risorsa contiene informazioni privilegiate non previste per quel livello di accesso).

Consumo di risorse e flussi di business

API4:2023, Unrestricted Resource Consumption: ogni richiesta consuma banda, CPU, memoria e a volte servizi pagati a richiesta, come SMS, email o verifiche biometriche. Senza limiti l'esito è un disservizio o un aumento dei costi operativi. API6:2023, Unrestricted Access to Sensitive Business Flows: flussi come l'acquisto di un biglietto o la pubblicazione di un commento, che fanno danno se ripetuti in grandi volumi da uno script. OWASP nota che questo rischio non nasce necessariamente da un errore di implementazione. Nessuno scanner lo segnala: serve qualcuno che abbia capito il processo.

Richieste lato server, configurazione, API di terzi

• API7:2023, Server Side Request Forgery: l'API scarica una risorsa remota da un indirizzo fornito dall'utente senza validarlo, e può essere spinta a raggiungere destinazioni interne, anche dietro un firewall o una VPN.
• API8:2023, Security Misconfiguration: le configurazioni dell'API e dei sistemi che la sostengono sono complesse, e una impostazione lasciata al valore sbagliato apre la strada a diversi tipi di attacco.
• API10:2023, Unsafe Consumption of APIs: i dati ricevuti da API di terzi vengono trattati con più fiducia dell'input degli utenti, e un attaccante può colpire il servizio integrato invece dell'API che gli interessa.

Come si svolge, passo per passo

1. Perimetro e artefatti. Quali API, quali versioni, quali ambienti, quali ruoli. La WSTG suggerisce di chiedere al cliente il prima possibile gli artefatti che gli strumenti sanno importare: definizioni OpenAPI o Swagger 2.0, collezioni di richieste aggiornate (per esempio Postman o Bruno), schemi GraphQL quando l'introspection è disabilitata, file WSDL o WADL per le API più vecchie.
2. Account di test. Almeno due utenti per ciascun ruolo, per verificare l'accesso orizzontale (un cliente sui dati di un altro cliente) e quello verticale (un utente sulle funzioni di un amministratore).
3. Ricognizione. Si confronta la documentazione con ciò che il backend risponde davvero. La WSTG avverte che anche una specifica scritta in buona fede può essere inesatta o incompleta.
4. Test e sfruttamento. Gli strumenti coprono l'ampiezza (la WSTG cita proxy di intercettazione come Burp Suite e ZAP), il lavoro manuale copre autorizzazioni e logica di business. Un finding è confermato quando la richiesta che lo dimostra è riproducibile.
5. Report e retest. Per ogni finding la richiesta, la risposta, l'impatto e la correzione proposta; poi la verifica che le correzioni tengano. Come si legge il documento finale è spiegato nella guida al penetration test report.

Staging o produzione

Le categorie API4 e API6 si verificano generando volume, e in produzione quel volume lo subisce chi usa il servizio. Va deciso prima: un ambiente di staging fedele, finestre concordate, soglie oltre le quali il tester si ferma.

Cosa chiedere al fornitore prima di firmare

• Copertura per iscritto. Quali categorie dell'OWASP API Security Top 10 2023 e quali scenari WSTG saranno verificati, e quali restano fuori.
• API non documentate. Se il test parte solo dalla specifica che consegni tu, shadow e zombie API restano fuori per costruzione. Chiedi come le cercano.
• Account per ruolo. Se te ne chiedono uno solo, l'autorizzazione a livello di oggetto non viene verificata davvero.
• Tecnologie coperte. REST, GraphQL, API interne fra servizi: cosa rientra e con quale metodo.
• Integrazioni di terzi. Dentro o fuori perimetro, e con quale autorizzazione del fornitore terzo.
• WAF attivo o escluso. Con il filtro attivo il test misura anche il filtro, con un'eccezione concordata misura l'API. Si decide nello scoping.
• Retest. Incluso o no, con quale finestra, sugli stessi identificativi dei finding.
• Token e chiavi. Come conservano le credenziali di test che ricevono e quando le revochi a fine attività.

Le stesse voci pesano sull'impegno: gli altri fattori sono nella guida a quanto costa un penetration test.

Test puntuale e controlli continui

Un test fotografa le API in un momento, e le API cambiano a ogni rilascio. La SP 800-228 colloca il test fra le fasi del ciclo di vita che precedono l'esercizio (pianificazione, sviluppo, build, test, rilascio) e gli affianca controlli che durano nel tempo:

• un inventario di tutte le API, interne ed esterne, comprese shadow e zombie, con la specifica di ciascuna, il responsabile e i dati di esercizio (REC-API-4.2);
• strumenti di discovery per tenerlo aggiornato (REC-API-4.3);
• uno strumento di audit delle autorizzazioni che cerchi con regolarità controlli mancanti o deboli, insieme a test unitari e di integrazione che verifichino che i permessi dei ruoli siano coerenti con la sensibilità dei dati (REC-API-12.3).

Sul WAF lo stesso documento è chiaro: confronta le richieste con firme di attacchi noti, e per questo è largamente inefficace contro attacchi nuovi. Aggiungiamo un'osservazione nostra: una richiesta che sfrutta un difetto di autorizzazione a livello di oggetto è ben formata e non ha una firma, è una lettura regolare del dato sbagliato. Il WAF resta utile; il test resta necessario.

Cosa dicono NIS2, DORA e ISO 27001

Nessuna di queste fonti nomina le API. Ci arrivano per sostanza, ed è una lettura nostra che le API esposte rientrino fra i sistemi da testare quando trattano dati o servizi rilevanti.

• NIS2. Il D.Lgs. 138/2024, all'art. 24, comma 2, include fra le misure minime la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, comprese la gestione e la divulgazione delle vulnerabilità (lettera e), e le politiche per valutare l'efficacia delle misure (lettera f). Per i soggetti essenziali l'allegato 2 della determinazione ACN 379907/2025, misura ID.RA-01, chiede attività periodiche, e comunque precedenti la messa in esercizio, che comprendano almeno vulnerability assessment e/o penetration test sui sistemi rilevanti, documentate con apposite relazioni.
• DORA. Il Regolamento (UE) 2022/2554, all'art. 25, par. 1, elenca fra i test del programma di resilienza operativa digitale gli esami del codice sorgente, ove fattibile, e i test di penetrazione. L'art. 24 chiede alle entità finanziarie diverse dalle microimprese che i test siano svolti da soggetti indipendenti, interni o esterni (par. 4), e che esistano procedure per dare priorità ai problemi emersi, classificarli e porvi rimedio, con metodologie di convalida interne (par. 5).
• ISO/IEC 27001:2022. L'Allegato A prevede la gestione delle vulnerabilità tecniche (controllo 8.8) e i test di sicurezza in fase di sviluppo e accettazione (controllo 8.29).

Da dove partire

Il primo passo non è il test, è l'elenco: quali API esponi, a chi, con quali ruoli, e chi ne risponde. Con quell'elenco il perimetro si scrive in un'ora e il test parte dalle API che trattano più dati. Se vuoi impostarlo con noi, dal perimetro al retest, trovi come lavoriamo nella pagina dedicata ai servizi di cybersecurity.