Cos’è la sicurezza delle API: guida pratica 2026

La sicurezza delle API è l’insieme di misure tecniche, processi e controlli di governance che garantiscono l’accesso agli endpoint esclusivamente ad utenti e applicazioni autorizzati, proteggendo i dati scambiati e la logica applicativa esposta. L’OWASP API Security Project ha codificato le dieci vulnerabilità più critiche per le API, diventando il riferimento tecnico di settore. I report Akamai documentano una crescita costante degli attacchi mirati agli endpoint, mentre standard come ISO 27001 forniscono il quadro di governance per integrare questi controlli nei processi aziendali. Per le organizzazioni cloud-first e per chi adotta soluzioni basate su intelligenza artificiale, la protezione delle API non è un’opzione: è il perimetro di sicurezza più esposto e più frequentemente violato.

Tre elementi definiscono una postura di sicurezza API efficace:

• Visibilità: sapere quali API esistono, chi le usa e quali dati trattano.
• Controllo degli accessi: autenticazione e autorizzazione granulare su ogni endpoint.
• Monitoraggio continuo: rilevare anomalie in tempo reale e rispondere agli incidenti prima che causino danni.

Indice

• Che cos’è un’API e perché espande la superficie di attacco
• Perché la sicurezza delle API conta: dati e impatto sul business
• Quali sono le minacce principali secondo l’OWASP API Top 10
• Come si svolge un attacco API: tre scenari reali
• Rischi specifici per REST, SOAP e GraphQL
• Best practice e controlli tecnici da implementare subito
• Come verificare che le API siano sicure: test e monitoraggio
• Cosa richiedono ISO 27001, GDPR e NIS2 per le API
• Quali strumenti e soluzioni valutare per proteggere le API
• Checklist pratica per iniziare: passi concreti per PMI e team IT
• Punti chiave
• La sicurezza delle API non è un problema tecnico: è un problema organizzativo
• Securityhub per la sicurezza delle API e la certificazione ISO 27001
• Risorse utili e letture raccomandate

Che cos’è un’API e perché espande la superficie di attacco

Un’API (Application Programming Interface) è un’interfaccia che permette a due sistemi software di comunicare, scambiare dati e invocare funzioni in modo strutturato. Quando un’applicazione mobile mostra il saldo bancario, chiama un’API. Quando un sistema di e-commerce aggiorna l’inventario in tempo reale, lo fa tramite API. Quando un modello di intelligenza artificiale riceve un prompt da un’applicazione aziendale, l’interazione avviene attraverso un endpoint API.

Le API si distinguono in tre categorie principali: pubbliche (accessibili a sviluppatori esterni), private (usate internamente tra microservizi) e partner (condivise con fornitori selezionati). Ogni categoria porta con sé un profilo di rischio diverso. Le API pubbliche sono esposte a chiunque abbia accesso a internet; quelle interne, spesso meno presidiate, possono diventare vettori di movimento laterale dopo una compromissione iniziale.

A differenza di un’applicazione web tradizionale, che espone un numero limitato di pagine, un’architettura a microservizi può contare centinaia di endpoint attivi. Ogni endpoint è una potenziale porta di ingresso. La separazione tra sicurezza applicativa e sicurezza API crea lacune di visibilità che gli attaccanti sfruttano sistematicamente.

Perché la sicurezza delle API conta: dati e impatto sul business

L’87% delle aziende ha segnalato almeno un incidente di sicurezza API negli ultimi 12 mesi, con un costo medio per incidente superiore a 700.000 dollari. Gli attacchi DDoS di livello 7, spesso combinati con abuso delle API, sono aumentati del 104% negli ultimi due anni.

Dato chiave: il costo medio di un incidente API è elevato, secondo i dati Akamai, e la crescita degli attacchi giornalieri alle API ha raggiunto il 113% nel corso del 2026.

L’adozione dell’intelligenza artificiale amplifica ulteriormente il rischio: le API che collegano applicazioni aziendali a modelli AI espongono dati sensibili e logica proprietaria, diventando bersagli ad alto valore. Akamai evidenzia che queste API sono state frequentemente oggetto di campagne mirate.

Quali sono le minacce principali secondo l’OWASP API Top 10

L’OWASP API Security Top 10 è la mappa di riferimento per comprendere le vulnerabilità più sfruttate negli endpoint. Ogni voce corrisponde a una classe di attacco documentata e replicabile.

• BOLA/IDOR (Broken Object Level Authorization): l’API non verifica se l’utente autenticato ha diritto ad accedere all’oggetto richiesto. Un attaccante modifica l’ID nella richiesta e accede ai dati di altri utenti. È la vulnerabilità più diffusa.
• Broken Authentication: meccanismi di autenticazione implementati in modo errato permettono di compromettere token o assumere l’identità di altri utenti. Segnale tipico: token con scadenza assente o prevedibile.
• Esposizione eccessiva di dati: l’API restituisce più campi di quanti ne servano al client, delegando il filtraggio all’interfaccia. I dati sensibili viaggiano in chiaro nella risposta.
• Mancanza di rate limiting: senza limiti sulle richieste, un attaccante può eseguire attacchi di forza bruta, enumerazione o denial of service. Spesso non richiede autenticazione.
• Broken Function Level Authorization: ruoli e gerarchie di accesso mal definiti permettono a utenti ordinari di invocare funzioni amministrative.
• Mass Assignment: l’API accetta proprietà JSON non filtrate e le applica direttamente al modello dati, consentendo modifiche non autorizzate.
• Security Misconfiguration: configurazioni predefinite non sicure, header HTTP mancanti, CORS permissivo, messaggi di errore verbosi che rivelano dettagli interni.
• Injection: dati non validati inviati a un interprete (SQL, NoSQL, comandi OS) permettono l’esecuzione di istruzioni arbitrarie.
• Gestione impropria degli asset: API deprecate, versioni non documentate e endpoint di debug attivi in produzione ampliano la superficie di attacco senza che il team ne sia consapevole.
• Logging e monitoring insufficienti: senza tracce di audit e alerting, un attaccante può operare per settimane prima di essere rilevato. La maggior parte delle violazioni viene scoperta da terzi, non dai team interni.

Come si svolge un attacco API: tre scenari reali

Scenario 1: BOLA su un’API REST di e-commerce

L’attaccante si autentica con un account legittimo e intercetta la richiesta GET /api/orders/12345. Sostituisce l’ID con valori incrementali: 12344, 12343, e così via. L’API non verifica che l’ordine appartenga all’utente autenticato e restituisce dati di altri clienti, inclusi indirizzi e metodi di pagamento. Il segnale di rilevazione è un pattern di richieste sequenziali sullo stesso endpoint da un singolo token, rilevabile tramite analisi dei log di accesso.

Scenario 2: Credential stuffing con abuso del rate limiting

Un attaccante dispone di un elenco di credenziali provenienti da una violazione precedente. L’API di autenticazione non impone limiti sulle richieste per IP o per account. L’attaccante distribuisce le richieste su più indirizzi IP e testa migliaia di combinazioni in poche ore. Gli account compromessi vengono poi usati per estrarre dati o effettuare transazioni fraudolente. La correlazione tra picchi di richieste fallite e successivi accessi riusciti da IP diversi è il segnale da monitorare.

Scenario 3: Compromissione di un’API collegata a un modello AI

Un’applicazione aziendale espone un endpoint che invia prompt a un modello di linguaggio esterno. L’API non valida il contenuto del prompt e non limita la quantità di dati restituiti. Un attaccante inietta istruzioni nel payload per estrarre dati di sistema o manipolare le risposte del modello. La correlazione di log tra richieste anomale all’endpoint AI e traffico in uscita verso indirizzi non autorizzati permette di ricostruire l’attacco.

Rischi specifici per REST, SOAP e GraphQL

I tre paradigmi API più diffusi presentano profili di rischio distinti, che richiedono controlli mirati.

REST:

• Endpoint pubblici spesso privi di autenticazione su metodi non critici (es. GET su risorse aggregate).
• Token bearer trasmessi in header non cifrati o con scadenza eccessivamente lunga.
• Parametri URL e query string non validati, vulnerabili a injection e BOLA.
• Versioni deprecate (/api/v1/) lasciate attive accanto alle versioni correnti.

SOAP:

• Payload XML complessi soggetti ad attacchi XXE (XML External Entity), che permettono di leggere file di sistema o effettuare richieste interne.
• WS-Security implementato in modo parziale, con firma digitale assente su parti del messaggio.
• Parsing di payload di grandi dimensioni senza limiti, esposto ad attacchi di tipo billion laughs.

GraphQL:

• Query di complessità arbitraria che possono saturare le risorse del server (query complexity attack).
• Overfetching: un singolo campo esposto permette di attraversare relazioni e recuperare dati non intenzionalmente accessibili.
• Autorizzazione a livello di campo spesso assente: il controllo avviene sul tipo, non sul singolo campo restituito.
• Introspezione dello schema abilitata in produzione, che rivela la struttura completa dell’API agli attaccanti.

Best practice e controlli tecnici da implementare subito

Un set di controlli tecnici ben prioritizzato riduce la superficie di attacco in modo misurabile. La mappatura controllo-rischio aiuta a giustificare gli investimenti e a comunicare le priorità al management.

• Autenticazione forte con OAuth 2.0 e OpenID Connect: elimina l’uso di chiavi API statiche e introduce token a scadenza breve con scope limitati. Mitiga broken authentication e accessi non autorizzati.
• Autorizzazione a livello di oggetto: ogni richiesta deve verificare che il soggetto autenticato abbia diritto sull’oggetto specifico, non solo sulla risorsa generica. Contrasta BOLA/IDOR.
• Validazione dell’input su ogni endpoint: schema validation (JSON Schema, OpenAPI) per rifiutare payload malformati prima che raggiungano la logica applicativa. Riduce il rischio di injection e mass assignment.
• Cifratura in transito e a riposo: TLS 1.2 come minimo, TLS 1.3 come standard; cifratura dei dati sensibili nei database e nei log.
• Rate limiting e throttling: limiti per IP, per token e per account su tutti gli endpoint di autenticazione e su quelli che espongono dati sensibili. Contrasta brute force, credential stuffing e DoS.
• API gateway e WAF: punto di ingresso centralizzato per applicare policy uniformi, ispezionare il traffico e bloccare pattern di attacco noti. Akamai, IBM DataPower e Palo Alto Networks Prisma Cloud offrono funzionalità specifiche per la protezione degli endpoint API.
• Logging strutturato e alerting: ogni richiesta deve produrre un log con token, IP, endpoint, codice di risposta e latenza. Gli alert devono scattare su anomalie statistiche, non solo su soglie fisse.
• Inventario e gestione degli asset API: nessun endpoint deve essere attivo senza essere documentato e monitorato. Strumenti di API discovery automatizzano questa attività.

Un consiglio: prioritizzate i controlli in base all’esposizione: gli endpoint pubblici che trattano dati personali o transazioni finanziarie richiedono tutti i controlli sopra elencati fin dal primo giorno; gli endpoint interni tra microservizi possono seguire un piano di rollout progressivo.

Come verificare che le API siano sicure: test e monitoraggio

La sicurezza delle API non si verifica una volta sola: richiede test continui integrati nel ciclo di sviluppo e monitoraggio in produzione.

Integrare SAST e DAST nella pipeline CI/CD garantisce che le regressioni di sicurezza vengano rilevate prima del rilascio. Il monitoraggio comportamentale in produzione, invece, cattura attacchi che superano i controlli statici perché sfruttano la logica applicativa piuttosto che vulnerabilità tecniche note. La gestione delle vulnerabilità in ottica ISO 27001 fornisce il processo per classificare, prioritizzare e risolvere i problemi rilevati.

Cosa richiedono ISO 27001, GDPR e NIS2 per le API

La sicurezza tecnica delle API deve essere ancorata a requisiti normativi precisi, soprattutto per le organizzazioni che operano in Europa centrale.

• ISO 27001: i controlli dell’Allegato A relativi alla sicurezza nella filiera ICT e alla gestione dei servizi di rete si applicano direttamente alle API esposte verso fornitori e partner. La certificazione ISO 27001 è spesso richiesta come prerequisito da grandi clienti e Pubbliche Amministrazioni, e fornisce il quadro per integrare controlli tecnici e di processo in modo documentato e verificabile.
• GDPR: ogni API che tratta dati personali deve rispettare i principi di minimizzazione (restituire solo i campi necessari), accountability (log di accesso e audit trail) e, nei casi ad alto rischio, richiedere una valutazione d’impatto (DPIA). La protezione dei dati personali via API è un obbligo, non una scelta progettuale.
• NIS2: la direttiva impone obblighi di gestione del rischio nella supply chain digitale e di notifica degli incidenti entro 24 ore per gli incidenti significativi. Le API che connettono sistemi di fornitori critici rientrano direttamente in questi obblighi. Le organizzazioni devono documentare le dipendenze API esterne e includere scenari di compromissione API nei piani di risposta agli incidenti.
• ISO 27017 e ISO 27018: per le API esposte su infrastrutture cloud, questi standard aggiuntivi definiscono controlli specifici per la protezione dei dati personali nel cloud, rilevanti per chi gestisce API che interagiscono con servizi SaaS o piattaforme di intelligenza artificiale.

Quali strumenti e soluzioni valutare per proteggere le API

La scelta degli strumenti dipende dalla maturità del team, dall’architettura esistente e dai requisiti di conformità. Le categorie principali da considerare sono:

• API gateway: punto di controllo centralizzato per autenticazione, autorizzazione, rate limiting e routing. Soluzioni come IBM DataPower o gateway open source integrabili con infrastrutture esistenti coprono questa categoria.
• Piattaforme di API management: aggiungono funzionalità di catalogazione, versioning e analytics al gateway. Utili per organizzazioni con molti endpoint e team di sviluppo distribuiti.
• WAF con protezioni API specifiche: Akamai App & API Protector e Palo Alto Networks Prisma Cloud offrono ispezione del traffico API con rilevamento comportamentale e protezione da attacchi OWASP.
• Strumenti di osservabilità e SIEM: aggregano log da gateway, applicazioni e infrastruttura per correlare eventi e rilevare campagne multi-livello. La correlazione tra log API e log di rete è il requisito minimo per rilevare attacchi persistenti.
• Servizi di pen test e red team specializzati su API: necessari per validare i controlli implementati e scoprire vulnerabilità logiche che gli scanner automatici non rilevano.

Nella valutazione, verificare: modalità di distribuzione (cloud, on-premise, ibrida), integrazione con pipeline CI/CD, supporto nativo per OAuth 2.0 e OpenID Connect, capacità di API discovery automatico, e conformità ai requisiti GDPR e NIS2 per la localizzazione dei dati. Un API gateway centralizzato con policy condivise e automazione tramite Infrastructure as Code migliora coerenza e sicurezza in modo documentato, come dimostrano casi di implementazione reale.

Checklist pratica per iniziare: passi concreti per PMI e team IT

1. Censire tutte le API attive: produrre un inventario completo di endpoint interni, esterni e di terze parti, con indicazione del proprietario, dei dati trattati e dello stato di documentazione.
2. Classificare i dati esposti: identificare quali endpoint trattano dati personali, dati finanziari o informazioni riservate, e assegnare un livello di criticità.
3. Mappare le autorizzazioni esistenti: verificare che ogni endpoint abbia controlli di autenticazione e autorizzazione attivi e documentati.
4. Applicare policy sul gateway: configurare rate limiting, autenticazione OAuth 2.0 e validazione dello schema su tutti gli endpoint critici.
5. Attivare logging strutturato e alerting: definire quali eventi generano log, dove vengono conservati e quali soglie attivano notifiche al team di sicurezza.
6. Integrare test di sicurezza nella pipeline CI/CD: aggiungere scansioni SAST e DAST come gate obbligatori prima del rilascio in produzione.
7. Definire ruoli e responsabilità DevSecOps: assegnare ownership della sicurezza API a figure specifiche nel team di sviluppo e nel team di sicurezza, evitando zone grigie.
8. Formare il team sulle vulnerabilità OWASP: una sessione pratica sulle prime cinque voci dell’OWASP API Top 10 riduce significativamente gli errori di implementazione più comuni.
9. Redigere un piano di risposta agli incidenti API: definire procedure di contenimento, notifica e ripristino specifiche per scenari di compromissione API, in linea con gli obblighi NIS2.
10. Valutare la certificazione ISO 27001 come leva di governance: strutturare i controlli tecnici all’interno di un Sistema di Gestione della Sicurezza delle Informazioni (SGSI) certificato garantisce continuità, verificabilità e credibilità verso clienti e partner. I passaggi per ottenere ISO 27001 sono documentati e seguibili anche per le PMI.

Punti chiave

La sicurezza delle API richiede visibilità completa sugli endpoint, controlli tecnici prioritizzati secondo l’OWASP API Top 10 e un framework di governance, come ISO 27001, per rendere i controlli verificabili e sostenibili nel tempo.

La sicurezza delle API non è un problema tecnico: è un problema organizzativo

La maggior parte degli incidenti API che analizzo non nasce da vulnerabilità tecniche oscure. Nasce da endpoint dimenticati, da token senza scadenza, da team che non sanno quali API sono in produzione. L’OWASP API Top 10 esiste da anni: BOLA, broken authentication, mancanza di rate limiting sono vulnerabilità note, documentate, con esempi pubblici. Eppure continuano a essere sfruttate con successo.

Il problema reale è organizzativo. Molte organizzazioni dichiarano priorità alla sicurezza delle API ma non hanno un inventario aggiornato, non hanno un processo di test integrato nella pipeline e non hanno definito chi è responsabile di cosa. La discrepanza tra percezione del rischio e risorse effettivamente dedicate è la vera vulnerabilità sistemica.

La certificazione ISO 27001 non risolve i problemi tecnici da sola, ma impone una disciplina organizzativa che li rende visibili e gestibili: ownership dei controlli, revisioni periodiche, procedure documentate. Per una PMI che non può permettersi un team di sicurezza dedicato, questo framework è spesso la differenza tra un incidente contenuto e uno che blocca l’operatività per settimane. L’automazione aiuta, ma senza governance rimane un insieme di strumenti scollegati.

Securityhub per la sicurezza delle API e la certificazione ISO 27001

Securityhub affianca le organizzazioni italiane che vogliono strutturare la sicurezza delle proprie API all’interno di un framework di governance verificabile. Il percorso parte dall’audit degli endpoint e dalla mappatura dei controlli esistenti, per arrivare all’implementazione di un SGSI conforme a ISO 27001 e, dove rilevante, a ISO 27017 e ISO 27018 per le API che trattano dati personali in cloud.

Per le PMI che devono rispondere a requisiti GDPR e NIS2 senza disporre di un team di sicurezza interno, Securityhub offre supporto documentale, formazione e consulenza operativa. Il risultato è una postura di sicurezza API misurabile, certificabile e comunicabile a clienti e partner. Per iniziare, è possibile consultare la guida all’implementazione ISO 27001 o contattare direttamente il team per un primo confronto sui requisiti specifici.

Risorse utili e letture raccomandate

• OWASP API Security Project: la fonte primaria per le vulnerabilità API, con descrizioni tecniche, esempi e guide di remediation. Lettura obbligatoria per sviluppatori e team di sicurezza.
• OWASP API Security Top 10 (PDF): il documento originale con la classificazione delle dieci vulnerabilità più critiche, con livelli di rischio e indicazioni pratiche.
• Akamai: report su API, applicazioni e DDoS: dati aggiornati su trend degli attacchi, crescita degli incidenti API e impatto dell’intelligenza artificiale sulla superficie di attacco. Utile per il management e per chi deve giustificare investimenti in sicurezza.
• Intesys: caso studio su API management e sicurezza: esempio pratico di implementazione di API gateway, policy condivise e automazione tramite Infrastructure as Code in un contesto aziendale reale.
• Securityhub: guida alla sicurezza nelle API per professionisti IT: approfondimento tecnico su strategie e strumenti per la protezione degli endpoint in contesti enterprise.
• Securityhub: guida ISO 27017 per aziende cloud: riferimento per le organizzazioni che espongono API su infrastrutture cloud e devono rispondere a requisiti di sicurezza specifici.
• Securityhub: compliance GDPR e ISO 27018: guida per chi gestisce API che trattano dati personali e deve dimostrare conformità al GDPR e allo standard ISO 27018.

Raccomandati

• Cos’è la sicurezza nelle API: guida per professionisti IT – Security Hub
• Cos’è la Sicurezza Software: Guida Completa 2025 – Security Hub
• Che Cos’è la Sicurezza Cloud: Guida Completa – Security Hub
• Cos’è la sicurezza dei SaaS: guida pratica per PMI – Security Hub