API security: 10 best practice per il 2021

Le API REST sono ormai il sistema nervoso del software moderno: collegano frontend e backend, app mobile e gestionali, microservizi, integrazioni con fornitori, sistemi di pagamento, CRM, ERP. Ogni volta che un’app comunica con un server, dietro le quinte c’e’ una API. E ogni API esposta su Internet e’ una potenziale porta di ingresso per attaccanti.

Nel 2021 la superficie di attacco e’ esplosa: secondo Gartner, entro il 2022 le API saranno il vettore di attacco piu’ frequente per le applicazioni web. Eppure, molte aziende italiane sviluppano API senza un approccio strutturato alla sicurezza, affidandosi a “ho messo HTTPS” come unica misura difensiva. Non basta.

In questa guida vedremo le 10 best practice di API security che ogni team di sviluppo dovrebbe applicare nel 2021: dall’autenticazione (OAuth2, JWT, mTLS) al rate limiting, dalla validazione input alla configurazione di un API Gateway, fino al monitoring continuo. Niente teoria astratta: solo pratiche concrete, riferimenti agli standard ufficiali (OWASP, IETF) e indicazioni operative.

Il target di questa guida sono CTO, IT manager, developer senior e security engineer che lavorano in PMI o software house italiane: chi deve progettare, sviluppare o auditare API REST in produzione. Per chi parte da zero suggeriamo di leggere prima la nostra introduzione alle API REST, poi tornare qui per capire come metterle in sicurezza.

1. API security: il rischio crescente nel 2021

Il 2020 e il 2021 hanno visto un’accelerazione brutale del processo di trasformazione digitale: smart working, e-commerce, app mobile, integrazioni cloud. Tutto questo si traduce in piu’ API esposte, spesso sviluppate in fretta, senza tempo per audit di sicurezza.

Le statistiche del 2021 sono impietose:

• +681% di attacchi alle API tra dicembre 2020 e giugno 2021 (Salt Security State of API Security Q3 2021)
• 91% delle organizzazioni ha avuto almeno un incidente di sicurezza legato alle API negli ultimi 12 mesi
• Costo medio di un data breach via API: oltre 4 milioni di dollari (IBM Cost of a Data Breach Report 2021)

I casi piu’ clamorosi del 2020-2021 — Peloton, Experian, LinkedIn, Facebook scraping da 533 milioni di account — hanno tutti una matrice comune: API mal protette o configurate male. Endpoint che restituivano dati personali senza autenticazione, mancanza di rate limiting, controlli di autorizzazione lato client invece che lato server.

Il messaggio per chi sviluppa software e per chi commissiona integrazione API e’ chiaro: la sicurezza non si aggiunge alla fine, si progetta dall’inizio (security by design).

2. OWASP API Security Top 10 2019 (riferimento attuale 2021)

Il punto di partenza obbligato e’ la OWASP API Security Top 10, pubblicata nel 2019 e ancora il riferimento attuale nel 2021. Elenca le 10 vulnerabilita’ piu’ frequenti nelle API:

1. API1 – Broken Object Level Authorization (BOLA): l’API non verifica che l’utente abbia il diritto di accedere a uno specifico oggetto (es. /api/users/123/orders accessibile cambiando l’ID).
2. API2 – Broken User Authentication: meccanismi di autenticazione mal implementati, token che non scadono, password deboli, brute force possibile.
3. API3 – Excessive Data Exposure: l’API restituisce piu’ dati del necessario, lasciando al frontend il compito di filtrarli (errore: il frontend e’ ispezionabile).
4. API4 – Lack of Resources & Rate Limiting: nessun limite sul numero di richieste, vulnerabile a DoS e brute force.
5. API5 – Broken Function Level Authorization: utenti normali possono chiamare endpoint admin manipolando URL o metodi HTTP.
6. API6 – Mass Assignment: l’API accetta tutti i campi del JSON in input, permettendo a un attaccante di settare campi non previsti (es. "role": "admin").
7. API7 – Security Misconfiguration: header HTTP mancanti, CORS troppo permissivo, messaggi di errore verbosi che espongono stack trace.
8. API8 – Injection: SQL injection, NoSQL injection, command injection — sempre attuali anche sulle API.
9. API9 – Improper Assets Management: vecchie versioni di API ancora online, ambienti di test esposti, documentazione obsoleta.
10. API10 – Insufficient Logging & Monitoring: senza log strutturati e alert, gli attacchi passano inosservati per mesi.

Stampatela e appendetela in ufficio. Letteralmente. Ogni nuova feature andrebbe valutata contro questa lista, e ogni audit di sicurezza dovrebbe ripartire da qui.

Una nota importante sull’API1 (BOLA): e’ la vulnerabilita’ piu’ frequente nelle API REST italiane che abbiamo audited. Si manifesta tipicamente cosi’: il developer assume che il frontend mostri solo gli ID di oggetti dell’utente loggato, e quindi non valida lato server che order_id=42 appartenga davvero a chi sta facendo la richiesta. Un attaccante autenticato puo’ enumerare ID e leggere ordini di altri utenti. La fix e’: ogni get/update/delete su una risorsa identificata da ID deve includere un controllo di ownership lato server. Senza eccezioni.

L’API3 (Excessive Data Exposure) e’ un altro classico: l’API restituisce l’intero record DB (compresi password_hash, two_fa_secret, internal_notes) e si confida nel frontend per mostrare solo i campi giusti. Errore. Definite DTO espliciti per ogni endpoint, con whitelist dei campi esposti. Frameworks come Laravel API Resources, Spring Boot DTO, FastAPI Pydantic models semplificano il pattern.

3. Autenticazione: API key, OAuth2, JWT, mTLS

La prima domanda e’: chi sta chiamando questa API? Esistono diverse strategie, ognuna adatta a scenari diversi.

API Key

Una stringa segreta passata in header (X-API-Key) o query string. Semplice, ma poco granulare: identifica un’app, non un utente. Adatta per integrazioni server-to-server interne, sconsigliata per app pubbliche.

OAuth 2.0

Lo standard de facto per autenticazione delegata: l’utente autorizza un’app a chiamare l’API per suo conto, senza condividere la password. Vedi paragrafo dedicato.

JWT (JSON Web Token)

Token firmato che contiene claim sull’utente. Stateless, scalabile. Spesso usato come access token in OAuth2. Vedi paragrafo dedicato.

mTLS (Mutual TLS)

Sia client che server presentano un certificato. Massima sicurezza, usato in scenari B2B e finanziari (PSD2, Open Banking). Complesso da gestire ma blindato.

Per la maggior parte dei progetti web e mobile, la combinazione vincente nel 2021 e’ OAuth 2.0 + JWT come access token + refresh token, con eventuale mTLS per le integrazioni server-to-server piu’ sensibili.

4. OAuth 2.0: come funziona davvero

OAuth 2.0 (RFC 6749) non e’ un protocollo di autenticazione ma di autorizzazione delegata. Per autenticazione vera, si usa OpenID Connect, costruito sopra OAuth2.

I quattro attori:

• Resource Owner: l’utente
• Client: l’app che vuole accedere
• Authorization Server: chi emette i token (es. Auth0, Keycloak, AWS Cognito, Azure AD)
• Resource Server: l’API protetta

I flussi piu’ comuni nel 2021:

• Authorization Code + PKCE: per app web e mobile pubbliche. Lo standard raccomandato dall’IETF (BCP) dal 2019.
• Client Credentials: per integrazioni server-to-server senza utente.
• Refresh Token: per rinnovare access token senza chiedere di nuovo le credenziali.

Il flusso Implicit Grant e Resource Owner Password Credentials sono deprecati nel 2021 (vedi OAuth 2.0 Security Best Current Practice). Se li trovate in un progetto, e’ tempo di migrare.

PKCE (Proof Key for Code Exchange) merita una menzione specifica. Nato per le mobile app, oggi si raccomanda anche per le SPA: il client genera un code_verifier casuale, ne calcola lo SHA-256 (code_challenge) e lo invia all’authorization endpoint. Quando scambia il code per il token, presenta il verifier originale. Il server verifica che l’hash corrisponda. Questo blinda il flusso contro l’intercettazione del code sul redirect URI.

Sugli scope: definite scope granulari (orders:read, orders:write, users:admin) e rispettate il principio del minimo privilegio. Una mobile app che mostra il riepilogo ordini non ha bisogno dello scope users:admin. Meno scope concedete, meno danni un token rubato puo’ fare.

5. JWT (JSON Web Token): pro e contro

Un JWT (RFC 7519) e’ una stringa Base64 a tre parti: header.payload.signature. La firma garantisce che il payload non sia stato modificato.

Pro:

• Stateless: il server non deve mantenere sessioni in memoria/DB
• Scalabile orizzontalmente: ogni server puo’ validare il token autonomamente
• Trasporta claim utili (user ID, ruoli, scadenza)

Contro e trappole comuni:

• Revoca difficile: un JWT valido fino a scadenza non si puo’ revocare facilmente. Soluzioni: TTL brevi (15 minuti) + refresh token, blacklist dei JTI revocati.
• Algoritmo “none”: vulnerabilita’ classica. Usate sempre RS256 o ES256, mai none.
• Algorithm confusion: alcune librerie permettono di passare la chiave pubblica come HMAC secret. Pinnare l’algoritmo nel verifier.
• Storage lato client: localStorage e’ vulnerabile a XSS. Preferite cookie httpOnly + SameSite=Strict.
• Payload sensibili: il payload e’ Base64, non cifrato. Non metteteci password, dati medici, IBAN.

6. Rate limiting e throttling

Senza limiti sul numero di richieste, una singola API esposta diventa una bomba a orologeria: brute force su login, scraping di dati, DoS, costi cloud fuori controllo.

Strategie nel 2021:

• Token bucket: ogni client ha un secchio di token che si riempie a ritmo costante. Consente burst controllati.
• Leaky bucket: richieste in coda, processate a velocita’ fissa.
• Fixed window: max N richieste per finestra temporale (es. 1.000/h).
• Sliding window: piu’ equo, evita il problema dell’edge della finestra fissa.

Limiti tipici:

• API pubbliche non autenticate: 60-100 req/min per IP
• API autenticate per utente: 1.000-10.000 req/h
• API enterprise: limiti per piano commerciale

Header standard di risposta (RFC draft IETF):

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 423
X-RateLimit-Reset: 1623504000
Retry-After: 60

Strumenti consigliati: Redis con algoritmo sliding window, oppure direttamente l’API Gateway (vedi paragrafo dedicato). Redis offre primitive atomiche (INCR, EXPIRE) ideali per implementare token bucket distribuiti su piu’ istanze applicative.

Una distinzione utile: rate limiting e’ un limite hard (oltre la soglia, 429 Too Many Requests), throttling e’ un rallentamento progressivo (le richieste in eccesso vengono accodate o servite con latenza maggiore). Entrambi hanno il loro posto: il rate limiting protegge backend e database, il throttling smussa picchi di traffico legittimi senza errori visibili al client.

Considerate anche limiti differenziati per endpoint: l’endpoint /login dovrebbe avere un limite molto piu’ stretto (5 tentativi falliti ogni 15 minuti per username + IP) rispetto a un GET di lettura. Lo stesso vale per endpoint di reset password, registrazione, contact form.

7. HTTPS/TLS obbligatorio

Nel 2021 non c’e’ piu’ alcuna scusa per esporre API in HTTP. Anche le API “interne” o “di test” devono usare TLS:

• TLS 1.3 (RFC 8446, 2018) e’ lo standard attuale: handshake piu’ rapido, cifrari moderni, forward secrecy.
• TLS 1.2 ancora accettabile con cipher suite forti (no RC4, no 3DES).
• SSL 3.0, TLS 1.0 e 1.1: deprecati ufficialmente nel 2020 (RFC 8996). Disabilitateli sul server.

Header di sicurezza obbligatori:

• Strict-Transport-Security: max-age=31536000; includeSubDomains (HSTS)
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Content-Security-Policy (per chi serve anche HTML)

Per i certificati: Let’s Encrypt con auto-renewal e’ gratuito e affidabile. Per scenari piu’ critici, certificati EV con OCSP stapling.

8. Validazione input e protezione da injection

L’input dell’utente non e’ mai fidato. Mai. Anche se viene da una vostra app, anche se viene da un partner. Tutto va validato lato server.

Pattern di validazione:

• Schema validation: usate JSON Schema, OpenAPI/Swagger validators, Joi (Node.js), Pydantic (Python), Bean Validation (Java). Rifiutate richieste che non rispettano lo schema.
• Whitelist, non blacklist: definite cosa e’ permesso, non cosa e’ vietato.
• Type, range, format: un ID deve essere un intero positivo, una mail deve matchare il regex, un IBAN deve avere 27 caratteri.
• Limiti di dimensione: max 1MB per payload JSON, max 100 elementi per array. Evita zip bomb e memory exhaustion.

Per le injection:

• SQL: query parametrizzate / prepared statement. Mai concatenazione di stringhe.
• NoSQL (MongoDB, etc.): attenzione a oggetti annidati come {"$ne": null} nei filtri. Cast esplicito a stringa.
• Command injection: mai passare input utente a exec() o shell senza escape.
• SSRF: se l’API fa chiamate HTTP basate su input utente, validate l’URL e bloccate range privati (10.x, 172.16-31.x, 192.168.x, 169.254.x).

9. CORS configuration

Cross-Origin Resource Sharing (CORS) e’ uno dei temi piu’ fraintesi. Non e’ una protezione: e’ un meccanismo che permette al browser di rilassare la same-origin policy. Configurato male, apre la porta agli attacchi.

Errori comuni:

• Access-Control-Allow-Origin: * + Allow-Credentials: true: combinazione pericolosa, accetta richieste da qualsiasi sito con i cookie dell’utente.
• Reflection dell’origin: Allow-Origin: <qualsiasi origin la richiesta presenti> senza validazione. Equivale al wildcard.
• Whitelist troppo lunga: meglio una lista corta e curata che un regex permissivo.

Configurazione corretta:

Access-Control-Allow-Origin: https://app.brentasoft.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

Una sola origin per volta, validata server-side contro una whitelist hardcoded.

10. API Gateway: il guardiano centrale

Un API Gateway e’ il “buttafuori” davanti alle vostre API: gestisce autenticazione, rate limiting, logging, caching, trasformazione, routing — in modo centralizzato. Nel 2021 e’ praticamente obbligatorio per chi gestisce piu’ di una manciata di API.

Le opzioni piu’ usate nel 2021:

• Kong (open source + enterprise): basato su Nginx + Lua, ricco ecosistema di plugin, ottimo on-premise e Kubernetes.
• Tyk: open source, scritto in Go, dashboard pulita, buon rapporto qualita’-prezzo.
• AWS API Gateway: serverless, integrazione nativa con Lambda, IAM, Cognito. Ottimo se siete gia’ in AWS.
• Google Apigee: enterprise di fascia alta, analytics avanzati, monetization. Costoso.
• Azure API Management: la scelta naturale in stack Microsoft, integrazione con AAD.
• NGINX Plus: per chi vuole leggerezza e controllo a basso livello.

Cosa demanda al Gateway:

• Autenticazione (validazione JWT, API key, OAuth2 introspection)
• Rate limiting e quota per consumer
• Routing e versioning (/v1/ vs /v2/)
• Caching delle risposte GET
• Logging strutturato e metriche
• Trasformazione richieste/risposte (es. legacy SOAP -> REST)
• Circuit breaker e retry verso i backend

Il Gateway non sostituisce i controlli a livello applicativo: e’ la prima linea, non l’unica. La regola d’oro: defense in depth. Anche se il Gateway valida il JWT, l’applicazione deve ricontrollare scope, ownership e autorizzazione di funzione. Non confidate nel singolo punto di controllo.

Pattern di deployment tipico nel 2021: Cloudflare in front (DDoS, WAF, CDN), API Gateway al perimetro applicativo (Kong/Tyk/AWS), microservizi backend dietro service mesh (Istio, Linkerd) per il traffico est-ovest. Ogni livello aggiunge una rete di sicurezza, isolando i guasti e fornendo metriche.

11. Monitoring e logging

L’API10 OWASP — Insufficient Logging & Monitoring — e’ la piu’ sottovalutata. Senza log strutturati e alerting, un attacco puo’ durare mesi prima di essere scoperto.

Cosa loggare per ogni richiesta:

• Timestamp ISO 8601 con timezone
• Method, path, status code, latenza
• IP client e User-Agent
• User ID (se autenticato), API key ID
• Trace ID / correlation ID (per tracciare richieste tra microservizi)
• Eventi di sicurezza: login fallito, 401, 403, 429, errori di validazione

Cosa non loggare:

• Password, token, JWT, API key
• Numeri di carta, CVV
• Body completi con dati sanitari/personali (a meno di mascheratura)

Stack tipico 2021: ELK (Elasticsearch + Logstash + Kibana) oppure Loki + Grafana, Prometheus per metriche, Sentry per gli errori applicativi, Grafana per dashboard. Per scenari managed: Datadog, New Relic, AWS CloudWatch.

Alert da configurare subito:

• Spike di 401/403 (possibile attacco brute force)
• Spike di 5xx (problemi infrastrutturali)
• Latency p95/p99 oltre soglia
• Traffico anomalo da singolo IP o user
• Geolocalizzazione sospetta (login dall’Italia, poi 5 minuti dopo dalla Russia)

12. Domande frequenti

Quali sono le best practice di API security piu’ importanti nel 2021?

Le tre fondamentali: autenticazione robusta (OAuth2 + JWT con scadenza breve), rate limiting su tutti gli endpoint, validazione rigorosa dell’input lato server. Aggiungete HTTPS obbligatorio (TLS 1.2+) e logging strutturato per avere una baseline solida.

Qual e’ la differenza tra OAuth2 e JWT?

OAuth 2.0 e’ un framework di autorizzazione: definisce come un’app ottiene il permesso di chiamare un’API per conto dell’utente. JWT e’ un formato di token: una stringa firmata che trasporta claim. Spesso OAuth2 emette JWT come access token, ma puo’ anche usare token opachi.

E’ sicuro mettere il JWT in localStorage?

No, e’ vulnerabile a XSS. Preferite cookie con flag HttpOnly, Secure e SameSite=Strict. Se proprio dovete usare localStorage, implementate una solida CSP e tenete TTL brevissimi (5-15 minuti).

Quanto deve durare un access token JWT?

Nel 2021 la best practice e’ 15 minuti per l’access token + refresh token (scadenza 7-30 giorni) ruotato a ogni uso. Token piu’ lunghi rendono difficile la revoca e amplificano l’impatto di un furto.

Mi serve davvero un API Gateway per un progetto piccolo?

Per un singolo microservizio interno con pochi consumer noti, no. Ma appena avete 3-4 API, consumer esterni, esigenze di rate limiting, versioning o analytics, un Gateway (anche open source come Kong o Tyk) ripaga rapidamente l’investimento.

Come proteggere un’API da attacchi DDoS?

Difesa stratificata: Cloudflare/AWS Shield in front, rate limiting sull’API Gateway, autoscaling lato backend, circuit breaker per evitare effetti a catena. Per attacchi applicativi (low & slow), monitorate i pattern e bloccate per fingerprint.

Mi conviene scrivere io l’autenticazione o usare un servizio?

Nel 2021 raramente conviene scrivere da zero un sistema di autenticazione. Auth0, AWS Cognito, Keycloak (open source), Azure AD B2C offrono OAuth2 + OpenID Connect + MFA + flussi social, gia’ battle-tested. Concentrate il vostro tempo sul dominio del business.

Se state pianificando una nuova web app o PWA, dei gestionali personalizzati, o state migrando verso soluzioni cloud, includete API security nel design fin dall’inizio. Per approfondire i fondamentali, leggete la nostra guida non tecnica alle API REST e la nostra guida alla sicurezza informatica per PMI 2021.