Skip to content

Glossary

CORS

Cross-Origin Resource Sharing

By Published Updated

CORS (Cross-Origin Resource Sharing) è il meccanismo del browser che controlla quando JavaScript da un’origine può leggere le risposte da un’altra. Per impostazione predefinita, i browser bloccano le risposte XHR/fetch cross-origin — gli header CORS dal server consentono un accesso controllato.

I due principali header di risposta:

  • Access-Control-Allow-Origin: quali origini possono leggere la risposta. Può essere un’origine specifica o * (qualsiasi).
  • Access-Control-Allow-Credentials: se i cookie possono fluire con le richieste cross-origin. true richiede che l’origine sia specifica, non *.

Per le richieste che non sono “semplici” (header personalizzati, metodi non GET/POST, corpi JSON), il browser invia prima una richiesta OPTIONS di preflight per verificare cosa è consentito. Il server risponde con Access-Control-Allow-Methods e Access-Control-Allow-Headers; la richiesta effettiva viene inviata solo se il preflight ha successo.

Equivoci comuni: CORS non è un meccanismo di sicurezza lato server — è una restrizione applicata dal browser che protegge gli utenti da un sito che legge dati per loro conto da un altro sito. I server possono comunque ricevere ed elaborare richieste cross-origin; CORS controlla solo se il browser restituisce la risposta al JS chiamante.

Cosa significa “origine” con precisione: la tupla (schema, host, porta). http://example.com e https://example.com sono origini diverse (schema diverso). https://api.example.com e https://example.com sono origini diverse (sottodominio diverso). https://example.com:8080 e https://example.com sono origini diverse (porta diversa). Questa è la same-origin policy su cui CORS aggiunge eccezioni. Internet Explorer ignorava la parte della porta — una peculiarità che ha prodotto anni di bug cross-browser fino al ritiro di IE.

Problemi comuni in produzione: il carattere jolly Access-Control-Allow-Origin: * blocca le credenziali per specifica; se si ha bisogno di cookie su una richiesta cross-origin bisogna restituire l’header Origin della richiesta specificamente. Aggiungere un header Authorization trasforma la richiesta da “semplice” a “con preflight”, raddoppiando i round-trip — la memorizzazione nella cache del preflight tramite Access-Control-Max-Age (fino a 7200 secondi in Chrome, 600 in Firefox) è la mitigazione standard. Infine, l’errore CORS del browser nella console DevTools è genuinamente la decisione del browser — i log del server mostreranno che la richiesta ha raggiunto il backend ed è stata elaborata normalmente; la risposta è stata semplicemente scartata lato client. Riferimento: WHATWG Fetch — HTTP-CORS Protocol.

Esempio pratico: un POST JSON con preflight

Una SPA su https://app.example.com invia un JSON POST con un token bearer a https://api.example.com/v1/orders. Poiché la richiesta usa Content-Type: application/json e un header Authorization, non è semplice. Il browser invia prima OPTIONS /v1/orders con Origin: https://app.example.com, Access-Control-Request-Method: POST, e Access-Control-Request-Headers: authorization,content-type. Il server risponde 204 con Access-Control-Allow-Origin: https://app.example.com, Access-Control-Allow-Methods: POST, Access-Control-Allow-Headers: authorization,content-type, e Access-Control-Max-Age: 600. Solo allora viene inviato il POST reale. Impostare Max-Age: 600 evita il preflight per i successivi 10 minuti, eliminando un round-trip da ogni chiamata successiva — misurabile come un taglio di 50-100 ms su connessioni transatlantiche.

Quando CORS non è sufficiente

CORS protegge gli utenti dalle letture cross-origin; non protegge i server da richieste indesiderate. Gli endpoint che modificano lo stato richiedono ancora token CSRF o cookie SameSite, e l’autenticazione richiede ancora la corretta convalida dei token lato server. Un’API pubblica dietro Access-Control-Allow-Origin: * è pubblicamente accessibile da chiunque — CORS ha semplicemente consentito al browser di renderlo evidente. Per ulteriori informazioni architetturali vedere il riferimento CORS di MDN, che rispecchia la specifica WHATWG con esempi pratici.

Frequently asked questions

Cos’è CORS?
CORS (Cross-Origin Resource Sharing) è un meccanismo di sicurezza del browser che controlla quali richieste HTTP cross-origin JavaScript può effettuare. Il browser blocca le richieste da un’origine (es. app.example.com) a un’altra (api.other.com) a meno che il server non risponda con l’appropriato header Access-Control-Allow-Origin.
Come funziona CORS in pratica?
Un’app React su https://app.example.com effettua una fetch da https://api.example.com/data. Il browser aggiunge un header Origin; l’API deve rispondere con Access-Control-Allow-Origin: https://app.example.com (o *). Senza quell’header, il browser blocca la risposta anche se il server l’ha inviata.
Qual è la differenza tra una richiesta semplice e un preflight CORS?
Le richieste semplici (GET/POST con header standard e tipi di contenuto) vengono inviate direttamente con l’header Origin. Le richieste preflight vengono inviate automaticamente dal browser prima di richieste complesse (DELETE, header personalizzati, corpo JSON) come una chiamata OPTIONS per chiedere al server se la richiesta reale è consentita.
CORS protegge il server dall’essere acceduto direttamente?
No — CORS si applica solo a JavaScript basato su browser. curl, Postman e le chiamate server-to-server ignorano completamente CORS. CORS protegge il browser dell’utente dall’essere indotto a inviare richieste autenticate cross-origin; non protegge l’endpoint API dall’accesso diretto.

Related

Published May 15, 2026 · Last reviewed May 31, 2026