API Security: Le Best Practice per Proteggere le Tue API nel 2026

Le API sono il sistema nervoso delle applicazioni moderne. Sono anche il vettore d'attacco preferito dagli attaccanti: OWASP dedica una Top 10 specifica alle vulnerabilità delle API perché il panorama delle minacce è sufficientemente unico da meritare trattazione separata.

Il panorama delle minacce API

Le API presentano sfide di sicurezza specifiche:

Superficie d'attacco ampia — un'applicazione moderna può esporre centinaia o migliaia di endpoint API, ognuno potenzialmente vulnerabile.

Autenticazione e autorizzazione complesse — le API spesso servono multiple tipologie di client (web, mobile, terze parti) con requisiti diversi.

Esposizione di dati — le API restituiscono dati strutturati facilmente analizzabili da tool automatici.

Microservizi — le architetture a microservizi moltiplicano il numero di API interne, ognuna con la propria superficie d'attacco.

Le vulnerabilità principali (OWASP API Top 10)

API1: Broken Object Level Authorization (BOLA)

La vulnerabilità più comune. L'API accetta richieste con ID di oggetti senza verificare che l'utente sia autorizzato ad accedere a quell'oggetto specifico.

GET /api/v1/users/12345/invoices  ← accede alle fatture dell'utente 12345
GET /api/v1/users/12346/invoices  ← cambiando ID, accede alle fatture di un altro utente

Difesa: Verifica server-side sempre che l'utente autenticato sia il proprietario dell'oggetto richiesto.

API2: Broken Authentication

Token API deboli, sessioni che non scadono, meccanismi di reset password insicuri.

Difesa: Usa OAuth 2.0 con scadenze brevi, implementa refresh token rotation, invalida i token al logout.

API3: Broken Object Property Level Authorization

L'API permette all'utente di modificare proprietà che non dovrebbe poter modificare (es. il proprio ruolo, credenziali di altri utenti).

Difesa: Definisci esplicitamente quali campi ogni ruolo può leggere e modificare. Non usare mass assignment senza whitelist.

API4: Unrestricted Resource Consumption

Assenza di rate limiting su endpoint costosi: il server viene sovraccaricato da richieste massicce.

Difesa: Rate limiting per IP, per utente, per endpoint. Limiti sul payload size. Timeout sulle query al database.

API5: Broken Function Level Authorization

Endpoint con funzionalità amministrative o privilegiate non adeguatamente protetti.

Difesa: Tutti gli endpoint admin devono verificare esplicitamente il ruolo admin, non solo il login.

Le best practice fondamentali

Autenticazione robusta

OAuth 2.0 + OpenID Connect è lo standard per le API pubbliche. Per API interne, considera mTLS (mutual TLS) o API key con rotazione automatica.

JWT: se usi JWT, usa RS256 o ES256 (non HS256 con chiave condivisa), imposta exp (expiration) breve, valida tutti i claim rilevanti.

API Key: hashale nel database (come le password), imposta scadenze, permetti revoca immediata.

Autorizzazione granulare

Non basta verificare che l'utente sia autenticato. Per ogni richiesta:

1. Chi è l'utente? (autenticazione)
2. Ha il permesso di fare questa azione? (function level authorization)
3. Ha il permesso di accedere a questo oggetto specifico? (object level authorization)

Tutti e tre i livelli devono essere verificati indipendentemente.

Input validation

Valida tutto — tipo, formato, lunghezza, range. Non fidarti mai dell'input del client.

Schema validation — usa JSON Schema o OpenAPI schema validation per validare automaticamente tutti i payload in ingresso.

Sanitization — non è sufficiente per la sicurezza, ma complementa la validation.

Output limiting

Non restituire più dati del necessario. Se l'utente chiede il nome di un utente, non restituire anche password hash, token interni, dati sensibili.

Paginazione — limita il numero di record per risposta. Senza paginazione, un endpoint lista può restituire milioni di record.

Rate limiting e throttling

Implementa rate limiting a più livelli:

• Per IP — protezione da attacchi di forza bruta e scraping
• Per utente — equità nell'uso delle risorse
• Per endpoint — endpoint costosi hanno limiti più bassi

Usa gli header standard:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640995200
Retry-After: 60

HTTPS ovunque

Nessuna eccezione. Anche le API interne dovrebbero usare TLS. Un attaccante con accesso alla rete interna può intercettare traffico HTTP non cifrato.

Logging e monitoring

Loga ogni richiesta API con: timestamp, IP, utente, endpoint, parametri (senza dati sensibili), status code, tempo di risposta.

Imposta alert su: picchi di 4xx, accessi a endpoint sensibili fuori orario, pattern anomali di accesso agli oggetti.

La sicurezza delle API non è un problema da risolvere una volta: è un processo continuo di verifica, monitoring e aggiornamento. Testa regolarmente le tue API con tool specializzati e rimani aggiornato sulle nuove tecniche di attacco.