Cloudflare e CORS: gestione del Cross-Origin Resource Sharing

Cloudflare e CORS: gestione del Cross-Origin Resource Sharing

CORS (Cross-Origin Resource Sharing) è il meccanismo di sicurezza dei browser che limita le richieste tra origini diverse (protocollo + dominio + porta). Quando il sito su tuosito.it chiama un'API su api.tuosito.it, il browser blocca la richiesta a meno che il server di destinazione invii header CORS appropriati. Cloudflare può facilitare o complicare la gestione CORS a seconda della configurazione: vediamo come farlo correttamente.

Anatomia di una richiesta CORS

Esistono due tipi di richieste cross-origin. Simple request (GET, POST con content-type semplice): il browser invia direttamente la richiesta, il server risponde con header Access-Control-Allow-Origin. Preflight (PUT, DELETE, custom headers): il browser invia prima OPTIONS per chiedere permesso, solo se la risposta è positiva manda la richiesta vera. Cloudflare deve permettere il flusso di entrambe.

Procedura passo-passo

  1. Identifica le origini che devono accedere alle tue risorse (sito frontend, app mobile, partner).
  2. Configura l'origine (Nginx, Apache, Node) per inviare header CORS corretti.
  3. Esempio Nginx: add_header Access-Control-Allow-Origin "https://tuosito.it";
  4. Per multiple origini gestiscile via map o tramite Worker.
  5. Per preflight gestisci esplicitamente OPTIONS restituendo 204 con header CORS completi.
  6. Su Cloudflare crea un Worker se vuoi gestire CORS centralmente.
  7. Worker example: intercetta OPTIONS, ritorna 204 con header.
  8. Per altre richieste passa-attraverso e aggiungi Access-Control-Allow-Origin alla risposta.
  9. Testa con curl -X OPTIONS -H "Origin: https://tuosito.it" -H "Access-Control-Request-Method: PUT" https://api.tuosito.it/endpoint.
  10. Verifica risposta 204 con header CORS attesi.

Header CORS essenziali

Access-Control-Allow-Origin: specifica origine permessa, valore "*" per qualsiasi o origine specifica. Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS. Access-Control-Allow-Headers: header custom permessi (Authorization, Content-Type, X-Custom). Access-Control-Allow-Credentials: true se servono cookie cross-origin (requires origine specifica, no "*"). Access-Control-Max-Age: cache preflight in secondi (es. 86400).

Worker per CORS dinamico

Un Worker Cloudflare è il modo più elegante per gestire CORS quando l'origine non può essere modificata o quando servono regole dinamiche. Esempio: il Worker controlla l'Origin header della richiesta, lo confronta con una whitelist, ed echoes l'origine nell'Access-Control-Allow-Origin solo se autorizzata. Questo permette di gestire molte origini senza wildcards e mantenere credenziali. Il Worker è codice JavaScript di 30-50 righe.

Errori comuni e come risolverli

  • Access-Control-Allow-Origin missing: l'origine non invia header. Configura Nginx/Apache o usa Worker.
  • Multiple values in Allow-Origin: il server lo invia due volte. Configura una sola sorgente di header.
  • Credentials true with wildcard: errore browser. Sostituisci "*" con origine specifica.
  • Preflight 405 Method Not Allowed: l'origine non gestisce OPTIONS. Aggiungi handler dedicato.
  • WAF blocca preflight: regole WAF troppo aggressive su OPTIONS. Aggiungi exception per metodo OPTIONS.

Cache e CORS

Se Cloudflare cache una risposta con header CORS basato su Origin, il cache key di default non include Origin. Risultato: la risposta cachata per origine A viene servita per origine B con header sbagliato. Per evitare: usa header Vary: Origin sulla risposta dell'origine. Cloudflare e i browser rispetteranno il Vary creando cache entry separate per origine. Su Cloudflare anche Custom Cache Keys (Enterprise) permettono di includere Origin.

CORS e API pubblica

Per API pubbliche che devono essere chiamate da qualsiasi sito (es. mappe, font, public data), il valore Access-Control-Allow-Origin: * è appropriato. Non puoi avere credentials in questo caso. Per font e CSS l'header serve solo se l'origine è diversa. Per video/audio cross-origin servono CORS più una direttiva crossorigin nel tag HTML. Cloudflare Images e Stream gestiscono CORS automaticamente.

Domande frequenti

D: Cloudflare aggiunge automaticamente header CORS?
R: No di default. Devi configurare origine o Worker.

D: Posso permettere multiple origini con un solo header?
R: No, Allow-Origin accetta un solo valore. Usa Worker per gestione dinamica.

D: SameSite cookie influenza CORS?
R: Sì, cookie SameSite=Strict non viaggiano cross-origin.

D: Posso disabilitare CORS?
R: No, è imposto dal browser. Devi gestire correttamente.

Considerazioni operative finali

Quando applichi una configurazione di questo tipo in produzione è sempre buona norma seguire un'approccio incrementale: parti con un test su staging, monitora gli effetti per qualche giorno, poi estendi gradualmente al traffico live. La rete Cloudflare elabora ogni cambiamento in pochi secondi a livello globale, quindi le modifiche sono effettive quasi immediatamente, ma gli effetti collaterali su utenti reali possono richiedere ore o giorni per emergere. Annota nel runbook interno data, motivo e parametri di ogni modifica significativa. Una documentazione precisa accelera enormemente il troubleshooting futuro e facilita il passaggio di consegne tra membri del team.

Vale anche la pena ricordare che Cloudflare aggiorna frequentemente l'interfaccia del dashboard e le posizioni delle voci di menu. La logica e le funzionalità descritte in questa guida restano valide, ma il percorso esatto per raggiungere ogni opzione può variare leggermente nel tempo. In caso di difficoltà a trovare una specifica voce, utilizza la barra di ricerca interna del dashboard oppure consulta la documentazione ufficiale aggiornata. La community Cloudflare sul forum ufficiale e su Stack Overflow è inoltre molto attiva e offre spesso risposte rapide a problemi specifici di configurazione.

Per progetti complessi che coinvolgono più servizi Cloudflare contemporaneamente (CDN, Workers, WAF, Access, R2) conviene strutturare la configurazione come codice tramite Terraform o Pulumi. Questo permette versioning, code review, rollback atomici e deploy ripetibili tra environment. Per team con esigenze più semplici la gestione manuale via dashboard resta perfettamente valida, soprattutto se accompagnata da una checklist scritta delle impostazioni applicate. La scelta dell'approccio dipende dalle dimensioni del progetto e dal grado di automazione desiderato. L'importante è essere consistenti e mantenere tracciabilità delle modifiche effettuate.

Hai bisogno di aiuto?

Se vuoi configurare Cloudflare per il tuo sito con il team di G Tech Group, scrivici tramite il modulo di contatto.

Hai trovato utile quest'articolo?