Principali modelli di sicurezza API

Le API sono il sangue vitale delle applicazioni moderne. Sono anche la superficie di attacco più mirata. SQL injection, XXE, autenticazione compromessa, movimento laterale — tutto entra attraverso le API.

In Perimetrical, crediamo che la sicurezza delle API richieda un approccio stratificato. Non solo bloccare ciò che è cattivo (sicurezza negativa), ma anche permettere solo ciò che è buono (sicurezza positiva). Esploriamo entrambi i modelli e come funzionano insieme.

L'architettura: reverse proxy con protezione edge

Il nostro modello posiziona un reverse proxy basato su CDN tra i client e la tua API backend:

Client → CDN (Edge) → [Ispezione WAF + Logica VCL] → Cache o API Backend

Questa semplice architettura sblocca un potere immenso:

• Ispezione edge: le decisioni di sicurezza avvengono all'edge della CDN, non all'origin
• Bassa latenza: le richieste legittime passano in microsecondi
• Scalabilità: il traffico DDoS e gli attacchi bot vengono assorbiti all'edge, non raggiungono mai l'origin
• Caching: le risposte API memorizzabili in cache riducono il carico dell'origin e migliorano le prestazioni

Modello 1: modello di sicurezza negativa (nega il cattivo)

Il modello di sicurezza tradizionale: supponi che tutto sia legittimo a meno che non sia provato il contrario. Blocca i modelli di attacco noti.

WAF: nucleo della sicurezza negativa

Un Web Application Firewall (WAF) ispeziona il traffico in arrivo e blocca le richieste che corrispondono a modelli malintenzionati noti:

• Set di regole principali OWASP (CRS): mantenuto da una comunità di sicurezza, queste sono regole collaudate in battaglia per gli attacchi comuni
• Rilevamento SQL Injection (SQLi): identifica comandi come UNION SELECT, DROP TABLE o payload codificati
• Rilevamento Cross-Site Scripting (XSS): blocca l'iniezione JavaScript, i gestori di eventi e i tentativi di iframe
• Local File Inclusion (LFI) / Remote File Inclusion (RFI): previene gli attacchi di traversal (../../../etc/passwd) e il caricamento di script remoti
• Applicazione del protocollo HTTP: rifiuta i header malformati, il contenuto di dimensioni eccessive e i metodi non validi
• Prevenzione della fissazione della sessione e CSRF: convalida i modelli di token e gli header di origine

Il WAF funziona con il rilevamento basato su firma e comportamentale. È efficace contro gli attacchi noti ma può generare falsi positivi e richiede continui aggiornamenti delle regole.

Limitazioni della sicurezza negativa da sola

• Solo vulnerabilità note: gli attacchi zero-day e le tecniche nuove slittano attraverso
• Tentativi di evasione: gli attaccanti utilizzano codifica, polimorfismo e offuscamento per aggirare le regole
• Falsi positivi: le richieste legittime a volte corrispondono alle firme di attacco (soprattutto nei contenuti generati dall'utente)
• Manutenzione delle regole: richiede continui aggiornamenti man mano che emergono nuovi modelli di attacco

Modello 2: modello di sicurezza positiva (consenti il buono)

Un approccio più moderno: invece di bloccare ciò che è cattivo, consenti solo ciò che hai esplicitamente definito come buono. Ciò richiede la definizione dello schema API.

Convalida dello schema OpenAPI

OpenAPI (precedentemente Swagger) ti consente di definire il contratto API: endpoint, metodi, parametri, tipi di dati e vincoli.

Utilizzando questo schema, Perimetrical applica:

• Whitelisting degli endpoint: solo gli endpoint definiti sono accessibili; i percorsi non definiti restituiscono 404
• Applicazione del metodo HTTP: un endpoint definito per GET non è accessibile tramite POST, PATCH o DELETE
• Convalida dei parametri: i parametri obbligatori devono essere presenti, i parametri facoltativi vengono ignorati se non necessari
• Applicazione del tipo di dati: i parametri interi devono essere interi, le stringhe devono corrispondere alla lunghezza definita, le date devono essere valide
• Convalida dell'enumerazione: se un parametro accetta solo "attivo" o "inattivo", qualsiasi altra cosa viene rifiutata
• Conformità dello schema: i payload JSON devono conformarsi allo schema definito; i campi extra vengono rifiutati o normalizzati
• Convalida dell'intervallo: i campi numerici rimangono entro i limiti min/max, le stringhe entro i limiti di lunghezza

Esempio: un endpoint `/api/users/{id}` definito come GET-only con `id` come intero positivo farà:

• Accetta: `/api/users/123` ✓
• Accetta: `/api/users/999999` ✓
• Rifiuta: `/api/users/abc` ✗ (non è un intero valido)
• Rifiuta: `/api/users/123/delete` ✗ (tentativo di path traversal)
• Rifiuta: `POST /api/users/123` ✗ (metodo HTTP sbagliato)

Vantaggi della sicurezza positiva

• Nessun falso positivo: solo le richieste che corrispondono al contratto API sono consentite
• Protezione zero-day: le tecniche di attacco sconosciute vengono automaticamente bloccate se violano lo schema
• Guidato dalla documentazione: la tua specifica OpenAPI è sia documentazione che policy di sicurezza
• Manutenzione minima: le regole cambiano quando il contratto API cambia, non quando emergono nuovi attacchi
• Alta fiducia: sai esattamente quale traffico è valido; tutto il resto è dannoso

Limitazioni della sicurezza positiva da sola

• Richiede schema API: non tutte le applicazioni hanno definizioni OpenAPI formali
• Logica di business cieca: convalida il formato ma non l'intento (ad es. consente SQL all'interno di un parametro di stringa formattato correttamente)
• Sovraccarico di prestazioni: la convalida dello schema su ogni richiesta ha un costo di latenza (anche se minimo sui CDN moderni)

Vantaggi del caching CDN per le richieste memorizzabili in cache

Non tutte le richieste API sono dinamiche. Le API di lettura intensiva per configurazione, cataloghi o dati di riferimento sono eccellenti candidati al caching.

• Riduzione della latenza: le risposte memorizzate in cache servite dal bordo in microsecondi vs. origin in millisecondi
• Moltiplicazione della velocità effettiva: una singola richiesta di origin serve 100.000 hit della cache
• Protezione dell'origin: il livello cache assorbe i picchi di traffico in lettura, proteggendo l'origin dall'overload
• Invalidazione granulare: il purging basato su CDN (URL, tag o basato su tempo) mantiene i contenuti freschi senza stampede della cache
• Riduzione dei costi: meno richieste di origin = costi di egress inferiori e carico di query del database ridotto

Protezione DDoS applicativa Layer 7

Oltre a WAF e convalida dello schema, Perimetrical aggiunge la protezione DDoS comportamentale al livello applicativo:

• Rate limiting: per-IP, per-utente o per-chiave API richieste limiti con blocco automatico
• Assorbimento del traffico: il traffico DDoS viene assorbito all'edge; il traffico di origin legittimo continua
• Targeting dei client: applicare limiti più severi ai client non affidabili (nuovi IP, botnet noti)
• ACL (Access Control Lists): whitelist partner affidabili, blocca ASN maligne note
• Gestione delle anomalie: risposta automatica alle anomalie comportamentali (improvviso picco di traffico, spostamento geografico)

L'approccio ibrido: combinare entrambi i modelli

La migliore sicurezza API combina la sicurezza negativa e positiva:

1. Livello 1 (Edge): WAF blocca gli attacchi ovvi (SQLi, XSS noti, ecc.) — veloce, basato su firma, cattura il 90% degli attacchi automatizzati
2. Livello 2 (Edge): la convalida dello schema OpenAPI applica il contratto API — nessun falso positivo, resistente a zero-day
3. Livello 3 (Edge): la protezione DDoS e comportamentale blocca i modelli di traffico anormali
4. Livello 4 (Edge): il caching serve le richieste legittime dall'edge; l'origin gestisce solo i cache miss
5. Livello 5 (Origin): convalida a livello di applicazione come difesa finale — convalida i vincoli di logica di business

Questo strato assicura:

• Il 99% degli attacchi viene fermato all'edge, non raggiunge mai l'origin
• Il traffico legittimo sperimenta una latenza minima
• Il tuo origin funziona snello, servendo solo cache miss legittimi
• Il recupero dagli attacchi è veloce perché i nodi edge sono stateless e distribuiti

Implementazione in Perimetrical

La nostra piattaforma lo rende semplice:

• Carica la tua specifica OpenAPI nel dashboard
• Abilita la protezione WAF con un clic
• Configura le regole di caching per gli endpoint memorizzabili in cache
• Imposta i limiti di velocità per endpoint o globali
• Monitora in tempo reale: traffico dal vivo, richieste bloccate, tempi di risposta dell'origin

Conclusione

La sicurezza delle API nel 2025 richiede più delle sole regole WAF basate su firma. Le API moderne hanno bisogno di un approccio ibrido: sicurezza negativa per catturare gli attacchi noti, sicurezza positiva per applicare il contratto API e protezioni comportamentali per mitigare i DDoS. Combinato con il caching edge e l'intelligenza CDN, questo crea uno scudo impenetrabile attorno all'infrastruttura API.

Il risultato è API più veloci, meno incidenti di sicurezza e minore carico dell'origin — il tutto senza sacrificare l'esperienza dell'utente.