Tutti gli articoli

CORS: perché il browser blocca richieste "normali" verso un altro dominio

Molti hosting italiani, soprattutto quelli condivisi diffusi tra le piccole agenzie web, girano ancora su Apache: l'errore classico è aggiungere Header set Access-Control-Allow-Origin "*" nel file .htaccess per risolvere rapidamente un errore CORS, senza accorgersi che l'applicazione PHP sottostante imposta già lo stesso header via codice. Il risultato è un header duplicato nella risposta, che il browser rifiuta a prescindere, perché Access-Control-Allow-Origin deve comparire una sola volta con un solo valore.

La politica della stessa origine

Per impostazione predefinita, i browser applicano la Same-Origin Policy: il codice JavaScript di una pagina con una certa origine (dominio + schema + porta) non può leggere le risposte di richieste fatte verso un'origine diversa. È un meccanismo di sicurezza fondamentale che impedisce a uno script malevolo su un sito di rubare dati da un altro sito dove l'utente è autenticato.

Come CORS allenta questa politica

CORS (Cross-Origin Resource Sharing) è un insieme di header HTTP con cui un server autorizza esplicitamente certe origini esterne (o tutte) a leggere le sue risposte. L'header chiave è Access-Control-Allow-Origin, che indica quali domini hanno il permesso.

La trappola del wildcard con le credenziali

Quando una richiesta viene inviata con credentials: 'include' — necessario per mandare il cookie di sessione a un'API su un altro sottodominio — il browser rifiuta categoricamente di accettare Access-Control-Allow-Origin: * nella risposta. La specifica vieta esplicitamente di combinare un'origine jolly con le credenziali; il server deve restituire l'origine esatta della richiesta.

A cosa serve

  • Diagnosticare un errore CORS e capire esattamente quali header mancano sul server.
  • Individuare header CORS duplicati nella combinazione Apache più applicazione backend.
  • Capire la differenza tra richieste "semplici" e richieste preflight (OPTIONS).

CORS non protegge il server dagli attacchi

È un equivoco comune pensare che CORS sia una misura di sicurezza lato server — in realtà limita solo ciò che il JavaScript nel browser può leggere. Un aggressore che usa curl, Postman o uno script backend direttamente aggira completamente CORS, perché questi strumenti non applicano la politica della stessa origine. CORS non dovrebbe mai essere considerato un sostituto della vera autenticazione e autorizzazione sul server.

Prova lo strumento