Il server simula la richiesta preflight e la richiesta effettiva per determinare rapidamente se il problema è in Allow-Origin, Allow-Headers o credentials.
Simula lato server le richieste preflight CORS e le richieste reali, verifica uno per uno i 6 header di risposta, localizza con precisione errori di configurazione cross-origin e fornisce codice di correzione per più framework come Nginx/Node.js/Spring.
Questo è il problema CORS più classico! Perché Postman e curl non sono affatto soggetti alla politica della stessa origine del browser — sono client HTTP, non browser, non intercettano risposte, e non inviano neanche automaticamente richieste preflight OPTIONS. Gli errori cross-origin sono un meccanismo di sicurezza esclusivo del browser; solo l'ambiente di esecuzione JavaScript del browser effettua verifiche CORS. Che Postman possa connettersi dimostra solo che l'API stessa può restituire dati, non dimostra che la configurazione CORS sia corretta. Devi usare il browser, o questo strumento (che simula il flusso CORS del browser sul server) per verificare, e lì scoprirai il problema.
Il 99% degli errori CORS sono problemi di configurazione del backend (o problemi di configurazione nello strato Nginx/gateway), il frontend può fare ben poco. Il cuore di CORS è che il server «autorizza» il browser tramite header di risposta per permettere l'accesso cross-origin; il frontend può solo configurare withCredentials, impostare header di richiesta ecc., non può eludere le restrizioni di sicurezza del browser. I proxy del frontend di cui si parla su internet (proxy devServer, proxy inverso Nginx che proxano frontend e API sulla stessa origine) essenzialmente «ingannano» il browser facendogli credere che sia una richiesta stessa origine, non risolvono realmente il problema CORS; in produzione se frontend e backend sono origini diverse il backend deve comunque configurare CORS correttamente.
Perché GET normalmente soddisfa le condizioni di richiesta semplice, il browser invia la richiesta direttamente; mentre POST se invii Content-Type: application/json (il 90% delle API POST sono così), non appartiene più a richiesta semplice, attiverà preflight OPTIONS. La richiesta preflight richiede che il server restituisca gli header CORS corretti; molta gente ha configurato header CORS solo per GET/POST ma non ha gestito il metodo OPTIONS, o la risposta OPTIONS non ha header, quindi segnala errore. I metodi PUT/DELETE/PATCH di per sé non sono metodi semplici, attivano inevitabilmente preflight.
In ambiente di sviluppo ci sono diverse soluzioni: ① Proxy integrato nel framework (devServer.proxy di Vue CLI, server.proxy di Vite, proxy di Create React App): proxano le richieste di API sulla stessa origine del server di sviluppo del frontend, il browser crede che sia richiesta stessa origine senza cross-origin; ② Disattivare parametri di sicurezza del browser (per esempio Chrome con parametro di avvio --disable-web-security), solo per test temporanei locali, assolutamente non per navigazione normale; ③ Configurare CORS sul backend autorizzando l'origine localhost (consigliato, comportamento coerente con la produzione). In produzione il backend deve configurare CORS correttamente: configurare whitelist di origini autorizzate, impostare correttamente Allow-Methods/Allow-Headers/Allow-Credentials, aggiungere Vary: Origin, o usare gateway/Nginx per gestire CORS in modo unificato.
No, l'header di risposta Access-Control-Allow-Origin può avere un solo valore, sia un'origine specifica (come https://a.com), sia *. Il browser non accetta più origini (per esempio scrivere https://a.com,https://b.com è invalido, il browser lo considererà non corrispondente). Il modo corretto di configurazione multi-origine è: il server mantiene una whitelist di origini autorizzate, ogni volta che riceve una richiesta legge il valore di Origin nell'header di richiesta, verifica se quell'Origin è nella whitelist, se sì imposta Access-Control-Allow-Origin come quel valore di Origin specifico, e restituisce contemporaneamente l'header Vary: Origin; se non c'è, non restituisce header CORS o restituisce errore. Non provare a restituire più header Allow-Origin o separare più valori con virgola, il browser non li riconosce.
La richiesta preflight OPTIONS non ha bisogno di restituire nessuna logica di business né corpo di risposta, ha solo bisogno di restituire gli header di risposta CORS corretti e codice di stato 200/204 è sufficiente. Il browser ricevendo gli header CORS corretti considera che il preflight è passato, non leggerà il contenuto del body della risposta OPTIONS. Quindi la migliore pratica è: intercettare direttamente le richieste OPTIONS nello strato Nginx/gateway, restituire 204 No Content e gli header CORS corretti, senza inoltrare al server applicativo backend; questo alleggerisce il carico del backend ed evita anche errori 405 causati da route backend che non supportano OPTIONS. Ma assicurati che gli header CORS della risposta OPTIONS siano coerenti con gli header CORS della richiesta reale.
Le richieste cross-origin con Cookie richiedono di soddisfare contemporaneamente tre condizioni: ① XMLHttpRequest.withCredentials = true nel frontend o credentials: 'include' in fetch; ② Header di risposta backend Access-Control-Allow-Credentials: true; ③ Access-Control-Allow-Origin non può essere *, deve essere origine specifica. Le tre condizioni sono indispensabili. Inoltre fai attenzione agli attributi dei Cookie: il Cookie deve avere impostato SameSite=None; Secure (ambiente HTTPS) per poter essere portato in richieste cross-origin; se il Cookie è SameSite=Lax o Strict, in richieste cross-origin non verrà portato; l'attributo Domain del Cookie deve essere configurato correttamente; fai anche attenzione all'impatto delle politiche sui Cookie di terze parti (browser come Chrome hanno restrizioni sui Cookie di terze parti).
CORS è l'allentamento delle restrizioni di accesso cross-origin, CSRF è un attacco di falsificazione di richiesta tra siti, sono concetti diversi. Configurare CORS correttamente non causa direttamente vulnerabilità CSRF — perché CORS permette solo a JS di leggere risposte, mentre CSRF è quando un attaccante induce l'utente a inviare richieste a sua insaputa (come tag img, invio automatico di moduli), queste richieste anche senza CORS vengono inviate portando Cookie. Difendere dal CSRF richiede di usare CSRF Token, SameSite Cookie, verificare Origin/Referer e altre soluzioni, non si può difendere dal CSRF disabilitando CORS. Ma se durante la configurazione di CORS imposti Allow-Origin come * e autorizzi le credenziali, amplificherà effettivamente il rischio CSRF, ecco perché in scenari con credenziali non si può assolutamente usare *, devi restringere strettamente la whitelist di origini.
Il caricamento di risorse cross-origin con normali tag <img>, <script>, <link> (immagini CDN, script JS, CSS) di default non ha problemi CORS; queste sono «risorse incorporate» non «richieste AJAX», il browser permette di caricarle ma JS non può leggerne il contenuto. Ma se vuoi manipolare immagini cross-origin in Canvas, o caricare queste risorse con fetch/XHR e leggerne il contenuto, allora hai bisogno di CORS, e contemporaneamente devi aggiungere l'attributo crossorigin sul tag. Il download di file cross-origin (clic su tag a per scaricare) di default non richiede neanche CORS. I reindirizzamenti influenzano CORS: se la richiesta preflight OPTIONS restituisce un reindirizzamento 3xx, il browser la rifiuterà direttamente (Preflight redirect is not allowed); se il reindirizzamento della richiesta reale è tra origini diverse, ogni salto deve restituire correttamente gli header CORS.
Punti chiave della configurazione consigliata in Nginx: ① Usare la direttiva map per corrispondere con whitelist di Origins, impostando dinamicamente la variabile $cors_origin; ② Le richieste OPTIONS restituiscono direttamente 204 senza inoltrare al backend; ③ add_header ricorda di aggiungere il parametro always per assicurarti che le risposte di errore portino anche l'header; ④ Aggiungere Vary: Origin; ⑤ Configurare correttamente Allow-Methods/Allow-Headers/Credentials. Puoi trovare configurazioni di esempio nelle raccomandazioni di correzione dei risultati di rilevazione di questo strumento; forniamo frammenti di configurazione verificati per i principali framework come Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin.
Passaggi per verificare CORS: ① Prima usa la rilevazione online di questo strumento, inserisci URL, Origin, metodo, header, opzione credenziali, guarda se ogni verifica del preflight e della richiesta reale passa; ② Apri il pannello Network di DevTools del browser, marca Disable cache per disabilitare la cache (evitando interferenza di cache vecchia), attiva la richiesta cross-origin, verifica che gli header di risposta del preflight OPTIONS e della richiesta reale siano corretti; ③ In Console guarda se ci sono errori correlati a CORS; ④ Prova diversi scenari: richieste GET senza header personalizzati, richieste POST con application/json, metodi PUT/DELETE, con Cookie/senza Cookie, con header personalizzati; ⑤ Simula una richiesta OPTIONS con curl: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint, verifica che gli header di risposta siano corretti.
Diversi browser hanno differenze nei dettagli di implementazione della specifica CORS: ① Safari ha restrizioni più severe su Max-Age della cache preflight (versioni vecchie solo 600 secondi), la politica dei Cookie (ITP anti-tracciamento intelligente) è anch'essa più severa, può causare problemi di Cookie cross-origin; ② Chrome ha verifiche più severe sui wildcard con credenziali, Allow-Headers/Allow-Methods non permettono neanche *, alcune versioni di Firefox possono essere più permissive; ③ Il vecchio IE (IE11) usa XDomainRequest invece di XMLHttpRequest standard, l'implementazione CORS ha molte trappole (per esempio non supporta header personalizzati, supporta solo GET/POST); ④ Diversi browser hanno differenze sottili nella gestione dell'header Vary, gestione dei reindirizzamenti, gestione degli header di sicurezza. La soluzione è configurare strettamente secondo la specifica CORS, non dipendere dal comportamento compatibile di un browser specifico.
Si consiglia di impostare tra 3600 (1 ora) e 86400 (24 ore). Impostare troppo corto (come 60 secondi): la cache preflight scade velocemente, inviando frequentemente richieste OPTIONS, aumentando il tempo di richiesta e la pressione del server, l'impatto è notevole in ambienti di rete mobile debole. Impostare troppo lungo (come 31536000, cioè un anno): se aggiorni la configurazione CORS (per esempio aggiungendo metodi autorizzati, header), il vecchio risultato preflight in cache nel browser dell'utente può impiegare molto tempo a scadere, durante quel periodo appariranno problemi di configurazione che non ha effetto. Inoltre Chrome e Firefox troncheranno automaticamente i valori che superano 86400 secondi a 86400 secondi, per quanto tu lo imposti non serve. In ambiente di sviluppo puoi impostare -1 per disabilitare la cache preflight, facilitando il debug.
WebSocket (ws:// e wss://) non sono soggetti al meccanismo CORS HTTP, perché WebSocket è un protocollo indipendente, non sono richieste HTTP AJAX. Ma la fase di handshake di WebSocket è una richiesta HTTP; il server può verificare l'header Origin per decidere se autorizzare la connessione — questo è un controllo di permessi a livello WebSocket, non è CORS standard, ma il principio è simile. Se la connessione WebSocket viene rifiutata, devi verificare la configurazione di verifica Origin del server WebSocket, non gli header CORS HTTP. Librerie come Socket.IO possono avere il proprio modo di configurare il cross-origin, simile alla configurazione CORS standard ma non esattamente uguale. Inoltre, altre API del browser come HTTP/2 Server Push, WebRTC hanno anch'esse il proprio controllo di permessi, non seguono completamente il CORS HTTP.
Questo strumento sul server simula strettamente secondo la specifica W3C CORS il flusso di preflight e richiesta reale del browser, la logica di verifica degli header CORS è fondamentalmente coerente con i browser moderni. Se lo strumento rileva che passa ma il browser segnala ancora errore, le possibili cause sono: ① Il browser ha messo in cache risultati preflight o risposte vecchie, fai ricaricamento forzato Ctrl+F5 o cancella la cache e riprova; ② Estensioni del browser (ad blocker, protezione privacy, plugin di sicurezza) hanno modificato o intercettato la richiesta; ③ L'Origin, gli header di richiesta, il metodo, l'opzione credenziali che hai scritto nello strumento non sono coerenti con quello che il frontend invia realmente (per esempio il frontend porta realmente un header personalizzato che non hai aggiunto nello strumento); ④ Cache incoerente sui nodi CDN/proxy, il nodo a cui lo strumento chiede e il nodo a cui il browser chiede restituiscono risultati diversi; ⑤ Il browser ha politiche di sicurezza speciali (come le richieste a contenuto misto HTTP in pagine HTTPS sono bloccate, restrizioni speciali del protocollo file:// di file locali).
