Oggi praticamente qualsiasi applicazione moderna utilizza delle API.
Un sito web può avere un frontend pubblico e, dietro le quinte, comunicare con diversi endpoint:
https://api.example.com/users
https://api.example.com/products
https://api.example.com/orders
Le API possono gestire autenticazione, pagamenti, dati degli utenti, configurazioni e praticamente qualsiasi altra funzione dell'applicazione.
Per questo rappresentano una parte importante della superficie di attacco.
E spesso sono meno visibili della normale interfaccia web.
Cosa significa "API esposta"?
Un'API è esposta quando uno o più dei suoi endpoint sono raggiungibili attraverso una rete accessibile al client, ad esempio Internet.
Per esempio:
https://api.example.com/v1/products
può essere perfettamente normale.
Un'API pubblica non è necessariamente un'API vulnerabile.
Il problema è capire cosa espone, a chi e con quali controlli.
API pubblica non significa dati pubblici
Questa distinzione è fondamentale.
Un'API può essere raggiungibile da Internet ma richiedere autenticazione:
GET /api/orders
Authorization: Bearer ...
In questo caso l'endpoint è pubblico dal punto di vista della rete, ma l'accesso ai dati può essere limitato.
Al contrario, un endpoint accessibile senza autenticazione potrebbe restituire dati che non dovrebbero essere pubblici.
La domanda quindi non è:
"L'API è online?"
ma:
"Quali operazioni e quali dati sono accessibili attraverso quell'API?"
Dove si trovano le API?
Non sempre sono disponibili su un dominio separato.
Potrebbero trovarsi su:
api.example.com
ma anche:
example.com/api/
example.com/api/v1/
example.com/rest/
example.com/graphql
oppure su sottodomini differenti:
mobile.example.com
backend.example.com
services.example.com
Per questo la discovery della superficie web dovrebbe considerare anche le API.
Le versioni sono importanti
Un'applicazione potrebbe utilizzare:
/api/v1/
e successivamente introdurre:
/api/v2/
Il problema nasce quando la vecchia versione continua a essere pubblicamente disponibile senza una reale necessità.
Potremmo quindi avere:
v1 → vecchia
v2 → attuale
ma entrambe accessibili.
Una vecchia API può avere:
- controlli di sicurezza differenti;
- funzionalità non più utilizzate;
- dipendenze obsolete;
- endpoint dimenticati;
- documentazione non aggiornata.
OWASP identifica proprio la gestione inadeguata dell'inventario delle API come uno dei principali rischi specifici delle API.
API di staging e test
Un altro caso comune è:
api.example.com
api-staging.example.com
api-test.example.com
L'ambiente di produzione può essere configurato correttamente mentre quello di test viene lasciato online con impostazioni più permissive.
Ad esempio:
Produzione
✓ autenticazione
✓ logging
✓ rate limiting
Staging
? autenticazione
? dati reali
? rate limiting
Il fatto che un ambiente sia chiamato "staging" non significa che sia irrilevante.
Se è raggiungibile da Internet, fa parte della superficie pubblica e dovrebbe essere gestito di conseguenza.
Cosa controllare in un'API?
Un controllo iniziale dovrebbe considerare almeno:
Autenticazione
Gli endpoint che gestiscono dati riservati richiedono autenticazione?
Autorizzazione
Un utente autenticato può accedere soltanto alle risorse che gli appartengono?
Questo è particolarmente importante per endpoint come:
/api/users/123
/api/orders/456
/api/documents/789
OWASP classifica i problemi di autorizzazione a livello di oggetto come API1:2023 Broken Object Level Authorization, proprio perché un endpoint può essere accessibile all'utente ma non necessariamente tutti gli oggetti identificati attraverso i parametri della richiesta.
Metodi HTTP
Quali operazioni sono disponibili?
GET
POST
PUT
PATCH
DELETE
E soprattutto: quali ruoli possono eseguirle?
Rate limiting
Un'API dovrebbe considerare anche quanto rapidamente un client può effettuare determinate operazioni.
Questo è particolarmente importante per login, ricerca, invio di codici, operazioni costose e flussi che possono generare costi.
OWASP include infatti il consumo illimitato di risorse tra i rischi principali delle API.
Errori
Le risposte API non dovrebbero rivelare inutilmente:
stack trace
percorsi locali
query SQL
nomi di file
variabili interne
informazioni sull'infrastruttura
Un errore:
{
"error": "Internal Server Error"
}
può essere molto più appropriato, in produzione, di una risposta contenente dettagli interni dell'applicazione.
Come si presenta una API ben documentata?
Un'API dovrebbe avere un inventario aggiornato degli endpoint, delle versioni e dei relativi requisiti di accesso.
Per esempio:
API
├── /v1/products
│ └── GET
├── /v1/orders
│ ├── GET
│ └── POST
└── /v1/users
├── GET
└── PATCH
Per ogni endpoint è utile sapere:
- cosa fa;
- quali parametri accetta;
- quale autenticazione richiede;
- quali ruoli possono utilizzarlo;
- quali dati restituisce;
- quali errori può produrre;
- se è ancora necessario.
Una checklist pratica
Per un primo controllo:
- [ ] conosco tutti gli host API;
- [ ] conosco tutte le versioni pubblicate;
- [ ] ho individuato eventuali API di staging e test;
- [ ] gli endpoint sensibili richiedono autenticazione;
- [ ] l'autorizzazione viene verificata a livello di risorsa;
- [ ] i dati restituiti sono realmente necessari;
- [ ] i metodi HTTP sono appropriati;
- [ ] esistono controlli sul consumo delle risorse;
- [ ] gli errori non rivelano informazioni interne;
- [ ] le API obsolete vengono ritirate.
L'importanza dell'inventario
Una delle difficoltà principali della sicurezza API è sapere quali API esistono realmente.
Nel tempo possono comparire:
v1
v2
v3
staging
test
mobile
legacy
internal
e non tutte vengono necessariamente rimosse quando non servono più.
Questo crea una superficie difficile da gestire.
Per questo la sicurezza API non comincia necessariamente dal penetration test.
Comincia spesso da una domanda molto più semplice:
"Quante API abbiamo realmente esposte?"
MiHakero e le API
Le API sono una parte fondamentale della superficie che un servizio di sicurezza esterno dovrebbe riuscire a osservare.
Individuare un endpoint non significa aver trovato una vulnerabilità.
Significa aver trovato qualcosa che deve essere compreso.
L'obiettivo è passare da:
api.example.com
a una visione più utile:
API
├── endpoint
├── versione
├── autenticazione
├── configurazione
├── dati esposti
└── rischi da verificare
Perché un'API sicura non è semplicemente un'API che risponde.
È un'API di cui conosciamo cosa espone, a chi e perché.