Skip to main content

Quando si decide di basare la propria strategia d’integrazione IT sulle API occorre anche pensare a un approccio strategico per garantirne la sicurezza. Le API, infatti, presentano delle caratteristiche specifiche che richiedono una gestione ad hoc per evitare perdite o violazioni dei dati. L’importanza di questo tema è testimoniata dai report di sicurezza che mostrano andamenti crescenti non solo dell’utilizzo delle API, ma ancora di più del traffico maligno e degli incident sulle stesse.
Capiamo insieme quali sono le vulnerabilità che le affliggono maggiormente e le tipologie di attacco dalle quali un’azienda deve proteggersi.

Quali sono le minacce più frequenti per le API?

L’utilizzo delle API è un fenomeno che caratterizza i nuovi approcci per creare applicazioni web e app mobile, per raggiungere nuovi touch point digitali e anche per integrare i servizi tra aziende diverse. Questo le rende un elemento chiave nell’ondata di digitalizzazione che sta interessando le aziende, ma anche un bersaglio per le minacce cyber.

Secondo le stime di Gartner, nel 2022 gli attacchi alle API diventeranno il primo vettore d’attacco per frequenza, provocando fenomeni di data breach per le applicazioni web enterprise.

Da dove nascono queste vulnerabilità?

Nelle applicazioni web tradizionali l’elaborazione è eseguita prevalentemente server side e la pagina web risultante viene inviata al client che ha il compito di gestirne la visualizzazione. Le applicazioni moderne, invece, sfruttano le API per scambiare “dati grezzi” con i sistemi di backend e lasciano alla UI la gestione dello stato e della visualizzazione.

Differenza tra sicurezza delle applicazioni web e delle API

Le API a differenza delle applicazioni web tradizionali ritornano “dati”, indipendenti dallo strato di presentazione (APIsecurity.io)

Se da un lato quindi le API non hanno un frontend e risultano complessivamente più semplici di un’applicazione web tradizionale (full-stack), dall’altro hanno delle caratteristiche che le rendono aperte a nuove tipologie di attacco e richiedono, dal punto di vista della sicurezza, una trattazione dedicata.

Le peculiarità delle API

Le API tipicamente rispondono a criteri d’uso generale, risultando:

  • Riutilizzabili all’interno di vari silos applicativi;
  • Consumabili da una pletora di client e canali diversi con differenti tipologie di utenti, che presentano diversi gradi di trust;
  • In grado di inglobare logiche di business utili ai diversi contesti di utilizzo e ad assumere un controllo centralizzato per l’autenticazione e l’autorizzazione.

Al loro interno, a livello implementativo, assumono una cosiddetta “natura orizzontale”: vanno cioè a riutilizzare servizi e microservizi esistenti aumentando così la superficie di esposizione. I microservizi, inoltre, secondo le recenti tendenze “cloud native”, risultano essere scritti in disparati linguaggi di programmazione ed eseguiti in altrettanti ambienti d’esecuzione tra loro indipendenti.
Si intuisce quindi come le API, oltre ad una sicurezza perimetrale (nord-sud) tipicamente presidiata dagli API Gateway e dai WAF, sfruttano molto anche il cosiddetto traffico “east-west”, in particolar modo se eseguite all’interno di ambienti di orchestrazione di container come Kubernetes dove concorre l’esecuzione e la combinazione di diversi servizi (Service Mesh).

Come proteggersi quindi? Il presupposto è capire da cosa bisogna difendersi.

La Top 10 di OWASP dedicata alle API

In questo panorama già nel 2019 OWASP (Open Web Application Security Project), la famosa comunità non-profit che originato la medesima classifica per le applicazioni web, ha ritenuto necessario stilare la “Top 10” dedicata alle API identificando le dieci tipologie di attacco che specificatamente le mettono più a rischio:

  1. Broken object level authorization: un attaccante altera gli input per tentare di accedere ad oggetti/informazioni a cui non è autorizzato;
  2. Broken user authentication: errori nella implementazione della autenticazione che consentono ad un attaccante di assumere l’identità di altri utenti;
  3. Excessive data exposure: i dati delle API contengono informazioni a cui l’utente non è autorizzato ad accedere o la cui visibilità è (erroneamente) delegata al client;
  4. Lack of resources and rate limiting: assenza di limiti nell’accesso a funzioni o risorse;
  5. Broken function level authorization: l’attaccante riesce ad utilizzare funzionalità amministrative e funzioni altrimenti riservate;
  6. Mass assignement: un attaccante manipola gli oggetti in input per sfruttare business logic vulnerabili e ottenere diritti che altrimenti non avrebbe;
  7. Security misconfiguration: errate configurazioni consentono ad un attaccante accessi o funzioni non autorizzate;
  8. Injection: un attaccante degli input per sfruttare vulnerabilità di SQL, NoSQL, LDAP injection;
  9. Improper assets management: l’attaccante sfrutta degli asset non documentati o non aggiornati, ma pubblici, per ottenere informazioni o compromettere un sistema;
  10. Insufficient logging and monitoring: insufficienza di log o di monitoraggio consentono ad un attaccante di operare senza essere rilevato o rilevato in ritardo.

La classificazione OWASP non è certo l’unico strumento, ma è sicuramente un ottimo punto di partenza per comprendere le possibili vulnerabilità e costruire una strategia di messa in sicurezza delle API che, nel loro ciclo di vita, deve essere necessariamente strutturata, organizzata e condivisa secondo un principio di “Security by Design” coinvolgendo a 360° i team degli API designer, degli sviluppatori, dei DevSecOps, delle operations e tutti gli addetti alla sicurezza IT.

Abbiamo parlato di questo argomento e di come difendere le API nell’edizione 2021 di Headless & API date (25 novembre): guarda la registrazione per saperne di più.

Guarda la registrazione dell'evento

No Article rating
0 Reviews
Cosa ne pensi dell'articolo?
  1. Amazing
  2. Good
  3. Bad
  4. Meh
  5. Pff
Denis Signoretto
IT Architect & Senior Project Manager

Esperto da oltre 20 anni di soluzioni software open source e sviluppatore certificato Liferay, Denis in Intesys è specializzato di API Design per lo sviluppo di architetture Headless.

NEWSLETTER