Sicurezza API: i passaggi essenziali per non lasciare la porta aperta

Quando pensiamo alla sicurezza del sistema, guardiamo lo schermo: la password complessa, il blocco del browser, il login a due fattori. Ma l'aggressore non guarda lo schermo. Esamina l'API, il livello di servizio dei dati dietro l'interfaccia, dove semplicemente non esistono protezioni visibili.

Questa è la pericolosa asimmetria delle applicazioni moderne. L'interfaccia è stata creata per gli esseri umani e nasconde la complessità. L'API è stata creata per le macchine ed espone tutto direttamente. Un utente malintenzionato ignora i pulsanti e comunica direttamente con l'API, dove le regole di buona educazione dell'interfaccia non si applicano.

Non è esagerato affermare che le API sono diventate il principale vettore di attacco ai sistemi digitali. OWASP stessa mantiene un elenco specifico dei principali rischi per la sicurezza delle API, separato dall'elenco generale delle applicazioni web, proprio perché i problemi hanno una loro natura. Questo articolo è una tabella di marcia dei passaggi essenziali per proteggere un'API, per i team che dispongono già di API in produzione e devono garantire che non siano una backdoor.

Perché l'API è il collegamento più mirato

L'interfaccia filtra ciò che vedi. L'API, se mal progettata, offre molto di più di quanto mostrato sullo schermo. È normale che un'API restituisca un intero oggetto utente, inclusi i campi che l'interfaccia non visualizza mai, perché era più semplice inviare tutto e lasciare che il front-end scegliesse cosa mostrare. L'aggressore, che esamina la risposta grezza, vi trova dati che nessuno dovrebbe vedere.

Aggiungi a quell'automazione. Un utente malintenzionato non testa una richiesta alla volta come un essere umano. Esegue la scansione di migliaia di combinazioni al secondo, esaminando identificatori, parametri ed endpoint. Un difetto che sarebbe difficile da sfruttare manualmente diventa banale su scala automatizzata.

La tesi: proteggere l'interfaccia senza proteggere l'API significa chiudere la porta principale e lasciare spalancata la porta posteriore. La vera sicurezza risiede nel livello che serve i dati, non in quello che li presenta.

Passaggio 1: autenticazione forte su ogni richiesta

Ogni chiamata API deve dimostrare chi la sta effettuando. Non è sufficiente proteggere l'accesso e fidarsi del resto. Ogni richiesta a una risorsa protetta deve contenere una credenziale valida, in genere un token, che il server verifica.

La cura essenziale riguarda la gestione di questi token. Devono avere una validità limitata, in modo che un token rubato non possa essere utilizzato per sempre. Devono poter essere revocati. E non dovrebbero mai essere trasportati o immagazzinati in modo non sicuro. I token di lunga durata e mai revocati invitano al disastro: basta una fuga di notizie.

L'errore comune qui è trattare autenticazione come qualcosa che viene risolto una volta. In effetti, si tratta di una disciplina continua di emissione, convalida, scadenza e revoca delle credenziali.

Passo 2: autorizzazione verificata ad ogni accesso

Questo è il passaggio più importante e più trascurato. L'autenticazione risponde "chi sei?". L'autorizzazione risponde "puoi accedere a questo?". Sono domande diverse e le perdite API più gravi derivano dal rispondere alla prima e dimenticare la seconda.

Il modello di errore ha un nome nell'elenco OWASP: autorizzazione a livello di oggetto interrotta. Il sistema conferma che hai effettuato l'accesso, ma non verifica che quei dati specifici siano tuoi. Il risultato è il classico attacco di modifica del numero nell'URL: interroghi /pedidos/123, lo cambi in /pedidos/124 e vedi la richiesta di qualcun altro.

La regola non negoziabile: per ogni accesso a una risorsa, il server deve verificare se quello specifico utente ha diritto a quella specifica risorsa. Questo controllo non può essere localizzato sul client controllato dall'aggressore. Deve essere sul server, in ogni richiesta, senza eccezioni.

Passaggio 3: convalida e limita tutto ciò che entra

L'API non può fidarsi di nulla che provenga dall'esterno. Tutti gli input, i parametri, il corpo della richiesta e le intestazioni devono essere convalidati per formato, tipo e dimensione prima di essere utilizzati. La fiducia nell'input è la radice degli attacchi injection, in cui i dati dannosi vengono interpretati come comandi.

La validazione rigorosa sul server è la difesa. La convalida lato client è una comodità per l'utente, non una sicurezza, perché l'aggressore semplicemente bypassa il client e comunica direttamente con l'API.

Vale anche la pena limitare ciò che può essere inviato. Le API che accettano grandi payload o query che restituiscono enormi volumi di dati sono vettori sia di sovraccarico che di estrazione di massa di informazioni.

Passaggio 4: limita il tasso di richieste

Senza limitazione della velocità, un'API è esposta ad abusi di forza bruta e ad una massiccia esfiltrazione di dati. Un utente malintenzionato può provare migliaia di password al minuto o scorrere tutti i possibili identificatori per scaricare l'intero database, semplicemente effettuando numerose richieste rapide.

La limitazione della velocità, limitazione della velocità, limita il numero di richieste che un cliente può effettuare in un dato momento. Si tratta di una difesa semplice e potente contro l'automazione dannosa, gli attacchi denial-of-service e lo scraping dei dati. La sua assenza trasforma ogni altro difetto in qualcosa di sfruttabile su scala industriale.

Step 5: esponi il minimo e registra tutto

Due pratiche chiudono l’insieme essenziale. Il primo è salvare l'esposizione: l'API dovrebbe restituire solo i dati necessari all'operazione, mai l'oggetto completo “per comodità”. Ogni campo aggiuntivo esposto rappresenta un numero maggiore di dati che possono essere divulgati. Inoltre, i messaggi di errore non dovrebbero rivelare dettagli interni che aiutino l'aggressore a mappare il sistema.

Il secondo è la registrazione e il monitoraggio. Senza i registri di ciò che accade nell'API, un attacco può andare avanti per settimane senza essere notato. La registrazione degli accessi, degli errori di autenticazione e dei modelli anomali consente di rilevare e rispondere. Nei sistemi soggetti a LGPD, essere in grado di sapere cosa è successo ai dati e quando non è solo una buona pratica di sicurezza, ma fa parte della responsabilità legale essere responsabili.

Riflessione critica: la sicurezza delle API è un lavoro in corso

L'errore più comune è considerare la sicurezza delle API come un controllo una tantum al momento del lancio. Le API si evolvono, ottengono nuovi endpoint, si integrano con nuovi sistemi. Ogni cambiamento è un’opportunità per introdurre un difetto. La superficie di attacco cresce con ogni rilascio e la sorveglianza deve crescere con esso.

C’è anche il problema delle API dimenticate. Vecchie versioni ancora attive, endpoint di test esposti, integrazioni che nessuno mantiene più. Queste API fantasma sono tra i vettori più sfruttati perché non sono sul radar di nessuno. Mantenere un inventario di ciò che viene esposto è una parte essenziale della difesa.

La visione strategica per chi guida: l'API è il luogo in cui vive realmente il tuo sistema. Investire nella sicurezza dell'interfaccia mentre l'API rimane non protetta significa investire nell'apparenza della sicurezza, non nella sicurezza. Gli incidenti moderni arrivano dove viaggiano effettivamente i dati, e questa è l'API.

Proteggere un'API non richiede genialità. Richiede l’applicazione coerente dei principi fondamentali: autenticare ogni richiesta, autorizzare ogni accesso, convalidare ogni input, limitare la velocità, esporre il minimo e registrare tutto. Coloro che lo fanno in modo disciplinato chiudono la porta attraverso la quale entrerebbero la maggior parte degli attacchi.

Se la tua organizzazione ha API in produzione e non ha mai effettuato un serio controllo della sicurezza su di esse, questo è un punto cieco che vale la pena affrontare in via prioritaria. Sono disponibili altri articoli di blog su autenticazione, OWASP e architettura sicura che approfondiscono ogni passaggio. Se la sicurezza delle API è una vera preoccupazione nel tuo contesto, vale la pena parlarne.