Sicurezza delle API: il tallone d’Achille dell’economia digitale

C’è un paradosso silenzioso al cuore dell’economia digitale contemporanea. Le API (Application Programming Interface) sono l’infrastruttura nervosa che tiene in vita ogni transazione bancaria, ogni ordine di e-commerce, ogni scambio di dati sanitari, ogni richiesta di un’applicazione mobile. Sono invisibili all’utente finale, onnipresenti nel codice, fondamentali per qualunque modello di business digitale. Eppure, proprio questa ubiquità le rende il bersaglio preferito degli attaccanti moderni e, troppo spesso, il punto più trascurato dell’intera catena della sicurezza informatica.

I numeri aiutano a comprendere la dimensione del problema. Secondo il Cloudflare Radar 2025 Year in Review, l’analisi più autorevole e aggiornata disponibile, basata sull’osservazione diretta di una rete globale presente in oltre 330 città, le API rappresentano oggi più della metà di tutto il traffico web dinamico, con un’incidenza in costante crescita.

Akamai, su un campione diverso di traffico internet, stima la quota fino all’83%. Nel solo 2025, le API hanno generato oltre 11.000 bollettini di sicurezza, pari al 17% di tutte le vulnerabilità software pubblicamente divulgate in un anno. Il traffico malevolo diretto verso le API è cresciuto del 681% nell’arco degli ultimi anni, secondo il Wallarm 2026 API ThreatStats Report. Quasi il 99% delle organizzazioni ha dichiarato di aver subito almeno un incidente legato alla sicurezza delle API negli ultimi dodici mesi. Non si tratta di statistiche marginali: è la fotografia di un’infrastruttura critica sotto assedio sistematico, e di un settore che stenta ancora a rispondere con adeguata consapevolezza.

Un bersaglio su misura per gli attaccanti

Cosa rende le API un vettore così attraente? La risposta sta nella loro natura strutturale. A differenza delle applicazioni web tradizionali, un’API non ha una “porta d’ingresso” visibile: non ha un login, non ha un CAPTCHA, non ha l’interfaccia grafica che un essere umano deve attraversare. È progettata per essere consumata da macchine, e le macchine non faticano a sparare decine di migliaia di richieste al secondo. Un’organizzazione che espone API pubbliche riceve in media 10.000 attacchi al giorno. Le API GraphQL, sempre più diffuse per la loro flessibilità, hanno visto un incremento del 140% nei tentativi di abuso nel corso del 2025.

La semplicità di attacco è altrettanto allarmante. Secondo il Wallarm 2026 API ThreatStats Report, il 97% delle vulnerabilità API è sfruttabile con una singola richiesta HTTP. Il 98% è classificato come facile o banale da sfruttare. Il 59% non richiede nemmeno autenticazione. Il 30% ha già exploit pubblici disponibili nel momento stesso in cui la vulnerabilità viene divulgata. Questa combinazione di alta diffusione, alta sfruttabilità e bassa complessità trasforma le API in un terreno di caccia privilegiato per attori di ogni livello, dai criminali opportunistici alle APT sofisticate.

A questo si aggiunge la questione del rilevamento. Solo il 21% delle organizzazioni dichiara di avere capacità solide nell’identificare attacchi a livello API. Appena il 13% riesce a prevenire più del 50% degli attacchi. Gli strumenti tradizionali come i Web Application Firewall (WAF) si rivelano inadeguati: il 53% delle organizzazioni ne riconosce apertamente i limiti nella rilevazione di frodi a livello API. Siamo di fronte a un disallineamento strutturale tra la superficie esposta e le difese disponibili.

L’OWASP API Security Top 10: una mappa delle fragilità

Dal 2019, l’Open Worldwide Application Security Project pubblica la propria lista delle vulnerabilità API più critiche. La versione aggiornata al 2023, oggi il riferimento di settore, riflette un’evoluzione significativa del panorama delle minacce. L’88% degli attacchi reali sfrutta almeno una delle vulnerabilità elencate, il che rende questa tassonomia uno strumento di prioritizzazione imprescindibile per qualunque team di sicurezza.

API1:2023 – Broken Object Level Authorization (BOLA) rimane, a distanza di anni, la vulnerabilità più sfruttata nelle API. Si manifesta quando un endpoint espone dati di un oggetto senza verificare che l’utente autenticato abbia effettivamente il diritto di accedervi. Un attaccante che conosce o indovina l’identificatore di un record (un numero d’ordine, un ID paziente, un codice cliente) può semplicemente cambiarlo nella richiesta e accedere ai dati altrui. La logica è elementare; l’impatto, devastante.

API2:2023 – Broken Authentication aggrega tutte le debolezze legate alla gestione dell’identità: password deboli, token JWT mal configurati, assenza di blocco su tentativi multipli, meccanismi di reset insicuri. In questa categoria rientrano anche i frequenti errori nella gestione dei segreti: chiavi API hard-coded nel codice sorgente, token esposti in repository pubblici, credenziali condivise tra ambienti di produzione e sviluppo. Un caso emblematico, divulgato nel dicembre 2024 dal team TRIAD di CloudSEK: la scoperta di oltre 30.000 workspace Postman accessibili pubblicamente, contenenti token di accesso attivi, chiavi API reali e payload con dati sanitari e credenziali aziendali di organizzazioni in settori che vanno dalla finanza all’abbigliamento sportivo.

API3:2023 – Broken Object Property Level Authorization (BOPLA) è una novità della lista 2023, nata dalla fusione di due categorie precedenti (Excessive Data Exposure e Mass Assignment). Riconosce che il problema non è solo chi può accedere a un oggetto, ma anche quali proprietà di quell’oggetto possono essere lette o modificate. Un utente che riesce a modificare un campo come role: admin in una richiesta PUT sta sfruttando esattamente questa vulnerabilità.

API4:2023 – Unrestricted Resource Consumption riguarda la mancanza di limiti efficaci sull’uso delle risorse: assenza di rate limiting, nessun controllo sulla dimensione dei payload, nessun tetto alle query su database o ai servizi di terze parti a pagamento. Gli attacchi DDoS diretti alle API sono cresciuti del 200% nel 2025. In assenza di throttling, un attaccante può paralizzare un servizio o generare costi operativi insostenibili attraverso richieste massive e automatizzate.

API5:2023 – Broken Function Level Authorization (BFLA) colpisce quando la distinzione tra funzioni amministrative e funzioni utente non è enforcement a livello backend. Se un’API non verifica il livello di privilegio richiesto per ciascun endpoint, un utente ordinario potrebbe invocare endpoint di amministrazione semplicemente conoscendone il path.

API6:2023 – Unrestricted Access to Sensitive Business Flows è la vulnerabilità più sottile e difficile da rilevare automaticamente. Non riguarda un bug tecnico, ma l’assenza di protezione contro l’uso massiccio e automatizzato di flussi di business legittimi: acquisto di biglietti, creazione di account, pubblicazione di contenuti. Un bot che acquista in millisecondi tutti i posti di un concerto sta sfruttando questa categoria, e nessuno scanner tradizionale lo individuerà.

API7:2023 – Server-Side Request Forgery (SSRF) è una novità del 2023. Si verifica quando un’API recupera risorse remote senza validare l’URI fornito dall’utente, consentendo a un attaccante di instradare richieste verso sistemi interni, servizi di metadata cloud o endpoint protetti da firewall.

API8:2023 – Security Misconfiguration è il contenitore di una casistica vastissima: CORS permissivi, header di sicurezza assenti, messaggi di errore verbosi che rivelano la struttura interna, TLS non configurato, porte di debug esposte in produzione. I cloud provider registrano misconfigurazioni API in oltre il 30% dei casi di breach.

API9:2023 – Improper Inventory Management riguarda le cosiddette shadow API, un tema che merita un approfondimento dedicato per la rilevanza che ha assunto negli ultimi anni, come illustrato nel paragrafo seguente.

API10:2023 – Unsafe Consumption of APIs è l’unica voce della lista che capovolge la prospettiva: non riguarda i rischi di essere un provider di API, ma quelli di essere un consumer. Un’applicazione che consuma API di terze parti senza validarne l’output, senza limitare i dati elaborati e senza considerare la possibilità di un provider compromesso, eredita automaticamente le vulnerabilità di quell’ecosistema.

Il problema delle shadow API: quello che non sai che esiste

Tra tutte le sfide della sicurezza API, la gestione delle API non documentate, denominate shadow API o zombie API, è probabilmente la più sistemica e la più sottovalutata. Le shadow API sono endpoint reali, attivi, raggiungibili dalla rete, che non compaiono in nessun inventario ufficiale, non sono soggetti a test di sicurezza, non sono monitorati da nessun team. Possono essere API di vecchie versioni dimenticate durante una migrazione, endpoint di sviluppo mai rimossi in produzione, integrazioni create da team interni senza passare per il processo formale di release.

I numeri dicono che le shadow API rappresentano oltre il 20% dell’inventario API totale nelle organizzazioni enterprise. Le istituzioni finanziarie gestiscono in media 601 API e una parte rilevante di queste sfugge a qualsiasi governance attiva. Un caso paradigmatico del 2025 è quello di Stripe: attaccanti hanno individuato un endpoint legacy (/v1/sources) ancora collegato ai sistemi di validazione pagamenti, privo dei controlli di sicurezza delle API moderne, e lo hanno sfruttato per condurre una campagna massiva di card skimming su almeno 49 e-commerce compromessi. L’endpoint era un residuo dell’architettura precedente, scarsamente documentato e ignorato nei security audit. Non una vulnerabilità zero-day: un oggetto dimenticato.

Quello di Stripe non è un caso isolato. Il breach di Optus del settembre 2022 ha esposto i dati personali di quasi 10 milioni di clienti australiani, quasi un terzo della popolazione del paese, attraverso un’API priva di autenticazione rimasta accessibile da internet per circa tre mesi. Secondo l’analisi dell’Australian Communications and Media Authority (ACMA), un errore di codifica introdotto nel 2018 aveva reso inefficaci i controlli di accesso su un sottodominio, e il problema era rimasto non rilevato nonostante una correzione parziale applicata nel 2021 sul dominio principale. L’attaccante non aveva bisogno di strumenti sofisticati: l’API non richiedeva alcuna autenticazione, e i customer ID erano numerici e incrementali, rendendoli banalmente enumerabili.

Il breach che nel 2022 ha colpito Twitter è spesso descritto in modo impreciso. Non si trattava di un’API legacy dimenticata, ma di un bug introdotto nell’aggiornamento del codice di giugno 2021: la vulnerabilità consentiva a chiunque di sottomettere un numero di telefono o un indirizzo e-mail all’API della piattaforma e ricevere in risposta l’ID dell’account Twitter associato, anche quando l’utente aveva esplicitamente configurato le impostazioni di privacy per impedire questa correlazione.

Il bug fu segnalato tramite bug bounty in gennaio 2022 e corretto subito dopo; era però già stato sfruttato da almeno dicembre 2021. Un threat actor aveva creato un database di 5,4 milioni di profili, incluse informazioni private come numeri di telefono e indirizzi e-mail, poi venduto online e infine diffuso gratuitamente. Ulteriori analisi rivelarono che la stessa vulnerabilità era stata sfruttata su scala molto più ampia, portando a un dataset finale di oltre 200 milioni di account.

In entrambi i casi, come nel caso Stripe, la catena causale è identica: controlli insufficienti, endpoint dimenticati o alterati, nessun monitoraggio, nessun alert.

Breach recenti: leggere gli incidenti come segnali

L’analisi dei 60 breach API divulgati nel 2025, condotta da Wallarm nel 2026 API ThreatStats Report, restituisce un quadro per settori e categorie: software (15%), piattaforme AI (15%), vendor di cybersecurity (13%), SaaS (8%), automotive (7%), cloud services (7%). Mappati sulla tassonomia OWASP, la broken authentication è responsabile del 52% degli incidenti, mentre l’unsafe consumption di API di terze parti spiega il 27%.

Tra gli episodi più rilevanti del 2025: API di terze parti hanno esposto milioni di record presso il fornitore di servizi creditizi 700Credit; debolezze nell’autenticazione delle API Qantas hanno permesso accessi di massa non autorizzati; credenziali rubate e permessi API eccessivi hanno abilitato transazioni fraudolente su SwissBorg; server MCP esposti hanno fatto trapelare infrastrutture di agent AI su larga scala. A maggio 2025 un hacker con lo pseudonimo “ByteBreaker” ha pubblicato su forum underground la presunta raccolta di dati relativi a 1,2 miliardi di account Facebook tramite abuso di API.

Meta ha negato si tratti di un breach nuovo, sostenendo che il dataset reimpacchetti dati già divulgati nel 2021; i ricercatori di Cybernews e Hackread hanno rilevato incongruenze strutturali nella dimensione dichiarata e sovrapposizioni significative con il leak precedente. Il claim resta pertanto non verificato indipendentemente, ma l’episodio conferma il modello di sfruttamento delle API come vettore di data harvesting massivo.

Il filo conduttore è sempre lo stesso: non exploit sofisticati, non attori nation-state con capacità eccezionali, ma debolezze fondamentali (autenticazione assente o debole, autorizzazione non granulare, endpoint dimenticati, terze parti non verificate) sfruttate con strumenti automatizzati alla portata di qualunque attore.

DevSecOps e la sicurezza by design: integrare prima che sia tardi

La risposta sistemica al problema della sicurezza API non può essere post-hoc. Applicare controlli di sicurezza su API già in produzione è costoso, inefficace e spesso destinato a fallire. La strada maestra è l’integrazione della sicurezza nel ciclo di vita dello sviluppo, in quello che il settore definisce approccio DevSecOps oppure, più recentemente, shift-left security.

In pratica, questo significa che il processo di sviluppo deve includere: modellazione delle minacce nella fase di design (identificare le attack surface prima di scrivere codice); revisione del codice orientata alla sicurezza (con particolare attenzione alla gestione dei segreti, alla sanitizzazione degli input, alla corretta implementazione dell’autenticazione); test automatizzati di sicurezza nelle pipeline CI/CD (SAST per il codice sorgente, DAST per le API deployate, test specifici contro le vulnerabilità OWASP); e monitoraggio continuo in produzione, con alerting su anomalie comportamentali che potrebbero segnalare tentativi di exploitation.

Questo approccio richiede che la sicurezza non sia responsabilità esclusiva di un team separato, ma venga distribuita attraverso l’intera organizzazione di sviluppo. I developer devono conoscere le vulnerabilità OWASP API Top 10. I team di prodotto devono includere requisiti di sicurezza nelle specifiche. I team di infrastruttura devono garantire che le pipeline espongano segnali di sicurezza rilevabili. Tuttavia, secondo il 2025 State of API Security Report di Traceable AI, basato su oltre 1.500 professionisti IT e cybersecurity, solo il 14% delle organizzazioni ha attualmente una strategia formale di API posture governance. Il gap tra l’ambizione del DevSecOps e la sua attuazione pratica rimane ampio.

Un nodo critico è rappresentato dall’adozione dell’AI generativa nello sviluppo software. La pratica del cosiddetto vibe coding, generare codice API con assistenti AI senza un’adeguata revisione critica, è diventata pervasiva. Secondo Akamai, l’AI-assisted coding è associato a un aumento di misconfigurazioni, impostazioni predefinite insicure e vulnerabilità trascurate nelle API generate. Il 65% delle organizzazioni considera la GenAI un rischio da serio a estremo per la sicurezza delle proprie API. La velocità di sviluppo che l’AI permette amplifica proporzionalmente la superficie esposta se non è accompagnata da un’eguale accelerazione dei controlli di sicurezza.

PSD2, Open Banking e DORA: la sicurezza delle API come obbligo regolatorio

Nel settore finanziario, la sicurezza delle API non è solo una questione tecnica: è un obbligo normativo con conseguenze legali misurabili. La Direttiva PSD2 ha imposto alle banche europee di esporre API dedicate ai Third-Party Provider (TPP), ovvero fintech autorizzate a offrire servizi di pagamento e aggregazione di conti, con requisiti stringenti di Strong Customer Authentication (SCA), dynamic linking e identificazione tramite certificati eIDAS. In questa architettura aperta, ogni vulnerabilità su un’API bancaria è potenzialmente una violazione dei dati del cliente, una frode abilitata dalla piattaforma e una sanzione per la banca emittente.

Le penali per non conformità possono raggiungere il 4% del fatturato annuo o 5 milioni di euro, applicando il criterio più alto. Ma il quadro si è ulteriormente complicato. Con l’accordo politico su PSD3/PSR raggiunto a novembre 2025 e l’adozione formale attesa nel primo semestre 2026, cui seguirà un periodo di transizione di 21 mesi verso l’implementazione completa prevista intorno al 2027, le banche europee si trovano ora a navigare obblighi paralleli e crescenti: responsabilità ampliata per le frodi da impersonificazione, verifica obbligatoria del beneficiario (Verification of Payee), autenticazione a doppia inerenza e benchmark di performance API più severi.

Parallelamente, DORA (il Digital Operational Resilience Act, entrato pienamente in vigore il 17 gennaio 2025) ha unificato il regime di incident reporting per il settore finanziario. L’EBA ha formalmente abrogato le proprie linee guida PSD2 sulla notifica degli incidenti, sostituendole con il framework DORA. Questo cambiamento non è meramente amministrativo: significa che un breach su un’API Open Banking deve ora essere gestito attraverso il prisma della resilienza operativa digitale, con obblighi di notifica armonizzati e un orizzonte di governance che abbraccia l’intera catena tecnologica, incluse le terze parti. Va notato che questa convergenza risolve parzialmente, ma non elimina, la tensione strutturale tra PSD2 (che spinge verso l’apertura dei dati) e il GDPR (che impone la protezione dei dati personali).

Come documentato in uno studio peer-reviewed pubblicato su MDPI nel gennaio 2026, i requisiti sovrapposti di consenso e protezione dei dati creano ancora incertezza nella governance e nell’allocazione delle responsabilità tra banche e TPP, anche alla luce del quadro normativo europeo DORA e NIS2.

Sul piano tecnico, il framework FAPI 2.0 (Financial-grade API Security Profile) ha raggiunto la propria specifica finale nel febbraio 2025, diventando il riferimento per l’implementazione sicura di API ad alto valore. FAPI 2.0 richiede l’uso di Pushed Authorization Requests (PAR), PKCE per tutti i client e token sender-constrained tramite mTLS o DPoP. Il 75% delle banche europee ha già adottato lo standard NextGenPSD2 del Berlin Group.

PCI DSS 4.0.1, diventata l’unica versione attiva dall’aprile 2025, è il primo standard PCI a citare esplicitamente le API come oggetto di controlli di sicurezza: il Requisito 6.4.2 impone soluzioni automatizzate davanti alle API pubbliche per rilevare e prevenire attacchi; il Requisito 6.3.2 richiede un inventario completo di tutto il software custom incluse le API. La non conformità comporta sanzioni tra 5.000 e 100.000 dollari al mese.

La frammentazione persistente nella qualità delle implementazioni rimane una fonte di rischio documentata dalla stessa Commissione Europea, che ha rilevato significative discrepanze negli standard API tra istituti diversi: un problema che PSD3 punta a risolvere attraverso benchmark di performance più stringenti e l’eliminazione definitiva del fallback allo screen scraping.

Verso una maturità sistemica: cosa manca ancora

Osservando il panorama nel suo insieme, la distanza tra il livello di esposizione e il livello di maturità difensiva delle organizzazioni appare strutturalmente preoccupante. Il 57% delle organizzazioni ha subito un breach API negli ultimi due anni, con il 73% di queste che ne ha subiti tre o più. Il 41% dichiara cinque o più episodi. Si tratta di fallimenti sistemici, non di incidenti episodici.

La risposta richiede un cambio di paradigma su più livelli. Primo, il problema della visibilità: non è possibile proteggere ciò che non si conosce. La discovery continua delle API, incluse le shadow API, deve diventare una funzione operativa permanente, non un esercizio periodico. Secondo, il problema della governance: le organizzazioni devono trattare ogni API come un asset critico, con un ciclo di vita documentato, un responsabile identificato, test di sicurezza automatizzati e metriche di esposizione misurabili. Terzo, il problema della cultura: finché la sicurezza API è percepita come un vincolo tecnico imposto a posteriori, anziché come una proprietà architettonica costruita ab initio, il divario tra attaccanti e difensori continuerà ad ampliarsi.

Le previsioni per il 2026 non lasciano spazio all’ottimismo passivo. Akamai stima che le API diventeranno il vettore dominante per i breach a livello applicativo, potenzialmente responsabili di più della metà di tutti gli attacchi alle applicazioni. Il Model Context Protocol, l’infrastruttura che collega gli agenti AI alle API esterne, ha già accumulato 315 vulnerabilità documentate nel 2025, pari al 14,4% di tutte le vulnerabilità AI, con una crescita del 270% tra il secondo e il terzo trimestre. L’interconnessione crescente tra sistemi AI agentici e API di business apre una superficie d’attacco che oggi non è ancora pienamente compresa né adeguatamente presidiata.

Conclusione

Le API sono, nel senso più letterale, i punti di connessione dell’economia digitale. Sono ciò che permette a una banca di condividere i dati di un cliente con un’app fintech, a un ospedale di integrare i referti con un sistema di telemedicina, a una supply chain di coordinare ordini e spedizioni in tempo reale. La loro sicurezza non è un problema tecnico tra gli altri: è una condizione necessaria per la fiducia digitale su cui si regge l’intero ecosistema.

Il paradosso è che questa centralità non si traduce ancora in un’attenzione proporzionale. Le organizzazioni investono in perimetri, in endpoint protection, in SIEM sofisticati e lasciano le API senza inventario, senza test, senza monitoraggio. Solo il 14% ha una strategia formale di governance. Meno di una su cinque riesce a rilevare con sufficiente efficacia gli attacchi che la colpiscono. Gli attaccanti hanno capito dove si trova il valore. La domanda è se le organizzazioni abbiano la stessa chiarezza sul proprio tallone d’Achille e, soprattutto, se abbiano la volontà di trasformare quella consapevolezza in azione prima che sia il prossimo breach a farlo decidere per loro.