Protezione API e filtraggio delle richieste

1) Perché è necessario

API è il bordo esterno e interno della piattaforma. Qualsiasi errore di autenticazione, autorizzazione, convalida o normalizzazione delle richieste si trasforma in un funzionamento di vulnerabilità (PALLA/IDOR, injection, SSRF, sovraccarico di massa, esaurimento delle risorse). Obiettivo: creare una protezione su più livelli (defense-in-depth) dal perimetro alle regole aziendali, con SLO misurabili e controllo dei rischi.

2) Inventario e classificazione API

Catalogo API: registro di tutti i servizi/endpoint, proprietari, versioni, tipi di client (web, mobile, partner), modalità (pubblico/partner/interno), PII/find.
Criticità: High (transazioni finanziarie/autorizzazioni), Medium (lettura profilo), Low (guide pubbliche).
La superficie dell'attacco è , , , , webhooks.
Stato: prod/staging/experimental, criterio di deprecazione, durata di vita dei token/chiavi.
Shadow/API abbandonate: rilevamento attraverso l'ingrest dei reparti, eBPF/Service Mesh telemetria, confronto con la directory.

3) Modello di minacce (brevemente)

Identificazione: furto di token, fissazione sessione, MitM, replay.
Autorizzazione: PALLA/IDOR, escalation orizzontale/verticale.
Input: iniezioni (SQL/NoSQL/LDAP), modelli/serilizzazione, path traversal, intestazioni.
Traffico: DDoS/L7-floud, richieste lente, retrai fantasma.
Integrazioni: webhooks non sicuri, SSRF tramite impostazioni URL, scaricare file/scene.
La logica è abuso di bonus, corse, idempotenza incoerente.

4) Standard di sicurezza di base (minimo)

1. TLS 1. 2 + ovunque; HSTS; crittografi deboli disattivati.
2. Autenticazione: OAuth2/OIDC per i clienti, mTLS/o HMAC - servizio-a-servizio.
3. Autorizzazione: PDP centralizzato (RBAC/ABAC), controllo a livello di oggetto (PALLA).
4. Convalida: schema rigoroso (OpenAPI/JSON Schema/Protobuf), rifiuto nei campi superflui.
5. Limiti: rate/quote + burst, per-client/per-IP/per-token.
6. Idampotenza alle operazioni write, protezione da ripetizioni/corse.
7. Filtrazione WAF/gateway: normalizzazione dei percorsi/intestazioni, fogli deny, blocco payload-anti-pattern.
8. I segreti sono KMS/Vault, rotazione chiavi/certificati, controllo delle fughe.
9. Tracciabilità, verifiche di sicurezza (chi/cosa/quando/risultato), alert.
10. Procedure: playbook incidenti, valigette di prova e pentesti regolari/DAST.

5) Autenticazione e gestione dei token

OAUTh2/OIDC: token access a breve vita, refresh rigorosamente secondo OIDC; udienza/issuer/exp sono controllati sul gateway.
JWT: RS256/ES256; «nbf/exp/aud» è obbligatorio; Divieto di conservazione PII. Rotazione delle chiavi tramite JWKS.
DPoP/PoP - Aggancia il token alla chiave client per ridurre il rischio replay/furto.
mTLS per sistemi interni e partner fidati (certificazione CN/SAN, CRL/OCSP).
HMAC (firme) - Canonizzazione determinata (metodo + percorso + timestamp + nonce + body-hash); finestra di tempo valida (© 300s).
Sessioni del browser: SameSite=strict/lax, HttpOnly, Secure; Protezione da CSRF (doppio sottomit/token state).
Deposito clienti: su mobile - depositi sicuri (Keychain/Keystore), protezione da debag, pinning certificati.

6) Autorizzazioni (BOLA-first)

Object-level: ogni operazione verifica il diritto a una risorsa specifica (resource owner/scope/attributi).
RBAC/ABAC: ruoli + attributi (paese, segmento, limiti di rischio, livello KYC).
Criteri: deny-by-default; allow espliciti; versioning dei criteri Test per le valigette negative.
Kash di soluzioni: TTL adattivo + invalidità quando i ruoli/segmenti cambiano.

7) Filtrare e normalizzare le richieste (Gaitway/WAF)

Normalizzazione: compressione di slot ripetuti, disattivazione «../», decodifica una volta, ritaglio di spazi/zero byte.
Intestazioni allow-list (Host, Content-Type, Accept, Authorization, Date, Idempotency-Key, intestazioni trace).
I metodi sono: «GET/HEAD» senza corpo; «POST/PUT/PATCH», con un tipo di applicazione/json o rigorosamente autorizzato.
Dimensioni: max-body, max-headers, max-path; early-reject 413/431.
File: validatore MIME, antivirus/sandbox, divieto di contenuti attivi, resease/igiene delle immagini.
Indirizzi/fetch URL: blocco SSRF (deny private ranges/metadata IP, diagramma solo «https», allow-list domini).
SQL/NoSQL-Pattern: firme di iniezione tramite WAF rule-set + parametrizzazione server delle richieste.

Esempio di criteri di intestazione (formato pseudo)

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) Limiti, quote e antibot

Rate limiting: token-bucket/ leaky-bucket; livelli - per IP, per API key, per user, per org.
Quote: giornaliera/mensile, separata per i metodi write/expensive.
Adattabilità: stretta dinamica per anomalie (sudden burst/credential stuffing).
Slow-loris/slow-POST: timeout di lettura/keep-alive, vincolo delle connessioni parallele.
Antibot: device-fingerprint, segni comportamentali, proof-of-work/goccia ad alto rischio, elenco tor/proxy.
Controllo IP: filtri geo/ASN, sottotitoli deny «sporchi», fogli allow per i partner/dashboard.

9) Convalida di input e diagrammi

Fail-closed: tutto ciò che non passa dallo schema è 400. I campi superflui sono da rifiutare.
I tipi/intervalli sono i numeri, le date (UTC/ISO-8601), i valori enum, le lunghezze delle righe, le righe.
Qualità JSON: max-nesting, proibizione di grandi array/chiavi, canonical order (opzionale).
Validazione aziendale: Idempotenza per Idempotency-Key; regole anti-frod (limiti di frequenza, amount caps).
GraphQL: depth/complexity-limite, allow-listed queries, per-campo autorizzazioni.
gRPC: schemi Protobuf rigorosi, campi obbligatori, limiti di dimensione dei messaggi.

10) Webhooks e chiamate esterne

Firme: HMAC con timestamp/nonce; Verifica prima dell'elaborazione finestra +/- 5 minuti

Consegna: retrai con pausa esponenziale e jitter; massimo-tentativi deduplicazione dell'ID evento.
IP allow-list fornitore un sottofondo/percorso separato; stack di hosting minimo.
2xx solo dopo la scrittura interna riuscita altrimenti 4xx/5xx con codice comprensibile.
Controllo SSRF in uscita: con callback URL - allow-list, non indirizzi privati.

11) Crittografia e gestione dei segreti

Nel canale: TLS 1. 2+/1. 3, pinning, rigorosa politica dei codici.
In pace: crittografia del database/archivio oggetti, chiavi singole per PII/find.
KMS/Vault: memorizzazione centralizzata dei segreti, TTL brevi, rotazione automatica.
Chiavi e certificati separati per ambienti Controllo delle erogazioni Impedisci l'output ai cessi.
Token-introspection: elenchi di richiamo offline (revocation), brevi «exp».

12) Osservazione, verifica e risposta

Logi di protezione: tentativi di autenticazione, errori di autorizzazione, eventi rate-limit, modifiche a ruoli/limiti.
Traccia: correlation-ID end-end tracciamento delle chiamate esterne.
Metriche: RPS, P95/P99 latency, errato-rate codici, quota di 401/403/429, limiti hit-rate, anomalie.
Alert: picchi di 401/403/429, altezza 5xx, frequenti conflitti idempotency, brusche deviazioni di grafQL-complexity.
Playbooks blocca chiavi/token, ripristina rapidamente le regole, scalda i fogli deny, notifica i proprietari dei servizi.
Forenzica - Conserva payload controversi (con modifica sicura del PII), repliche in uno stand isolato.

13) Errori e risposte al cliente

Un unico formato di errore (codice, messaggio, trace-id, categoria).
Nessuna fuoriuscita: non rivelare SQL, nomi di tabella, idi interni; 403 invece di «perché no».
Codici: 400 (convalida), 401 (nessuna autenticazione), 403 (nessun diritto), 404 (maschera esistenza), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; per idempotenza, un consiglio di ripetizione con la stessa chiave.

14) Cartelli architettonici

Zero-Trust: mTLS, autorizzazione esplicita tra tutti i servizi, privilegi minimi.
API gateway + WAF + servizio-mesh: separazione dei compiti - perimetro, regole L7, autenticazione interna.
Canary/Blue-Green: rilascia nuove regole di filtraggio in modo graduale con osservazione.
Fail-closed - Per i write critici, è meglio guastare in modo sicuro che permettere un'operazione non corretta.
Backpressure: code/buffer, circuito breaker, timeouts/budget.

15) Esempi di regole pratiche (pseudo-config)

15. 1 Vincolo di percorsi e metodi

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15. 2 Idampotenza

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15. 3 Firma richiesta (HMAC)

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15. Protezione SSRF 4

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15. 5 GraphQL limite

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Specificità iGaming/finanza

Limiti segmentati dipendono dal CUS/paese/profilo di rischio.
Finestre temporali: regole per la frequenza di depositi/conclusioni, «raffreddamento» tra transazioni.
Bonus anti-abuse: blocchi consistenziali su account/dispositivo/IP/strumento di pagamento.
Controllo dei requisiti dei regolatori: conservazione dei fogli delle azioni e delle soluzioni (KYC/AML), periodi di ritenzione, registri invariati.

17) Elenco di controllo prod-pronto

• Catalogo API completo e mappa dei flussi di dati (PII/finanza).
• OpenAPI/Protobuf schemi, test di convalida e contratti in CI.
• mTLS/HMAC/OAuth2 configurati; TTL dei token corti; rotazione delle chiavi.
• Test PALLA e valigette di autorizzazione negative; PDP centralizzato.
• Limiti/quote/anti-bot, protezione contro slow-loris; Filtri IP.
• Regole di normalizzazione WAF/gateway, firme anti-iniezione.
• Idampotenza delle operazioni write; Protezione da replay.
• Firme webhook e allow-list; endpoint isolati.
• Segreti in KMS/Vault; stormi criptati; alert per anomalie.
• Dashboard, alert, verifiche; casi di playbooks lavorati.
• Pentest regolare/DAST/SAST, tracce di vulnerabilità e patch.

18) Antipattern (cosa che non può)

Fidarsi dì X-Forwarded- "senza terminazioni rigide TLS sul perimetro.
Accetta schemi JSON personalizzati «Content-Type» e «soft».
JWT a lunga vita senza ritiro/rotazione.
Miscelare ruoli e regole aziendali in un codice senza regole centralizzate.
Loghi con segreti/PII; Messaggi dettagliati da 500 verso l'esterno.
Endpoint aperti temporanei senza limiti e autorizzazioni.

19) Versioning e deprecato

Versioni nel percorso/intestazione; Criteri di supporto (ad esempio N-2).
Annunci: tempi di deprecazione, monitoraggio dell'utilizzo delle versioni precedenti, disattivazione controllata.
Compatibilità: contratti e matrici di test client/partner.

20) Test di sicurezza

Test contrattuali di schemi/regole, ingresso fuzzing, negative auth.
Profili perfomance con limiti/quote, prova di blocco (chaos-traffico).
Red-team/bug-bounty: script PALLA, SSRF, firme/repliche, GraphQL-complexity.

TL; DR

1. Catalogo API + schemi rigorosi.
2. OAuth2/OIDC per i clienti che si trovano all'interno.
3. Perimetro PALLA per risorsa (ABAC/RBAC).
4. Filtrazione: regolazione di percorsi/intestazioni, limiti, regole WAF.
5. Idempotenza, firme, protezione contro replay/SSRF.
6. KMS/Vault e rotazione di segreti.
7. Osservazione, alert, playbooks.