API Security Testing: la metodologia che uso in ogni engagement

Le API rappresentano la superficie di attacco in maggiore crescita nel panorama della sicurezza. Ogni applicazione moderna espone API - e la maggior parte ha vulnerabilita. Nella mia esperienza di pentesting, le API sono dove trovo i bug piu critici: IDOR (Insecure Direct Object Reference) che espongono dati di altri utenti, BOLA (Broken Object Level Authorization) che permette di accedere a risorse non autorizzate, e autenticazione rotta che bypassa completamente i controlli di accesso. La mia metodologia di API security testing si e evoluta attraverso decine di engagement.

Fase 1: Discovery e mapping

Prima di testare, devo capire cosa c'e. Colleziono la documentazione API (Swagger/OpenAPI se disponibile), analizzo il traffico dell'applicazione con Burp Suite per scoprire endpoint non documentati, e faccio fuzzing sui path per trovare versioni legacy delle API (v1 spesso ha meno controlli di v2). Un trucco che funziona sorprendentemente spesso: le API di staging o debug lasciate esposte in produzione. Le trovo in almeno il 20% degli engagement.

Fase 2: Autenticazione e autorizzazione

Qui e dove trovo la maggior parte delle vulnerabilita critiche. Testo: come vengono gestiti i token (JWT con secret deboli? Token che non scadono?), se l'autorizzazione e enforced a livello di oggetto (posso accedere ai dati dell'utente B con il token dell'utente A?), privilege escalation (un utente base puo accedere a endpoint admin?), e rate limiting (posso fare brute force sui token o sulle credenziali?).

Fase 3: Input validation e business logic. Testo injection (SQL, NoSQL, command injection attraverso parametri API), mass assignment (posso modificare campi che non dovrei? tipo is_admin=true), e flaw nella business logic (posso applicare un codice sconto infinite volte? Posso modificare il prezzo di un ordine?). La business logic e la parte che gli scanner automatici non trovano - richiede comprensione umana dell'applicazione.

Per ogni vulnerabilita trovata, il report include: descrizione tecnica, proof-of-concept riproducibile, impatto reale (non teorico), e raccomandazione specifica di remediation. Un buon report di API security testing non e una lista di CVE - e una narrativa che mostra il rischio reale per il business.