API Security Testing: Guida completa 2026

Perché il test delle API richiede un approccio diverso

Un'API non ha un'interfaccia che limiti le azioni possibili: ogni endpoint accetta parametri arbitrari, quindi il perimetro di test è deciso da chi lo esegue e non dall'interfaccia. Tre verifiche fanno la differenza nella pratica: l'accesso a oggetti altrui (cambiare un identificatore e ottenere dati di un altro utente), l'autorizzazione per funzione (un utente standard che raggiunge endpoint amministrativi) e l'assegnazione di massa (campi come role, isAdmin o balance accettati nel corpo della richiesta e scritti nel database).

Contano anche gli aspetti spesso trascurati: le versioni precedenti degli endpoint (/v1 ancora attive dopo il rilascio della /v2), gli ambienti di staging raggiungibili da Internet e le chiavi API con permessi più ampi del necessario.

Categorie OWASP API Security Top 10 (2023) da coprire

• API1:2023 Broken Object Level Authorization — accesso a oggetti di altri utenti tramite ID.
• API2:2023 Broken Authentication — token deboli, sessioni non invalidate, reset password prevedibili.
• API3:2023 Broken Object Property Level Authorization — campi sensibili esposti o modificabili.
• API4:2023 Unrestricted Resource Consumption — assenza di limiti su paginazione, upload e richieste concorrenti.
• API5:2023 Broken Function Level Authorization — endpoint amministrativi raggiungibili senza privilegi.
• API6:2023 Unrestricted Access to Sensitive Business Flows — abuso di flussi legittimi (acquisto, prenotazione, invio messaggi).
• API7:2023 Server Side Request Forgery — URL forniti dall'utente usati dal server per richieste interne.
• API8:2023 Security Misconfiguration — CORS permissivo, errori verbosi, header di sicurezza assenti.
• API9:2023 Improper Inventory Management — documentazione e versioni non allineate a ciò che è realmente esposto.
• API10:2023 Unsafe Consumption of APIs — fiducia cieca nelle API di terze parti integrate.

Come si struttura un test difensivo

Il test parte da un perimetro scritto: elenco degli endpoint, ambienti coinvolti, orari concordati, dati di test e limite di richieste al secondo. Si lavora su copie o su dati sintetici, mai su dati reali di clienti, e ogni prova viene registrata con richiesta, risposta e orario per poter ricostruire l'attività. Il rapporto finale elenca i problemi per severità (in genere con punteggio CVSS), indica i passi di riproduzione e propone una correzione verificabile; il retest dopo le patch conferma che il rischio è stato effettivamente ridotto.

Riferimenti normativi utili in Italia

Per chi tratta dati personali, il GDPR richiede misure tecniche e organizzative adeguate (art. 32) e la notifica delle violazioni al Garante entro 72 ore (art. 33): un test documentato aiuta a dimostrare la diligenza. Nei settori coperti dalla direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, la gestione dei rischi informatici e la verifica periodica diventano obblighi di governance. Chi gestisce pagamenti rientra nello scope PCI DSS, che richiede test periodici delle applicazioni che trattano dati di carta.

Checklist minima prima del rilascio

• Autenticazione obbligatoria su ogni endpoint, con token a scadenza breve e revoca possibile.
• Controllo di autorizzazione sull'oggetto e sulla funzione, testato con un utente di privilegio inferiore.
• Validazione dello schema di input e whitelist dei campi scrivibili.
• Rate limiting e quota per utente e per chiave API.
• Messaggi di errore senza dettagli interni e log applicativi con correlazione degli eventi.
• Gestione delle versioni: gli endpoint obsoleti vengono dismessi, non solo nascosti.

Un test di penetrazione autorizzato su queste basi produce risultati riutilizzabili, mentre una scansione automatica senza contesto lascia scoperti proprio i difetti di autorizzazione, che restano i più frequenti e i più costosi.