La maggior parte dei team tratta la sicurezza delle API come un problema di autenticazione. Aggiungono token, li verificano su ogni rotta e considerano il lavoro concluso. Poi un tester cambia un numero nell’URL e legge la fattura di un altro cliente.

Quel divario fra “autenticato” e “autorizzato” è dove vive la maggioranza delle violazioni reali delle API, e non è qualcosa che uno scanner trova in modo affidabile. Uno strumento automatico vede un token valido e una risposta 200 e segnala successo. Solo una persona che capisce le tue regole di business si accorge che la risposta conteneva i dati di qualcun altro.

La distinzione fondamentale: l’autenticazione dimostra chi sta chiamando. L’autorizzazione decide che cosa quello specifico chiamante può vedere o modificare, e va applicata su ogni oggetto, a ogni richiesta, nel livello dei dati. Quasi ogni vulnerabilità seria di un’API è un fallimento della seconda mentre la prima funziona perfettamente.

Autorizzazione sugli oggetti mancante, e perché domina

La falla grave più comune nelle API è anche la più semplice da descrivere.

Il tuo endpoint è /api/invoices/48213. Il chiamante è autenticato, quindi l’handler recupera la fattura 48213 e la restituisce. Nessuno verifica che la fattura 48213 appartenga a quel chiamante. Cambi il numero, ottieni la fattura di un altro. L’API si è comportata esattamente come era scritta; era la scrittura a essere sbagliata.

Questo scala male per te e benissimo per un attaccante. Gli identificatori sequenziali permettono di enumerare l’intero archivio con un semplice ciclo. Passare a identificatori non indovinabili aiuta un poco, ma non è una correzione, perché gli identificatori trapelano comunque attraverso altri endpoint, attraverso le esportazioni e attraverso le e-mail.

La correzione è strutturale, non incidentale. La proprietà va verificata nella query stessa: recupera la fattura che appartiene a questo cliente e ha questo identificatore, invece di recuperare la fattura sperando che più avanti qualcosa controlli. Metti quel controllo nel livello di accesso ai dati, così non potrà essere dimenticato in un nuovo controller scritto fra sei mesi da qualcuno che non ha mai letto questo paragrafo.

Lo stesso fallimento vale per le funzioni, non solo per gli oggetti. Se un endpoint amministrativo è protetto soltanto dal fatto che l’interfaccia non lo collega per gli utenti normali, non è protetto affatto.

Le falle di sicurezza delle API che emergono davvero

Oltre all’autorizzazione, una manciata di problemi spiega la maggior parte dei rilievi. La OWASP API Security Top 10 è il riferimento standard in materia, e OWASP la rivede periodicamente: consulta l’edizione corrente anziché un riassunto.

Restituire più di quanto l’interfaccia mostri. Un endpoint restituisce l’oggetto utente completo perché era comodo, e il front end ne mostra tre campi. Gli altri dodici, compresi il token di reimpostazione della password e il punteggio di rischio interno, restano nella risposta. Chiunque apra la scheda di rete se li porta via. Serializza deliberatamente: costruisci la risposta a partire da campi nominati invece di riversare un modello intero.

Mass assignment in ingresso. L’immagine speculare. Un endpoint di aggiornamento del profilo accetta qualunque campo arrivi e lo scrive sul record, così un chiamante aggiunge "role": "admin" e si promuove da solo. Vincola esplicitamente a un elenco di campi consentiti invece di accettare in blocco il corpo della richiesta.

Consumo senza limiti. Senza limiti, un solo chiamante può chiedere un milione di record per pagina, lanciare ricerche costose in un ciclo o innescare reimpostazioni di password a migliaia. Non è solo una questione di negazione del servizio; dove ogni richiesta ti costa denaro, come con un modello linguistico dietro il tuo endpoint, è un attacco alla fattura. I limiti di frequenza vanno posti per consumatore e per endpoint, con le operazioni costose limitate più strettamente di quelle economiche.

Inventario e fiducia verso i terzi

Endpoint dimenticati e non documentati. La versione due è in produzione e documentata, la versione uno gira ancora con la vecchia logica di autorizzazione, e un’API di staging con dati di produzione è raggiungibile da Internet. Gli attaccanti cercano esattamente questo. Tieni un inventario di ogni API distribuita, di ogni versione e di ogni ambiente, e dismetti in modo deliberato anziché per abbandono.

Fidarsi dei sistemi che chiami. La tua API consuma altre API, e le loro risposte finiscono nel tuo database e nel tuo rendering. Valida ciò che torna indietro invece di dare per sicuro un partner. Una risposta che arriva dall’esterno è pur sempre input, con tutti i controlli che questo comporta. La nostra guida all’integrazione di API di terze parti affronta il lato affidabilità della stessa relazione.

Impostare bene l’autenticazione

L’autenticazione è la parte che la maggior parte dei team fa più o meno bene, quindi qui contano i dettagli che la vanificano.

Usa token di accesso a vita breve con refresh, non chiavi longeve che non scadono mai. Una credenziale trapelata che funziona per sempre è una violazione permanente; una che scade in quindici minuti è un incidente con una fine definita.

Restringi l’ambito dei token. Un token emesso per un’integrazione di reportistica non dovrebbe poter creare utenti. Gli scope ti permettono di imporlo centralmente invece di affidarti al controllo di ogni singolo handler.

Valida i token correttamente, il che significa soprattutto non accettare l’algoritmo che il token stesso dichiara. Fissa l’algoritmo di firma atteso, verifica emittente e destinatario e controlla la scadenza. Esistono librerie che lo fanno per impostazione predefinita; è nella verifica fatta in casa che vivono gli errori.

Ruota le credenziali secondo un calendario e offri ai consumatori un modo per cambiare senza interruzioni, di solito accettando due chiavi valide durante il passaggio. Se la rotazione causa un disservizio, nessuno la farà.

Infine, non mettere mai credenziali nelle URL. Le query string finiscono nei log del server, nella cronologia del browser, nei log dei proxy e nelle intestazioni referrer. Usa le intestazioni.

Che cosa trova davvero un penetration test

La scansione automatica e il test manuale trovano cose diverse, e ti servono entrambi per ragioni diverse.

Gli scanner sono bravi con le dipendenze vulnerabili note, le intestazioni di sicurezza mancanti, la configurazione TLS errata e le injection evidenti. Falli girare di continuo nella tua pipeline, perché costano poco e intercettano le regressioni. La nostra checklist per l’audit di sicurezza del server mostra che cosa viene controllato sul lato infrastruttura.

Quello che non sanno fare è ragionare sul tuo business. Un tester scopre che un endpoint per i codici sconto può essere chiamato più volte per cumulare gli sconti, che una funzionalità a pagamento resta raggiungibile da un piano gratuito chiamando direttamente l’API, o che annullare un ordine già spedito attiva un rimborso senza controllo di magazzino. Sono questi i rilievi che costano denaro vero, e affiorano solo quando qualcuno capisce a che cosa serve la tua API.

Per un’API in particolare, chiedi che il test includa la verifica dell’autorizzazione fra ruoli: il tester tiene le credenziali di due clienti diversi e prova sistematicamente a raggiungere i dati di un account con il token dell’altro. Quel singolo esercizio trova più di tutto il resto messo insieme. La nostra panoramica sui tipi di penetration test spiega quanto accesso conviene dare a un tester, e fornire documentazione e credenziali produce risultati molto migliori di un test alla cieca.

Sul fronte del budget, un test focalizzato su un’API va tipicamente da circa £3,000 per un’API piccola e ben documentata fino a £15,000 o più per una superficie ampia con diversi ruoli e integrazioni. La nostra guida ai costi del penetration test scompone che cosa determina quella forbice.

Registrare abbastanza da poter indagare

La differenza fra un incidente e una catastrofe di solito sta nel poter ricostruire che cosa è successo.

Registra gli eventi di autenticazione, i rifiuti di autorizzazione e ogni operazione che cambia stato, ciascuno con l’identità del chiamante, l’oggetto interessato e un identificatore di correlazione. I rifiuti di autorizzazione in particolare sono il tuo preavviso: un’integrazione legittima non ne produce quasi nessuno, quindi una raffica significa che qualcuno sta sondando.

Non registrare i valori sensibili in sé. Token, dati di carta e dati personali nei file di log trasformano una violazione contenuta in una da notificare.

Allerta sugli schemi anziché sul volume. Un singolo chiamante che genera errori di autorizzazione su molti identificatori di oggetti è un’enumerazione in corso, e per quella vale la pena svegliare qualcuno. Il tasso di errore complessivo no.

Conserva abbastanza a lungo da essere utile. Le compromissioni vengono spesso scoperte settimane dopo il loro inizio, e trenta giorni di log sono spesso troppo pochi per trovare il punto di ingresso.

Testa l’API che hai davvero messo in produzione

Mecanik offre test di sicurezza applicativa concentrati sulle falle di autorizzazione e di logica di business che gli strumenti automatici non vedono, inclusi i test fra account con credenziali reali su più ruoli.

Lavoriamo partendo dalla tua specifica e dalla tua documentazione invece di indovinare la superficie esposta, il che porta alla luce come effetto collaterale gli endpoint non documentati e le vecchie versioni rimaste in giro. Dove il lavoro si estende a infrastruttura e rete, i nostri servizi di penetration test coprono quel terreno. E se la tua API sta dietro un’applicazione web, la nostra guida all’audit di sicurezza del sito mostra come le due verifiche si incastrano. E se stai ancora progettando l’API, la nostra guida al costo di sviluppo di un’API indica dove collocare autorizzazione, rate limiting e logging già in fase di costruzione, invece di aggiungerli dopo.

Mandaci la specifica e una descrizione dei tuoi ruoli, e ti diremo dove si concentra il rischio.

Post correlati: Sito WordPress hackerato: rimuovere il malware , Conformità tecnica GDPR per sviluppatori UK nel 2026 , Cloudflare Zero Trust: guida alla sicurezza degli accessi aziendali , Penetration Testing UK - Cosa aspettarsi nel 2026 .

Domande frequenti

Qual è la vulnerabilità di sicurezza più comune nelle API? L’autorizzazione sugli oggetti mancante, dove un chiamante autenticato raggiunge i dati di un altro utente cambiando un identificatore nella richiesta. L’autenticazione funziona correttamente, ma nulla verifica che l’oggetto richiesto appartenga al chiamante. La proprietà va quindi imposta nella query stessa.

Le chiavi API bastano a proteggere un’API? Da sole no. Le chiavi longeve che non scadono mai trasformano qualsiasi fuga in una violazione permanente. Usa token di accesso a vita breve con refresh, limitane l’ambito a ciò che il consumatore usa davvero, permetti la rotazione senza interruzioni e inviali sempre nelle intestazioni anziché nelle URL.

La scansione automatica può mettere in sicurezza un’API? No, anche se vale la pena eseguirla di continuo. Gli scanner trovano dipendenze vulnerabili note, intestazioni mancanti e injection evidenti. Non sanno ragionare sulle tue regole di business, quindi si perdono gli sconti cumulati, le funzionalità a pagamento raggiungibili dal piano gratuito e gli accessi fra account diversi.

Quanto costa un penetration test su un’API? Tipicamente da circa £3,000 per un’API piccola e ben documentata fino a £15,000 o più per una superficie ampia con più ruoli e integrazioni. Il costo dipende dal numero di endpoint, dal numero di ruoli distinti e dal fatto che vengano forniti documentazione e credenziali.

Che cosa dovrebbe registrare un’API a fini di sicurezza? Gli eventi di autenticazione, i rifiuti di autorizzazione e ogni operazione che cambia stato, ciascuno con identità del chiamante, oggetto interessato e identificatore di correlazione. Non registrare mai token o dati personali. Allerta quando un singolo chiamante produce errori di autorizzazione su molti identificatori, perché indica un’enumerazione.