Le API sono il tessuto connettivo delle applicazioni moderne — e il bersaglio preferito degli attaccanti. La classifica OWASP API Security Top 10 identifica le vulnerabilità più critiche e diffuse. Vediamo ciascuna con esempi concreti e contromisure.
API1: Broken Object Level Authorization (BOLA)
La vulnerabilità API più diffusa. L'attaccante modifica l'ID di un oggetto nella richiesta per accedere ai dati di un altro utente.
Esempio vulnerabile:
GET /api/utenti/123/ordini
// L'attaccante cambia 123 con 456 e vede gli ordini di un altro utente
Contromisure:
- Verificare l'autorizzazione a livello di oggetto in ogni endpoint
- Non basarsi solo sull'autenticazione — autenticato ≠ autorizzato
- Usare ID non prevedibili (UUID invece di numeri sequenziali)
// Verifica BOLA corretta
async function getOrdini(userId: string, requestUserId: string) {
if (userId !== requestUserId && !isAdmin(requestUserId)) {
throw new ForbiddenError('Non autorizzato')
}
return db.ordini.findMany({ where: { userId } })
}
API2: Broken Authentication
Meccanismi di autenticazione implementati in modo errato che permettono all'attaccante di impersonare altri utenti.
Vulnerabilità comuni:
- Token JWT senza verifica della firma
- Token senza scadenza
- Credenziali trasmesse in chiaro
- Assenza di rate limiting sul login
Contromisure:
- Validare sempre la firma del JWT con una chiave segreta robusta
- Impostare scadenze brevi sui token (15-30 minuti)
- Implementare rate limiting sugli endpoint di autenticazione
- Usare HTTPS obbligatorio
API3: Broken Object Property Level Authorization
L'API espone proprietà degli oggetti che l'utente non dovrebbe vedere o modificare.
Esempio:
// Risposta API che espone dati sensibili
{
"id": "user-123",
"nome": "Mario Rossi",
"email": "[email protected]",
"ruolo": "user",
"hashPassword": "$2b$10...", // MAI esporre
"saldoConto": 15000 // Non necessario per questa vista
}
Contromisure:
- Definire DTO (Data Transfer Objects) specifici per ogni risposta
- Non esporre mai il modello del database direttamente
- Validare anche le proprietà nei payload di aggiornamento
API4: Unrestricted Resource Consumption
L'API non limita le risorse consumabili, permettendo attacchi DoS o costi eccessivi.
Contromisure:
- Rate limiting per IP e per utente
- Limiti sulla dimensione del payload
- Paginazione obbligatoria sulle liste
- Timeout sulle operazioni pesanti
- Limiti sul numero di record restituiti
// Rate limiting con sliding window
const limiter = rateLimit({
windowMs: 60 * 1000, // 1 minuto
max: 100, // 100 richieste per finestra
standardHeaders: true,
legacyHeaders: false,
})
API5: Broken Function Level Authorization
L'attaccante accede a funzioni amministrative cambiando il percorso dell'endpoint.
Esempio:
GET /api/utenti → OK (utente normale)
DELETE /api/utenti/123 → Dovrebbe essere bloccato ma non lo è
POST /api/admin/utenti → Accesso admin non verificato
Contromisure:
- Verificare i permessi per ogni endpoint, non solo per il tipo di risorsa
- Separare chiaramente gli endpoint admin dagli endpoint utente
- Implementare RBAC (Role-Based Access Control) centralizzato
API6: Unrestricted Access to Sensitive Business Flows
L'API non protegge i flussi di business da abusi automatizzati (bot che comprano tutto lo stock, scraping massivo).
Contromisure:
- CAPTCHA o proof-of-work sui flussi critici
- Rate limiting specifico per i flussi di business
- Monitoraggio dei pattern anomali
- Device fingerprinting
API7: Server Side Request Forgery (SSRF)
L'API accetta URL forniti dall'utente e li richiede lato server, permettendo all'attaccante di raggiungere risorse interne.
Esempio vulnerabile:
POST /api/fetch-preview
{ "url": "http://169.254.169.254/latest/meta-data/" }
// Accede ai metadati dell'istanza cloud!
Contromisure:
- Validare e sanitizzare tutti gli URL ricevuti
- Bloccare gli indirizzi IP privati e i metadati cloud
- Usare una whitelist di domini autorizzati
- Isolare le richieste esterne in un ambiente sandboxed
API8: Security Misconfiguration
Configurazioni di sicurezza mancanti o errate.
Checklist:
- [ ] CORS configurato con origini specifiche (non
*) - [ ] Header di sicurezza HTTP impostati
- [ ] Messaggi di errore generici (non stack trace in produzione)
- [ ] Metodi HTTP non necessari disabilitati
- [ ] TLS 1.2+ obbligatorio
- [ ] Endpoint di debug disabilitati in produzione
API9: Improper Inventory Management
API non documentate, versioni obsolete ancora attive, endpoint shadow.
Contromisure:
- Inventario completo di tutte le API esposte
- Dismissione delle versioni obsolete
- Documentazione OpenAPI/Swagger aggiornata
- Monitoraggio degli endpoint non documentati
API10: Unsafe Consumption of APIs
L'API si fida dei dati ricevuti da servizi terzi senza validarli.
Contromisure:
- Validare tutti gli input, anche quelli provenienti da API "fidate"
- Usare Zod o schema JSON per la validazione
- Implementare circuit breaker per le dipendenze esterne
- Non propagare gli errori delle API terze all'utente finale
Checklist rapida di sicurezza API
| Controllo | Priorità | |-----------|----------| | Autorizzazione a livello di oggetto (BOLA) | Critica | | Rate limiting su tutti gli endpoint | Alta | | Validazione input con schema (Zod) | Alta | | Token JWT con firma e scadenza | Alta | | CORS configurato correttamente | Alta | | Header di sicurezza HTTP | Media | | Logging delle richieste sospette | Media | | Documentazione API aggiornata | Media | | Test di penetrazione periodici | Media | | Monitoraggio degli abusi | Media |
Conclusione
La sicurezza delle API non è un'opzione — è il fondamento di qualsiasi applicazione moderna. Le 10 vulnerabilità OWASP coprono la stragrande maggioranza degli attacchi reali. Iniziate da BOLA e autenticazione — sono le più critiche e le più diffuse.
Scansiona il tuo sito web gratis con WarDek — OWASP, NIS2, GDPR, AI Act in un'unica scansione.