Risks di Autenticazione API: 40% degli Endpoint con Vulnerabilità Multiple

Imperva API Security: Rapporto 2026 sui Rischi di Token e Autenticazione

Ogni anno, l'industria della sicurezza pubblica report di benchmark costruiti più o meno nello stesso modo: si selezionano alcune vulnerabilità comuni, si misura la loro frequenza, si pubblicano le percentuali e si passa oltre. Abbiamo appena completato il nostro secondo anno di analisi di uno di questi report, e la scoperta più importante non è stata una percentuale, ma un pattern nascosto sotto tutte le altre. Questo è il Rapporto 2026 su Token e Rischi di Autenticazione di Imperva API Security: un'analisi anno su anno di come le organizzazioni gestiscono i JSON Web Tokens (JWT), l'Autenticazione di Base e i cicli di vita dei token, basata su dati di rilevamento reali – non su risposte a sondaggi – in 1.104 ambienti clienti e 32.725 endpoint API live. Alcune delle nostre scoperte sono buone notizie. Altre dovrebbero preoccuparvi seriamente. E una scoperta, sepolta sotto alcuni livelli dei numeri principali, è il motivo per cui crediamo che la maggior parte delle organizzazioni stia risolvendo le cose sbagliate per prime.

Cosa Abbiamo Misurato e Perché Vale la Pena Fidarsi

Questo è il secondo anno di questo benchmark, il che conta più di quanto possa sembrare. Un anno di dati vi dice cosa sta succedendo. Due anni di misurazione costante vi dicono cosa sta cambiando – e il cambiamento è dove risiede il vero segnale. Abbiamo tracciato cinque categorie di rischio, invariate rispetto alla metodologia dello scorso anno: se i JWT contengono dati sensibili che non dovrebbero, se sono firmati con algoritmi deboli, se sono emessi con una durata eccessivamente lunga, se l'Autenticazione di Base con credenziali grezze è ancora in uso e se i token continuano a concedere l'accesso dopo essere scaduti. Ogni numero riportato è una quota di rilevamenti reali, non una proiezione. Tre delle cinque categorie di rischio sono migliorate. Gli algoritmi di firma deboli sono scesi dal 19,0% al 15,2% dei rilevamenti – un calo del 20% in termini relativi, il miglioramento più netto nello studio. L'Autenticazione di Base con credenziali grezze è scesa dal 9,0% al 7,3%. I token a lunga durata sono leggermente diminuiti, dal 21,0% al 19,2%. Queste tre categorie hanno qualcosa in comune: ciascuna si mappa su una soluzione specifica e ben pubblicizzata. Utilizzare un algoritmo più forte. Migrate a OAuth2 o mTLS. Accorciate la durata dei vostri token. Niente di tutto ciò è un segreto, e i dati suggeriscono che i team che hanno ascoltato il consiglio hanno agito di conseguenza. Questo è un vero successo da prendere sul serio. È anche, come si è scoperto, la parte facile. Le due categorie di rischio che sono peggiorate quest'anno non sono quelle con una soluzione semplice e ben nota. Risiedono nei dettagli di implementazione, e, non a caso, sono le due con la linea più diretta verso l'esposizione effettiva dei dati. I dati sensibili all'interno dei token sono saliti al 49,8% di tutti i rilevamenti, rispetto al 46,0% dello scorso anno – già la categoria di rischio più grande nello studio, ora che tocca quasi la metà di tutto ciò che abbiamo misurato. Questo numero merita più allarme di quanto potrebbe ricevere a prima lettura: un JWT non è crittografato per impostazione predefinita. È tipicamente solo codificato in base64, che non è la stessa cosa – chiunque possa vedere il token può leggere cosa c'è dentro; non è necessario un exploit. Un JWT non ha bisogno di essere "hackerato" per perdere dati. Basta che passi attraverso un posto ordinario in uno stack moderno: una riga di log che cattura gli header della richiesta, lo storage del browser su una macchina condivisa, un ticket di supporto in cui uno sviluppatore incolla una richiesta per il debug. Se il token trasporta un nome, un'indirizzo email, un numero di conto, ognuno di questi percorsi quotidiani e banali diventa un potenziale evento di esposizione. L'accesso ai token scaduti è salito dal 5,0% all'8,5% – un aumento del 70% in termini relativi, il movimento più netto di qualsiasi categoria che tracciamo, in qualsiasi direzione. Questo è potenzialmente più allarmante proprio perché è più meccanico da gestire correttamente. Decidere cosa conta come "sensibile" comporta un giudizio. Far sì che un token smetta di funzionare dopo la scadenza della sua rivendicazione di scadenza non lo è. Quando fallisce comunque, è di solito perché la scadenza è stata controllata in un solo posto – un servizio di autenticazione centrale – e non è stata verificata indipendentemente in tutti gli altri posti dove il token viene utilizzato. Ogni altra ipotesi che un team di sicurezza fa sui token si basa sul fatto che la scadenza sia il freno di emergenza. Quando quel freno non funziona, tutto ciò che è costruito sopra diventa silenziosamente più debole. Non possiamo dire con certezza perché uno o entrambi questi numeri si siano mossi come hanno fatto – una miscela di fattori è plausibile, tra cui cambiamenti effettivi nelle pratiche, miglioramenti nelle nostre capacità di rilevamento e cambiamenti nelle organizzazioni misurate ogni anno. Quello che possiamo dire è che la direzione, per entrambi, è quella sbagliata, per due anni consecutivi.

La Scoperta che Cambia la Storia

Ecco cosa non ci aspettavamo di trovare: il rischio di autenticazione di solito non si presenta da solo. Siamo andati da endpoint a endpoint e abbiamo posto una domanda specifica – con quale frequenza questi cinque rischi compaiono insieme, sullo stesso API, nello stesso momento? La risposta: 13.016 dei 32.725 endpoint che abbiamo analizzato, quasi il 40%, portavano più di un rischio di autenticazione contemporaneamente. Non un caso marginale. Non occasionale. Circa due su cinque. Immaginate cosa significhi nella pratica. Un endpoint che incorpora dati sensibili nei suoi token – un rischio presente in quasi la metà di tutti i rilevamenti – che siede sullo stesso endpoint di un gap di token scaduto che permette l'accesso indefinito, un rischio che è aumentato del 70% quest'anno. Non possiamo dire con certezza quante volte si verifica questa coppia esatta; i nostri dati ci dicono che gli endpoint portano rischi multipli, non quali rischi specifici si abbinano più spesso. Ma è esattamente il tipo di scenario di accumulo per cui quasi il 40% degli endpoint è posizionato – un token che non perde solo una volta, ma continua a perdere, perché nulla nel sistema lo interrompe mai. All'estremità più estrema, è peggio del pairing. L'endpoint più rischioso che abbiamo trovato portava tutti e cinque i tipi di rischio contemporaneamente: dati sensibili nel token, un algoritmo di firma debole, una durata eccessivamente lunga, Autenticazione di Base e accesso continuato dopo la scadenza. Gli endpoint come questi di solito non sono il risultato di cinque errori separati e non correlati. Più spesso, sono un endpoint legacy o poco utilizzato che non è mai stato toccato quando il resto dell'ambiente è passato a pratiche migliori – che continua a funzionare su vecchie ipotesi mentre tutto intorno migliora. Questo è il pattern che dovrebbe riformulare la lettura di questo intero rapporto. Se questi rischi fossero sparsi a caso, un endpoint come quello sarebbe una rarità statistica. Invece, il pattern si ripete su quasi il 40% di tutto ciò che abbiamo misurato. Questo non è sparso. Questo è sistemico – e significa che la risposta standard alla scoperta di un problema di autenticazione, correggerlo e chiudere il ticket, è molto probabilmente lasciando un secondo o terzo problema intoccato sullo stesso endpoint.

Cosa Questo Significa per l'Applicazione dell'Autenticazione

Ecco il pattern scomodo che sta sotto tutti i numeri sopra: i rischi che sono migliorati quest'anno sono quelli che sono facili da controllare. I rischi che sono peggiorati sono quelli che sono difficili da controllare. Non è una coincidenza – è una descrizione abbastanza accurata di come avviene il miglioramento della sicurezza all'interno della maggior parte delle organizzazioni. "Abbiamo scelto un algoritmo di firma forte" è una domanda sì-o-no che uno scanner può rispondere in pochi secondi. "Quali dati abbiamo deciso di mettere dentro questo token e qualcuno ha rivisto questa decisione" non lo è. "Abbiamo migrato a OAuth2 o mTLS" è un'altra domanda sì-o-no. "Abbiamo accorciato la durata dei nostri token" è un'altra domanda sì-o-no. Ma "abbiamo verificato che i nostri token siano sicuri in tutti i contesti in cui vengono utilizzati" è una domanda molto più complessa. In altre parole, stiamo vedendo un miglioramento nei controlli di base, ma non stiamo vedendo un miglioramento nella comprensione di come questi controlli si applicano in contesti più ampi. E questo è il motivo per cui crediamo che la maggior parte delle organizzazioni stia risolvendo le cose sbagliate per prime. Il rapporto 2026 su Token e Rischi di Autenticazione di Imperva API Security evidenzia l'importanza di un approccio olistico alla sicurezza dei token. Mentre i controlli di base come l'uso di algoritmi di firma forti e la migrazione a protocolli più sicuri sono migliorati, le organizzazioni devono prestare maggiore attenzione ai dettagli di implementazione e alla comprensione di come questi controlli si applicano in contesti più ampi. Solo così si può garantire una sicurezza efficace e completa.