Vai al contenuto

Verifica CORS

CORS Tester

Invia la preflight che manderebbe un browser da un’origine scelta più una GET con quell’Origin, e spiega secondo le regole dello standard Fetch quale intestazione ha bloccato la richiesta.

Un errore CORS nella console nomina l’intestazione che mancava e quasi mai la ragione, e la richiesta che il browser ha davvero inviato non è quella che sta nel codice. Questo strumento invia il preflight che un browser invierebbe da un’origine scelta da chi lo usa, poi una GET che porta quell’Origin, e legge il risultato secondo le regole dello standard Fetch.

☁️ Usa il nostro servercorshttpdebugweb

Questa richiesta la fa il nostro server al posto tuo. Gli inviamo solo l’URL, l’origine, il metodo e i nomi di header che scrivi: nessuno dei tuoi cookie e nessuno stato di accesso parte insieme. Il server si collega soltanto a indirizzi pubblici e rifiuta quelli privati e interni.

Un server manda il preflight (OPTIONS) che manderebbe un browser e poi la richiesta vera e propria, e il risultato viene giudicato con le regole CORS dello standard Fetch. La richiesta vera è sempre una GET (o una HEAD): non spara una PUT o una DELETE all’API di qualcun altro al posto tuo.

Lo schema, l’host e la porta della pagina web che fa la chiamata.

application/json fa sempre scattare un preflight.

Come si usa

  1. Inserire l’URL e l’origine

    L’origine è il sito *da cui* partirebbe la richiesta: la pagina che fa la chiamata, non l’API. Invertire le due è il motivo più frequente per cui una prova non concorda con il browser.

  2. Aggiungere il metodo e le intestazioni che si usano davvero

    Un preflight avviene solo per le richieste non semplici. A farlo scattare sono `Content-Type: application/json` o un’intestazione `Authorization`, quindi lasciarli fuori significa mettere alla prova una richiesta che non si fa mai.

  3. Leggere quale regola non è stata soddisfatta

    Il risultato nomina il controllo preciso — origine non consentita, metodo non elencato, intestazione non elencata, credenziali con origine jolly — invece di riferire un fallimento generico.

Domande frequenti

Qui passa ma il browser continua a bloccarla.

Va controllato che metodo, intestazioni e modalità delle credenziali corrispondano esattamente a quello che invia il codice, e che il server non faccia variare la risposta in base al cookie o allo user agent. Questa prova parte da un server, quindi una risposta che dipende da una sessione attiva sarà diversa.

Perché `Access-Control-Allow-Origin: *` non funziona con i cookie?

Lo standard lo vieta. Con `credentials: 'include'` l’origine deve essere restituita alla lettera e `Access-Control-Allow-Credentials: true` deve essere presente. Un jolly con le credenziali è rifiutato per progetto, non per un difetto.

Gira nel mio browser?

No: gira da un server, perché un browser non può fare la richiesta che il CORS blocca. Vuol dire che vede la risposta pubblica, senza i cookie di chi lo usa e senza la sua posizione di rete.

Posso mettere alla prova un indirizzo interno?

No. La richiesta parte da un server che non può raggiungere la rete locale, e gli indirizzi che si risolvono soltanto al suo interno falliranno a prescindere dalla loro configurazione CORS.

Può ricevere da

Dopo

Questi accettano ciò che produce questo strumento, così il risultato può passare direttamente.