{"id":802,"date":"2021-06-12T09:08:00","date_gmt":"2021-06-12T07:08:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/api-security-best-practice-2021\/"},"modified":"2021-06-12T09:08:00","modified_gmt":"2021-06-12T07:08:00","slug":"api-security-best-practice-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/api-security-best-practice-2021\/","title":{"rendered":"API security: 10 best practice per il 2021"},"content":{"rendered":"<p>Le <strong>API REST<\/strong> 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&#8217;app comunica con un server, dietro le quinte c&#8217;e&#8217; una API. E ogni API esposta su Internet e&#8217; una potenziale porta di ingresso per attaccanti.<\/p>\n<p>Nel 2021 la superficie di attacco e&#8217; esplosa: secondo Gartner, entro il 2022 le API saranno il vettore di attacco piu&#8217; frequente per le applicazioni web. Eppure, molte aziende italiane sviluppano API senza un approccio strutturato alla sicurezza, affidandosi a &#8220;ho messo HTTPS&#8221; come unica misura difensiva. Non basta.<\/p>\n<p>In questa guida vedremo le <strong>10 best practice di API security<\/strong> che ogni team di sviluppo dovrebbe applicare nel 2021: dall&#8217;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.<\/p>\n<p>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.<\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" width=\"1880\" height=\"1253\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-token-jwt-codice.jpg\" alt=\"JWT token autenticazione API codice sviluppatore\" class=\"wp-image-804\" style=\"max-width:100%;height:auto;margin:20px 0;\" srcset=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-token-jwt-codice.jpg 1880w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-token-jwt-codice-300x200.jpg 300w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-token-jwt-codice-1024x682.jpg 1024w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-token-jwt-codice-768x512.jpg 768w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-token-jwt-codice-1536x1024.jpg 1536w\" sizes=\"(max-width: 1880px) 100vw, 1880px\" \/><\/p>\n<h2>1. API security: il rischio crescente nel 2021<\/h2>\n<p>Il 2020 e il 2021 hanno visto un&#8217;accelerazione brutale del processo di trasformazione digitale: smart working, e-commerce, app mobile, integrazioni cloud. Tutto questo si traduce in <strong>piu&#8217; API esposte<\/strong>, spesso sviluppate in fretta, senza tempo per audit di sicurezza.<\/p>\n<p>Le statistiche del 2021 sono impietose:<\/p>\n<ul>\n<li><strong>+681%<\/strong> di attacchi alle API tra dicembre 2020 e giugno 2021 (Salt Security State of API Security Q3 2021)<\/li>\n<li><strong>91%<\/strong> delle organizzazioni ha avuto almeno un incidente di sicurezza legato alle API negli ultimi 12 mesi<\/li>\n<li><strong>Costo medio<\/strong> di un data breach via API: oltre 4 milioni di dollari (IBM Cost of a Data Breach Report 2021)<\/li>\n<\/ul>\n<p>I casi piu&#8217; clamorosi del 2020-2021 \u2014 Peloton, Experian, LinkedIn, Facebook scraping da 533 milioni di account \u2014 hanno tutti una matrice comune: <strong>API mal protette o configurate male<\/strong>. Endpoint che restituivano dati personali senza autenticazione, mancanza di rate limiting, controlli di autorizzazione lato client invece che lato server.<\/p>\n<p>Il messaggio per chi sviluppa software e per chi commissiona <a href=\"https:\/\/brentasoft.com\/soluzioni\/integrazione-api.php\">integrazione API<\/a> e&#8217; chiaro: la sicurezza non si aggiunge alla fine, si progetta dall&#8217;inizio (security by design).<\/p>\n<h2>2. OWASP API Security Top 10 2019 (riferimento attuale 2021)<\/h2>\n<p>Il punto di partenza obbligato e&#8217; la <a href=\"https:\/\/owasp.org\/www-project-api-security\/\" target=\"_blank\" rel=\"noopener\">OWASP API Security Top 10<\/a>, pubblicata nel 2019 e ancora il riferimento attuale nel 2021. Elenca le 10 vulnerabilita&#8217; piu&#8217; frequenti nelle API:<\/p>\n<ol>\n<li><strong>API1 &#8211; Broken Object Level Authorization (BOLA)<\/strong>: l&#8217;API non verifica che l&#8217;utente abbia il diritto di accedere a uno specifico oggetto (es. <code>\/api\/users\/123\/orders<\/code> accessibile cambiando l&#8217;ID).<\/li>\n<li><strong>API2 &#8211; Broken User Authentication<\/strong>: meccanismi di autenticazione mal implementati, token che non scadono, password deboli, brute force possibile.<\/li>\n<li><strong>API3 &#8211; Excessive Data Exposure<\/strong>: l&#8217;API restituisce piu&#8217; dati del necessario, lasciando al frontend il compito di filtrarli (errore: il frontend e&#8217; ispezionabile).<\/li>\n<li><strong>API4 &#8211; Lack of Resources &amp; Rate Limiting<\/strong>: nessun limite sul numero di richieste, vulnerabile a DoS e brute force.<\/li>\n<li><strong>API5 &#8211; Broken Function Level Authorization<\/strong>: utenti normali possono chiamare endpoint admin manipolando URL o metodi HTTP.<\/li>\n<li><strong>API6 &#8211; Mass Assignment<\/strong>: l&#8217;API accetta tutti i campi del JSON in input, permettendo a un attaccante di settare campi non previsti (es. <code>\"role\": \"admin\"<\/code>).<\/li>\n<li><strong>API7 &#8211; Security Misconfiguration<\/strong>: header HTTP mancanti, CORS troppo permissivo, messaggi di errore verbosi che espongono stack trace.<\/li>\n<li><strong>API8 &#8211; Injection<\/strong>: SQL injection, NoSQL injection, command injection \u2014 sempre attuali anche sulle API.<\/li>\n<li><strong>API9 &#8211; Improper Assets Management<\/strong>: vecchie versioni di API ancora online, ambienti di test esposti, documentazione obsoleta.<\/li>\n<li><strong>API10 &#8211; Insufficient Logging &amp; Monitoring<\/strong>: senza log strutturati e alert, gli attacchi passano inosservati per mesi.<\/li>\n<\/ol>\n<p>Stampatela e appendetela in ufficio. Letteralmente. Ogni nuova feature andrebbe valutata contro questa lista, e ogni audit di sicurezza dovrebbe ripartire da qui.<\/p>\n<p>Una nota importante sull&#8217;API1 (BOLA): e&#8217; la <strong>vulnerabilita&#8217; piu&#8217; frequente<\/strong> nelle API REST italiane che abbiamo audited. Si manifesta tipicamente cosi&#8217;: il developer assume che il frontend mostri solo gli ID di oggetti dell&#8217;utente loggato, e quindi non valida lato server che <code>order_id=42<\/code> appartenga davvero a chi sta facendo la richiesta. Un attaccante autenticato puo&#8217; enumerare ID e leggere ordini di altri utenti. La fix e&#8217;: <strong>ogni get\/update\/delete su una risorsa identificata da ID deve includere un controllo di ownership lato server<\/strong>. Senza eccezioni.<\/p>\n<p>L&#8217;API3 (Excessive Data Exposure) e&#8217; un altro classico: l&#8217;API restituisce l&#8217;intero record DB (compresi <code>password_hash<\/code>, <code>two_fa_secret<\/code>, <code>internal_notes<\/code>) 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.<\/p>\n<h2>3. Autenticazione: API key, OAuth2, JWT, mTLS<\/h2>\n<p>La prima domanda e&#8217;: <strong>chi sta chiamando questa API?<\/strong> Esistono diverse strategie, ognuna adatta a scenari diversi.<\/p>\n<h3>API Key<\/h3>\n<p>Una stringa segreta passata in header (<code>X-API-Key<\/code>) o query string. Semplice, ma poco granulare: identifica un&#8217;app, non un utente. Adatta per integrazioni server-to-server interne, sconsigliata per app pubbliche.<\/p>\n<h3>OAuth 2.0<\/h3>\n<p>Lo standard de facto per autenticazione delegata: l&#8217;utente autorizza un&#8217;app a chiamare l&#8217;API per suo conto, senza condividere la password. Vedi paragrafo dedicato.<\/p>\n<h3>JWT (JSON Web Token)<\/h3>\n<p>Token firmato che contiene claim sull&#8217;utente. Stateless, scalabile. Spesso usato come access token in OAuth2. Vedi paragrafo dedicato.<\/p>\n<h3>mTLS (Mutual TLS)<\/h3>\n<p>Sia client che server presentano un certificato. Massima sicurezza, usato in scenari B2B e finanziari (PSD2, Open Banking). Complesso da gestire ma blindato.<\/p>\n<p>Per la maggior parte dei progetti web e mobile, la combinazione vincente nel 2021 e&#8217; <strong>OAuth 2.0 + JWT come access token + refresh token<\/strong>, con eventuale mTLS per le integrazioni server-to-server piu&#8217; sensibili.<\/p>\n<h2>4. OAuth 2.0: come funziona davvero<\/h2>\n<p>OAuth 2.0 (<a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc6749\" target=\"_blank\" rel=\"noopener\">RFC 6749<\/a>) non e&#8217; un protocollo di autenticazione ma di <strong>autorizzazione delegata<\/strong>. Per autenticazione vera, si usa OpenID Connect, costruito sopra OAuth2.<\/p>\n<p>I quattro attori:<\/p>\n<ul>\n<li><strong>Resource Owner<\/strong>: l&#8217;utente<\/li>\n<li><strong>Client<\/strong>: l&#8217;app che vuole accedere<\/li>\n<li><strong>Authorization Server<\/strong>: chi emette i token (es. Auth0, Keycloak, AWS Cognito, Azure AD)<\/li>\n<li><strong>Resource Server<\/strong>: l&#8217;API protetta<\/li>\n<\/ul>\n<p>I flussi piu&#8217; comuni nel 2021:<\/p>\n<ul>\n<li><strong>Authorization Code + PKCE<\/strong>: per app web e mobile pubbliche. Lo standard raccomandato dall&#8217;IETF (BCP) dal 2019.<\/li>\n<li><strong>Client Credentials<\/strong>: per integrazioni server-to-server senza utente.<\/li>\n<li><strong>Refresh Token<\/strong>: per rinnovare access token senza chiedere di nuovo le credenziali.<\/li>\n<\/ul>\n<p>Il flusso <strong>Implicit Grant<\/strong> e <strong>Resource Owner Password Credentials<\/strong> sono <em>deprecati<\/em> nel 2021 (vedi OAuth 2.0 Security Best Current Practice). Se li trovate in un progetto, e&#8217; tempo di migrare.<\/p>\n<p>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>code_verifier<\/code> casuale, ne calcola lo SHA-256 (<code>code_challenge<\/code>) e lo invia all&#8217;authorization endpoint. Quando scambia il code per il token, presenta il verifier originale. Il server verifica che l&#8217;hash corrisponda. Questo blinda il flusso contro l&#8217;intercettazione del code sul redirect URI.<\/p>\n<p>Sugli <strong>scope<\/strong>: definite scope granulari (<code>orders:read<\/code>, <code>orders:write<\/code>, <code>users:admin<\/code>) e rispettate il principio del minimo privilegio. Una mobile app che mostra il riepilogo ordini non ha bisogno dello scope <code>users:admin<\/code>. Meno scope concedete, meno danni un token rubato puo&#8217; fare.<\/p>\n<h2>5. JWT (JSON Web Token): pro e contro<\/h2>\n<p>Un JWT (<a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc7519\" target=\"_blank\" rel=\"noopener\">RFC 7519<\/a>) e&#8217; una stringa Base64 a tre parti: <code>header.payload.signature<\/code>. La firma garantisce che il payload non sia stato modificato.<\/p>\n<p><strong>Pro<\/strong>:<\/p>\n<ul>\n<li>Stateless: il server non deve mantenere sessioni in memoria\/DB<\/li>\n<li>Scalabile orizzontalmente: ogni server puo&#8217; validare il token autonomamente<\/li>\n<li>Trasporta claim utili (user ID, ruoli, scadenza)<\/li>\n<\/ul>\n<p><strong>Contro e trappole comuni<\/strong>:<\/p>\n<ul>\n<li><strong>Revoca difficile<\/strong>: un JWT valido fino a scadenza non si puo&#8217; revocare facilmente. Soluzioni: TTL brevi (15 minuti) + refresh token, blacklist dei JTI revocati.<\/li>\n<li><strong>Algoritmo &#8220;none&#8221;<\/strong>: vulnerabilita&#8217; classica. Usate sempre <code>RS256<\/code> o <code>ES256<\/code>, mai <code>none<\/code>.<\/li>\n<li><strong>Algorithm confusion<\/strong>: alcune librerie permettono di passare la chiave pubblica come HMAC secret. Pinnare l&#8217;algoritmo nel verifier.<\/li>\n<li><strong>Storage lato client<\/strong>: localStorage e&#8217; vulnerabile a XSS. Preferite cookie httpOnly + SameSite=Strict.<\/li>\n<li><strong>Payload sensibili<\/strong>: il payload e&#8217; Base64, non cifrato. Non metteteci password, dati medici, IBAN.<\/li>\n<\/ul>\n<p><img decoding=\"async\" width=\"1880\" height=\"1250\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/protezione-dati-api.jpg\" alt=\"Protezione dati cifratura API sicurezza\" class=\"wp-image-805\" style=\"max-width:100%;height:auto;margin:20px 0;\" srcset=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/protezione-dati-api.jpg 1880w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/protezione-dati-api-300x199.jpg 300w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/protezione-dati-api-1024x681.jpg 1024w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/protezione-dati-api-768x511.jpg 768w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/protezione-dati-api-1536x1021.jpg 1536w\" sizes=\"(max-width: 1880px) 100vw, 1880px\" \/><\/p>\n<h2>6. Rate limiting e throttling<\/h2>\n<p>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.<\/p>\n<p>Strategie nel 2021:<\/p>\n<ul>\n<li><strong>Token bucket<\/strong>: ogni client ha un secchio di token che si riempie a ritmo costante. Consente burst controllati.<\/li>\n<li><strong>Leaky bucket<\/strong>: richieste in coda, processate a velocita&#8217; fissa.<\/li>\n<li><strong>Fixed window<\/strong>: max N richieste per finestra temporale (es. 1.000\/h).<\/li>\n<li><strong>Sliding window<\/strong>: piu&#8217; equo, evita il problema dell&#8217;edge della finestra fissa.<\/li>\n<\/ul>\n<p>Limiti tipici:<\/p>\n<ul>\n<li>API pubbliche non autenticate: 60-100 req\/min per IP<\/li>\n<li>API autenticate per utente: 1.000-10.000 req\/h<\/li>\n<li>API enterprise: limiti per piano commerciale<\/li>\n<\/ul>\n<p>Header standard di risposta (RFC draft IETF):<\/p>\n<pre><code>X-RateLimit-Limit: 1000\nX-RateLimit-Remaining: 423\nX-RateLimit-Reset: 1623504000\nRetry-After: 60<\/code><\/pre>\n<p>Strumenti consigliati: <strong>Redis<\/strong> con algoritmo sliding window, oppure direttamente l&#8217;API Gateway (vedi paragrafo dedicato). Redis offre primitive atomiche (INCR, EXPIRE) ideali per implementare token bucket distribuiti su piu&#8217; istanze applicative.<\/p>\n<p>Una distinzione utile: <strong>rate limiting<\/strong> e&#8217; un limite hard (oltre la soglia, 429 Too Many Requests), <strong>throttling<\/strong> e&#8217; 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.<\/p>\n<p>Considerate anche limiti differenziati per endpoint: l&#8217;endpoint <code>\/login<\/code> dovrebbe avere un limite molto piu&#8217; 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.<\/p>\n<h2>7. HTTPS\/TLS obbligatorio<\/h2>\n<p>Nel 2021 non c&#8217;e&#8217; piu&#8217; alcuna scusa per esporre API in HTTP. Anche le API &#8220;interne&#8221; o &#8220;di test&#8221; devono usare TLS:<\/p>\n<ul>\n<li><strong>TLS 1.3<\/strong> (<a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8446\" target=\"_blank\" rel=\"noopener\">RFC 8446<\/a>, 2018) e&#8217; lo standard attuale: handshake piu&#8217; rapido, cifrari moderni, forward secrecy.<\/li>\n<li><strong>TLS 1.2<\/strong> ancora accettabile con cipher suite forti (no RC4, no 3DES).<\/li>\n<li><strong>SSL 3.0, TLS 1.0 e 1.1<\/strong>: deprecati ufficialmente nel 2020 (<a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8996\" target=\"_blank\" rel=\"noopener\">RFC 8996<\/a>). Disabilitateli sul server.<\/li>\n<\/ul>\n<p>Header di sicurezza obbligatori:<\/p>\n<ul>\n<li><code>Strict-Transport-Security: max-age=31536000; includeSubDomains<\/code> (HSTS)<\/li>\n<li><code>X-Content-Type-Options: nosniff<\/code><\/li>\n<li><code>X-Frame-Options: DENY<\/code><\/li>\n<li><code>Content-Security-Policy<\/code> (per chi serve anche HTML)<\/li>\n<\/ul>\n<p>Per i certificati: <strong>Let&#8217;s Encrypt<\/strong> con auto-renewal e&#8217; gratuito e affidabile. Per scenari piu&#8217; critici, certificati EV con OCSP stapling.<\/p>\n<h2>8. Validazione input e protezione da injection<\/h2>\n<p>L&#8217;input dell&#8217;utente non e&#8217; mai fidato. Mai. Anche se viene da una vostra app, anche se viene da un partner. Tutto va validato lato server.<\/p>\n<p>Pattern di validazione:<\/p>\n<ul>\n<li><strong>Schema validation<\/strong>: usate JSON Schema, OpenAPI\/Swagger validators, Joi (Node.js), Pydantic (Python), Bean Validation (Java). Rifiutate richieste che non rispettano lo schema.<\/li>\n<li><strong>Whitelist, non blacklist<\/strong>: definite cosa e&#8217; permesso, non cosa e&#8217; vietato.<\/li>\n<li><strong>Type, range, format<\/strong>: un ID deve essere un intero positivo, una mail deve matchare il regex, un IBAN deve avere 27 caratteri.<\/li>\n<li><strong>Limiti di dimensione<\/strong>: max 1MB per payload JSON, max 100 elementi per array. Evita zip bomb e memory exhaustion.<\/li>\n<\/ul>\n<p>Per le injection:<\/p>\n<ul>\n<li><strong>SQL<\/strong>: query parametrizzate \/ prepared statement. Mai concatenazione di stringhe.<\/li>\n<li><strong>NoSQL<\/strong> (MongoDB, etc.): attenzione a oggetti annidati come <code>{\"$ne\": null}<\/code> nei filtri. Cast esplicito a stringa.<\/li>\n<li><strong>Command injection<\/strong>: mai passare input utente a <code>exec()<\/code> o shell senza escape.<\/li>\n<li><strong>SSRF<\/strong>: se l&#8217;API fa chiamate HTTP basate su input utente, validate l&#8217;URL e bloccate range privati (10.x, 172.16-31.x, 192.168.x, 169.254.x).<\/li>\n<\/ul>\n<h2>9. CORS configuration<\/h2>\n<p>Cross-Origin Resource Sharing (CORS) e&#8217; uno dei temi piu&#8217; fraintesi. Non e&#8217; una protezione: e&#8217; un meccanismo che permette al browser di rilassare la same-origin policy. Configurato male, apre la porta agli attacchi.<\/p>\n<p>Errori comuni:<\/p>\n<ul>\n<li><strong><code>Access-Control-Allow-Origin: *<\/code> + <code>Allow-Credentials: true<\/code><\/strong>: combinazione pericolosa, accetta richieste da qualsiasi sito con i cookie dell&#8217;utente.<\/li>\n<li><strong>Reflection dell&#8217;origin<\/strong>: <code>Allow-Origin: &lt;qualsiasi origin la richiesta presenti&gt;<\/code> senza validazione. Equivale al wildcard.<\/li>\n<li><strong>Whitelist troppo lunga<\/strong>: meglio una lista corta e curata che un regex permissivo.<\/li>\n<\/ul>\n<p>Configurazione corretta:<\/p>\n<pre><code>Access-Control-Allow-Origin: https:\/\/app.brentasoft.com\nAccess-Control-Allow-Methods: GET, POST, PUT, DELETE\nAccess-Control-Allow-Headers: Authorization, Content-Type\nAccess-Control-Allow-Credentials: true\nAccess-Control-Max-Age: 86400<\/code><\/pre>\n<p>Una sola origin per volta, validata server-side contro una whitelist hardcoded.<\/p>\n<h2>10. API Gateway: il guardiano centrale<\/h2>\n<p>Un <strong>API Gateway<\/strong> e&#8217; il &#8220;buttafuori&#8221; davanti alle vostre API: gestisce autenticazione, rate limiting, logging, caching, trasformazione, routing \u2014 in modo centralizzato. Nel 2021 e&#8217; praticamente obbligatorio per chi gestisce piu&#8217; di una manciata di API.<\/p>\n<p><img decoding=\"async\" width=\"1880\" height=\"1251\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-gateway-firewall.jpg\" alt=\"API Gateway firewall server network security\" class=\"wp-image-806\" style=\"max-width:100%;height:auto;margin:20px 0;\" srcset=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-gateway-firewall.jpg 1880w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-gateway-firewall-300x200.jpg 300w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-gateway-firewall-1024x681.jpg 1024w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-gateway-firewall-768x511.jpg 768w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/06\/api-gateway-firewall-1536x1022.jpg 1536w\" sizes=\"(max-width: 1880px) 100vw, 1880px\" \/><\/p>\n<p>Le opzioni piu&#8217; usate nel 2021:<\/p>\n<ul>\n<li><strong>Kong<\/strong> (open source + enterprise): basato su Nginx + Lua, ricco ecosistema di plugin, ottimo on-premise e Kubernetes.<\/li>\n<li><strong>Tyk<\/strong>: open source, scritto in Go, dashboard pulita, buon rapporto qualita&#8217;-prezzo.<\/li>\n<li><strong>AWS API Gateway<\/strong>: serverless, integrazione nativa con Lambda, IAM, Cognito. Ottimo se siete gia&#8217; in AWS.<\/li>\n<li><strong>Google Apigee<\/strong>: enterprise di fascia alta, analytics avanzati, monetization. Costoso.<\/li>\n<li><strong>Azure API Management<\/strong>: la scelta naturale in stack Microsoft, integrazione con AAD.<\/li>\n<li><strong>NGINX Plus<\/strong>: per chi vuole leggerezza e controllo a basso livello.<\/li>\n<\/ul>\n<p>Cosa demanda al Gateway:<\/p>\n<ul>\n<li>Autenticazione (validazione JWT, API key, OAuth2 introspection)<\/li>\n<li>Rate limiting e quota per consumer<\/li>\n<li>Routing e versioning (<code>\/v1\/<\/code> vs <code>\/v2\/<\/code>)<\/li>\n<li>Caching delle risposte GET<\/li>\n<li>Logging strutturato e metriche<\/li>\n<li>Trasformazione richieste\/risposte (es. legacy SOAP -&gt; REST)<\/li>\n<li>Circuit breaker e retry verso i backend<\/li>\n<\/ul>\n<p>Il Gateway non sostituisce i controlli a livello applicativo: e&#8217; la prima linea, non l&#8217;unica. La regola d&#8217;oro: defense in depth. Anche se il Gateway valida il JWT, l&#8217;applicazione deve ricontrollare scope, ownership e autorizzazione di funzione. Non confidate nel singolo punto di controllo.<\/p>\n<p>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.<\/p>\n<h2>11. Monitoring e logging<\/h2>\n<p>L&#8217;API10 OWASP \u2014 <strong>Insufficient Logging &amp; Monitoring<\/strong> \u2014 e&#8217; la piu&#8217; sottovalutata. Senza log strutturati e alerting, un attacco puo&#8217; durare mesi prima di essere scoperto.<\/p>\n<p>Cosa loggare per ogni richiesta:<\/p>\n<ul>\n<li>Timestamp ISO 8601 con timezone<\/li>\n<li>Method, path, status code, latenza<\/li>\n<li>IP client e User-Agent<\/li>\n<li>User ID (se autenticato), API key ID<\/li>\n<li>Trace ID \/ correlation ID (per tracciare richieste tra microservizi)<\/li>\n<li>Eventi di sicurezza: login fallito, 401, 403, 429, errori di validazione<\/li>\n<\/ul>\n<p>Cosa <em>non<\/em> loggare:<\/p>\n<ul>\n<li>Password, token, JWT, API key<\/li>\n<li>Numeri di carta, CVV<\/li>\n<li>Body completi con dati sanitari\/personali (a meno di mascheratura)<\/li>\n<\/ul>\n<p>Stack tipico 2021: <strong>ELK<\/strong> (Elasticsearch + Logstash + Kibana) oppure <strong>Loki + Grafana<\/strong>, <strong>Prometheus<\/strong> per metriche, <strong>Sentry<\/strong> per gli errori applicativi, <strong>Grafana<\/strong> per dashboard. Per scenari managed: Datadog, New Relic, AWS CloudWatch.<\/p>\n<p>Alert da configurare subito:<\/p>\n<ul>\n<li>Spike di 401\/403 (possibile attacco brute force)<\/li>\n<li>Spike di 5xx (problemi infrastrutturali)<\/li>\n<li>Latency p95\/p99 oltre soglia<\/li>\n<li>Traffico anomalo da singolo IP o user<\/li>\n<li>Geolocalizzazione sospetta (login dall&#8217;Italia, poi 5 minuti dopo dalla Russia)<\/li>\n<\/ul>\n<h2>12. Domande frequenti<\/h2>\n<h3>Quali sono le best practice di API security piu&#8217; importanti nel 2021?<\/h3>\n<p>Le tre fondamentali: autenticazione robusta (OAuth2 + JWT con scadenza breve), rate limiting su tutti gli endpoint, validazione rigorosa dell&#8217;input lato server. Aggiungete HTTPS obbligatorio (TLS 1.2+) e logging strutturato per avere una baseline solida.<\/p>\n<h3>Qual e&#8217; la differenza tra OAuth2 e JWT?<\/h3>\n<p>OAuth 2.0 e&#8217; un <em>framework di autorizzazione<\/em>: definisce come un&#8217;app ottiene il permesso di chiamare un&#8217;API per conto dell&#8217;utente. JWT e&#8217; un <em>formato di token<\/em>: una stringa firmata che trasporta claim. Spesso OAuth2 emette JWT come access token, ma puo&#8217; anche usare token opachi.<\/p>\n<h3>E&#8217; sicuro mettere il JWT in localStorage?<\/h3>\n<p>No, e&#8217; vulnerabile a XSS. Preferite cookie con flag <code>HttpOnly<\/code>, <code>Secure<\/code> e <code>SameSite=Strict<\/code>. Se proprio dovete usare localStorage, implementate una solida CSP e tenete TTL brevissimi (5-15 minuti).<\/p>\n<h3>Quanto deve durare un access token JWT?<\/h3>\n<p>Nel 2021 la best practice e&#8217; 15 minuti per l&#8217;access token + refresh token (scadenza 7-30 giorni) ruotato a ogni uso. Token piu&#8217; lunghi rendono difficile la revoca e amplificano l&#8217;impatto di un furto.<\/p>\n<h3>Mi serve davvero un API Gateway per un progetto piccolo?<\/h3>\n<p>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&#8217;investimento.<\/p>\n<h3>Come proteggere un&#8217;API da attacchi DDoS?<\/h3>\n<p>Difesa stratificata: Cloudflare\/AWS Shield in front, rate limiting sull&#8217;API Gateway, autoscaling lato backend, circuit breaker per evitare effetti a catena. Per attacchi applicativi (low &amp; slow), monitorate i pattern e bloccate per fingerprint.<\/p>\n<h3>Mi conviene scrivere io l&#8217;autenticazione o usare un servizio?<\/h3>\n<p>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&#8217; battle-tested. Concentrate il vostro tempo sul dominio del business.<\/p>\n<p>Se state pianificando una nuova <a href=\"https:\/\/brentasoft.com\/soluzioni\/web-app-pwa.php\">web app o PWA<\/a>, dei <a href=\"https:\/\/brentasoft.com\/soluzioni\/gestionali-personalizzati.php\">gestionali personalizzati<\/a>, o state migrando verso <a href=\"https:\/\/brentasoft.com\/soluzioni\/software-cloud.php\">soluzioni cloud<\/a>, includete API security nel design fin dall&#8217;inizio. Per approfondire i fondamentali, leggete la nostra <a href=\"https:\/\/brentasoft.com\/blog\/cos-e-una-api-rest-guida-non-sviluppatori\/\">guida non tecnica alle API REST<\/a> e la nostra <a href=\"https:\/\/brentasoft.com\/blog\/sicurezza-informatica-pmi-guida-2021\/\">guida alla sicurezza informatica per PMI 2021<\/a>.<\/p>\n<div style=\"background:#f5f7fa;border-left:4px solid #0066cc;padding:20px;margin:30px 0;border-radius:4px;\">\n<h3 style=\"margin-top:0;\">Hai API che gestiscono dati sensibili?<\/h3>\n<p>Brentasoft sviluppa API REST e GraphQL con security by design per PMI italiane: OAuth2, JWT, mTLS, rate limiting, OWASP best practice, monitoring.<\/p>\n<p style=\"margin-bottom:0;\"><a href=\"https:\/\/brentasoft.com\/erp-brenta.php\" style=\"display:inline-block;background:#0066cc;color:#fff;padding:12px 24px;border-radius:4px;text-decoration:none;font-weight:600;\">Scopri ERP Brenta &rarr;<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>API security best practice 2021: OAuth2, JWT, mTLS, OWASP Top 10, rate limiting, API Gateway. Guida pratica per CTO e developer senior italiani.<\/p>\n","protected":false},"author":2,"featured_media":803,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"API security: 10 best practice per il 2021","_seopress_titles_desc":"API security best practice 2021: OAuth2, JWT, mTLS, OWASP Top 10, rate limiting, API Gateway. Guida pratica per CTO e developer senior italiani.","_seopress_robots_index":"","footnotes":""},"categories":[9],"tags":[494,489,492,493,491,490,495],"class_list":["post-802","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guide-e-tutorial","tag-api-gateway","tag-api-security","tag-jwt","tag-mtls","tag-oauth2","tag-owasp","tag-sviluppo-sicuro"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/802","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=802"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/802\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/803"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=802"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=802"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=802"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}