Errore CORS: cosa significa «blocked by CORS policy» e cosa fare

Se nella console del browser hai trovato un messaggio come has been blocked by CORS policy, la tua app sta provando a leggere dati da un altro indirizzo e il browser glielo impedisce, perché quel server non ha dato il permesso. L'errore CORS non è un guasto del tuo computer né un problema di connessione: è una regola di sicurezza. Quasi sempre si risolve sul server che riceve la richiesta, o spostando la chiamata lato server, non ritoccando l'interfaccia.

Cos'è il CORS spiegato semplice

Ogni sito ha un'«origine»: la combinazione di protocollo (https), dominio (tuosito.it) e, a volte, porta. Per sicurezza i browser seguono una regola chiamata same-origin policy: una pagina può leggere liberamente le risposte che arrivano dalla sua stessa origine, ma non quelle di origini diverse.

CORS (Cross-Origin Resource Sharing, cioè «condivisione di risorse tra origini diverse») è il modo in cui un server dice al browser: «questi siti hanno il permesso di leggere le mie risposte». Pensa a un buttafuori con una lista di invitati. La tua app si presenta alla porta del server; se il suo nome non è in lista, il browser non le consegna la risposta.

Il permesso viaggia in un'intestazione della risposta, cioè un'etichetta tecnica che il server aggiunge, chiamata Access-Control-Allow-Origin. Se manca, o contiene un indirizzo diverso dal tuo, il browser blocca tutto.

Cosa significa «blocked by CORS policy»

Un dettaglio importante: spesso la richiesta arriva davvero al server. È il browser che, ricevuta la risposta senza permesso, si rifiuta di passarla alla tua app. Per questo il problema non si risolve dal codice della pagina: è il server che deve autorizzare la tua origine.

Come si presenta l'errore CORS

In Chrome e negli altri browser basati su Chromium il messaggio tipico è questo:

Access to fetch at 'https://api.esempio.com/dati' from origin
'https://tuosito.it' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

Varianti frequenti:

• Response to preflight request doesn't pass access control check
• The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin
• in Firefox: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ...

Nel codice, invece, l'app riceve solo un generico TypeError: Failed to fetch. Per motivi di sicurezza il browser non dice al codice perché la richiesta è fallita: i dettagli sono visibili solo nella console. Ecco perché l'AI, se le dici soltanto «Failed to fetch», spesso tira a indovinare.

La richiesta di prova («preflight»)

Per alcune richieste, per esempio quelle che inviano dati in formato JSON o un'intestazione di autorizzazione, il browser manda prima una richiesta di prova con il metodo OPTIONS. È come telefonare prima di presentarsi: «posso venire con questi dati?». Se il server non risponde correttamente a questa telefonata, la richiesta vera non parte nemmeno. Molti errori CORS nelle app create con l'AI nascono proprio qui.

Perché succede nelle app create con l'AI

Le cause più comuni sono queste.

• Chiamate a un servizio esterno direttamente dal browser. L'AI scrive codice che contatta un'API esterna (un'API è il «telefono» con cui due programmi si parlano) direttamente dalla pagina. Molti servizi non lo permettono di proposito, anche perché richiederebbe di mettere la chiave segreta nel frontend, cioè nella parte dell'app che gira nel browser di chiunque. Ne parliamo nella guida sulle chiavi API esposte nel frontend.
• Una funzione lato server che non gestisce il CORS. Se la tua app usa funzioni serverless, cioè piccoli programmi che girano sui server del fornitore, come le Edge Functions di Supabase, queste devono rispondere alla richiesta OPTIONS e aggiungere le intestazioni CORS a ogni risposta. Se l'AI se ne dimentica, il blocco è garantito.
• Il dominio è cambiato. In anteprima l'app gira su un indirizzo, online su un altro. Se il server autorizza solo l'indirizzo di anteprima o localhost, sul dominio vero compare l'errore. È uno dei motivi per cui un'app funziona in anteprima ma non online.
• Con o senza www, http o https. Per il browser https://tuosito.it e https://www.tuosito.it sono due origini diverse. Basta autorizzarne una sola per vedere l'errore sull'altra.
• Un errore del server travestito da CORS. Se la funzione va in crash e restituisce un errore 500 senza intestazioni CORS, il browser segnala un problema di CORS. In realtà il guasto è altrove, e lo trovi nei log del server.

Come capire qual è il tuo caso

Bastano pochi minuti e il browser:

1. Apri l'app, premi F12 e vai nella scheda «Console». Leggi l'indirizzo citato dopo Access to fetch at: è il server che sta rifiutando.
2. Passa alla scheda «Network» (Rete), ricarica e cerca la richiesta in rosso. Guarda il codice di stato e controlla se prima di quella vera c'è una richiesta OPTIONS fallita.
3. Chiediti: quel server è tuo (una tua funzione, il tuo backend) o di un servizio esterno?

Cosa puoi fare tu

Ecco i passi concreti, dal più semplice.

1. Se il server è un servizio esterno, non cercare di forzarlo. La soluzione corretta è spostare la chiamata in una funzione lato server tua, che parla con il servizio e restituisce il risultato alla pagina. Così proteggi anche la chiave segreta. Approfondiamo il tema nella guida su come integrare servizi esterni nella tua app.
2. Se il server è una tua funzione, chiedi all'AI di gestire la richiesta OPTIONS e di aggiungere le intestazioni CORS a tutte le risposte, comprese quelle di errore. Per le Edge Functions, la documentazione di Supabase spiega come farlo e mette a disposizione intestazioni già pronte nella libreria ufficiale.
3. Controlla l'elenco dei domini autorizzati. Deve contenere il dominio definitivo, con e senza www, in https.
4. Leggi i log della funzione se vedi un errore 500. Correggere il crash spesso fa sparire anche il CORS.
5. Ripubblica e prova in una finestra in incognito, per evitare che il browser usi risposte vecchie salvate in memoria.

Un esempio di richiesta all'AI:

La chiamata a https://xyz.supabase.co/functions/v1/invia-ordine
fallisce con "Response to preflight request doesn't pass access
control check". Fai in modo che la funzione risponda alle richieste
OPTIONS e aggiunga le intestazioni CORS a tutte le risposte, anche
in caso di errore. Autorizza solo https://tuosito.it e
https://www.tuosito.it.

Cosa evitare

• Estensioni del browser che «disattivano il CORS». Funzionano solo sul tuo computer: i tuoi utenti continueranno a vedere l'errore.
• mode: 'no-cors' nel codice. Fa sparire il messaggio, ma la risposta diventa illeggibile: la tua app non riceve i dati.
• Proxy CORS pubblici trovati online. Fanno passare i tuoi dati, e a volte le tue chiavi, dal server di uno sconosciuto.
• Access-Control-Allow-Origin: * ovunque. Vuol dire «chiunque può leggere», e se la richiesta usa i cookie per il login il browser lo rifiuta comunque. Meglio autorizzare solo i tuoi domini.

Quando conviene farti aiutare

Se hai provato i passi qui sopra e l'errore resta, o se non è chiaro quale server stia bloccando la richiesta, è il momento di farsi dare una mano. Lo stesso vale se la soluzione richiede di spostare chiamate e chiavi in una funzione lato server e non sai da dove cominciare: è un lavoro piccolo, ma va fatto con attenzione per non lasciare chiavi esposte.

Di solito partiamo dalla console e dai log, individuiamo il server che blocca e sistemiamo la configurazione in modo sicuro. Se vuoi capire insieme cosa sta succedendo nella tua app, prenota una call gratuita di 20 minuti.