OWASP API Security Top 10 — Guida 2025

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

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.