Simula preflight i sol·licituds reals des del costat del servidor, identifica ràpidament si el problema és a Allow-Origin, Allow-Headers o credentials.
El servidor simula CORS preflight i sol·licituds reals de manera real, comprova 6 capçaleres de resposta una per una, troba la ubicació exacta dels errors de configuració cross-origin, proporciona codi de correcció per a diversos frameworks com Nginx/Node.js/Spring.
Aquest és el problema CORS més clàssic! Perquè Postman i curl no estan en absolut limitats per la Same-Origin Policy del navegador — són clients HTTP, no navegadors, no bloquejaran respostes, ni enviaran automàticament sol·licituds preflight OPTIONS. L'error cross-origin és un mecanisme de seguretat que només existeix al navegador, només l'entorn d'execució JavaScript del navegador realitza comprovacions CORS. Que Postman aconsegueixi cridar només pot demostrar que l'API mateixa pot retornar dades, no pot demostrar que la configuració CORS sigui correcta. Cal utilitzar el navegador, o aquesta eina (el servidor simula el procés CORS del navegador) per comprovar, aleshores trobaràs el problema.
El 99% dels errors CORS són problemes de configuració del backend (o problemes de configuració de Nginx/gateway), el que pot fer el frontend és molt limitat. L'essència de CORS és que el servidor「dóna autorització」al navegador mitjançant capçaleres de resposta per permetre l'accés cross-origin, el frontend només pot establir withCredentials, establir capçaleres de sol·licitud aquestes coses, no pot saltar les limitacions de seguretat del navegador. El que es diu a internet que el frontend utilitza proxy (devServer proxy, reverse proxy Nginx que proxyja el frontend i l'API al mateix origen) bàsicament és「enganyar」el navegador fent-li creure que és una sol·licitud del mateix origen, no resol realment el problema CORS, si en l'entorn de producció el frontend i el backend són d'origen diferent encara cal que el backend configuri CORS correctament.
Perquè GET normalment compleix les condicions de sol·licitud simple, el navegador envia la sol·licitud directament; però per a POST si envies Content-Type: application/json (el 90% de les API POST són així), ja no serà una sol·licitud simple, activarà preflight OPTIONS. La sol·licitud preflight requereix que el servidor retorni capçaleres CORS correctes, molta gent només configura capçaleres CORS per a GET/POST però no processa el mètode OPTIONS, o la resposta OPTIONS no té capçaleres, per tant ocorre l'error. Mètodes com PUT/DELETE/PATCH per si mateixos no són mètodes simples, segur que activen preflight.
L'entorn de desenvolupament té diverses opcions: ①proxy integrat del framework (devServer.proxy de Vue CLI, server.proxy de Vite, proxy de Create React App): proxyja les sol·licituds API al mateix origen que el servidor de desenvolupament del frontend, el navegador pensa que és una sol·licitud del mateix origen per tant no és cross-origin; ②desactivar els paràmetres de seguretat del navegador (com Chrome afegint el paràmetre d'inici --disable-web-security), limitat a proves temporals locals, absolutament no l'utilitzis per a navegació normal; ③el backend configura CORS permetent l'origen localhost (recomanat, coherent amb el comportament de l'entorn de producció). L'entorn de producció requereix obligatòriament que el backend configuri CORS correctament: configurar la whitelist d'orígens permesos, establir Allow-Methods/Allow-Headers/Allow-Credentials correctament, afegir Vary: Origin, o utilitzar gateway/Nginx per gestionar CORS centralment.
No es pot, la capçalera de resposta Access-Control-Allow-Origin només pot tenir un valor, sigui un origen específic (com https://a.com), o *. El navegador no accepta múltiples orígens (com escriure https://a.com,https://b.com no és vàlid, el navegador el considerarà no coincident). La manera correcta de configurar múltiples orígens és: el servidor manté una llista whitelist d'orígens permesos, cada vegada que rep una sol·licitud llegeix el valor d'Origin de la capçalera de la sol·licitud, comprova si aquest Origin és a la whitelist, si hi és estableix Access-Control-Allow-Origin al valor d'Origin específic corresponent, alhora retorna la capçalera Vary: Origin; si no hi és no retornis capçaleres CORS o retorna un error. No intentis retornar múltiples capçaleres Allow-Origin ni utilitzar comes per separar múltiples valors, el navegador no ho acceptarà.
La sol·licitud preflight OPTIONS no cal que retorni lògica de negoci ni cap cos de resposta, n'hi ha prou amb retornar les capçaleres de resposta CORS correctes i un codi d'estat 200/204. Quan el navegador rep les capçaleres CORS correctes considerarà que el preflight ha passat, no llegirà el cos de la resposta OPTIONS. Per tant la millor pràctica és: Blocar la sol·licitud OPTIONS directament a la capa Nginx/gateway, retornant 204 No Content i les capçaleres CORS correctes, sense necessitat de passar al servidor d'aplicacions backend, això redueix la càrrega del backend i evita errors 405 perquè el router del backend no admet OPTIONS. Però cal assegurar que les capçaleres CORS de la resposta OPTIONS siguin coherents amb les capçaleres CORS de la sol·licitud real.
Les sol·licituds cross-origin amb Cookie han de complir tres condicions simultàniament: ①XMLHttpRequest.withCredentials = true del frontend o credentials: 'include' de fetch; ②la capçalera de resposta del backend Access-Control-Allow-Credentials: true; ③Access-Control-Allow-Origin no pot ser *, ha de ser un origen específic. Les tres condicions no en pot faltar cap. A més cal parar esment als atributs de Cookie: la Cookie ha d'establir SameSite=None; Secure (entorn HTTPS) per poder enviar-se en sol·licituds cross-origin; si la Cookie és SameSite=Lax o Strict, les sol·licituds cross-origin no s'enviaran; l'atribut Domain de la Cookie s'ha d'establir correctament; també cal parar esment a l'impacte de la política de Cookies de tercers (navegadors com Chrome tenen restriccions sobre Cookies de tercers).
CORS és relaxar les restriccions d'accés cross-origin, CSRF és un atac de falsificació de sol·licituds entre llocs, són conceptes diferents. Configurar CORS correctament no causarà directament vulnerabilitats CSRF — perquè CORS només permet que JS llegeixi respostes, mentre que CSRF és quan un atacant persuadeix l'usuari d'enviar una sol·licitud sense adonar-se'n (com una etiqueta img, un formulari enviat automàticament), aquesta sol·licitud s'enviarà portant Cookie encara que no hi hagi CORS. La defensa contra CSRF necessita utilitzar CSRF Token, SameSite Cookie, comprovar Origin/Referer i altres esquemes, no es pot confiar en desactivar CORS per prevenir CSRF. Però si configures CORS establint Allow-Origin a * i permetent enviar credentials, realment augmentarà el risc de CSRF, per tant en escenaris amb credentials absolutament no es pot utilitzar *, cal restringir estrictament la whitelist d'orígens.
Carregar recursos cross-origin amb etiquetes <img>, <script>, <link> habituals (imatges CDN, scripts JS, CSS) per defecte no tindran problemes CORS, aquests són「recursos incrustats」no「sol·licituds AJAX」, el navegador permet carregar-los però JS no pot llegir-ne el contingut. Però si vols manipular imatges cross-origin a Canvas, o carregar aquests recursos amb fetch/XHR i llegir-ne el contingut, cal CORS, alhora has d'afegir l'atribut crossorigin a l'etiqueta. Descarregar fitxers cross-origin (clic per descarregar amb una etiqueta a) per defecte tampoc necessita CORS. Les redireccions afectaran CORS: si la sol·licitud preflight OPTIONS retorna una redirecció 3xx, el navegador la rebutjarà directament (Preflight redirect is not allowed); si la redirecció de la sol·licitud real és cross-origin, cal que cada salt retorni les capçaleres CORS correctes.
Els punts principals de la configuració Nginx recomanada: ①utilitzar la directiva map per concordar amb la whitelist d'Origin, establint la variable $cors_origin dinàmicament; ②les sol·licituds OPTIONS retornen 204 directament sense passar al backend; ③add_header recorda afegir el paràmetre always per assegurar que les respostes d'error també tinguin capçaleres; ④afegir Vary: Origin; ⑤configurar Allow-Methods/Allow-Headers/Credentials correctament. Podeu trobar exemples de configuració en els suggeriments de correcció dels resultats de comprovació d'aquesta eina, per a frameworks populars com Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin, hem preparat fragments de configuració verificats.
Passos de verificació CORS: ①Comprova en línia amb aquesta eina primer, introdueix URL, Origin, mètode, capçaleres, opció credentials, mira si cada comprovació de preflight i sol·licitud real passa; ②obre el panell Network de DevTools del navegador, marca Disable cache per desactivar la memòria cau (evitant interferències de memòries cau antigues), dispara la sol·licitud cross-origin, comprova si les capçaleres de resposta del preflight OPTIONS i la sol·licitud real són correctes; ③mira la Console si hi ha errors relacionats amb CORS; ④prova diversos escenaris: sol·licitud GET sense capçaleres personalitzades, sol·licitud POST amb application/json, mètodes PUT/DELETE, amb Cookie/sense Cookie, amb capçaleres personalitzades; ⑤simula la sol·licitud OPTIONS amb curl: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint, comprova si les capçaleres de resposta són correctes.
Diferents navegadors tenen diferents detalls d'implementació de l'especificació CORS: ①Safari té límits més estrictes sobre Max-Age de la memòria cau preflight (les versions inicials només eren 600 segons), la política de Cookies (ITP Intelligent Tracking Prevention) també és més estricta, pot causar problemes de Cookie cross-origin; ②Chrome comprova els comodins més estrictament quan s'enviïn credentials, Allow-Headers/Allow-Methods tampoc permeten utilitzar *, algunes versions de Firefox poden ser més laxes; ③IE antic (IE11) utilitza XDomainRequest en lloc de XMLHttpRequest estàndard, la implementació CORS té molts paranys (com no admetre capçaleres personalitzades, només admetre GET/POST); ④diferents navegadors tenen petites diferències en processar capçaleres Vary, processar redireccions, processar capçaleres de seguretat. La manera de corregir és configurar estrictament segons l'especificació CORS, no confiïs en el comportament de compatibilitat de cap navegador.
Es recomana establir entre 3600 (1 hora) i 86400 (24 hores). Establir massa curt (com 60 segons): la memòria cau preflight expira ràpidament, envia sol·licituds OPTIONS sovint, augmenta el temps de sol·licitud i la càrrega del servidor, l'impacte és clar en entorns de xarxa mòbil febles. Establir massa llarg (com 31536000 és a dir un any): si actualitzes la configuració CORS (com afegir mètodes, capçaleres permeses), els resultats preflight antics guardats en memòria cau pels navegadors dels usuaris poden trigar molt a expirar, en aquest període hi haurà problemes de configuració que no s'aplica. A més Chrome i Firefox tallaran automàticament els valors que superin 86400 segons a 86400 segons, establir més llarg tampoc serveix. L'entorn de desenvolupament pot establir a -1 per desactivar la memòria cau preflight, facilitant la depuració.
WebSocket (ws:// i wss://) no està limitat pel mecanisme CORS HTTP, perquè WebSocket és un protocol independent, no una sol·licitud HTTP AJAX. Però la fase d'encaix de mans de WebSocket és una sol·licitud HTTP, el servidor pot comprovar la capçalera Origin per decidir si permet la connexió — aquest és un control de permís a nivell de WebSocket, no CORS estàndard, però el principi és similar. Si la connexió WebSocket és rebutjada, cal comprovar la configuració de verificació d'Origin del costat del servidor WebSocket, en lloc de les capçaleres CORS HTTP. Llibreries com Socket.IO poden tenir les seves pròpies maneres de configurar cross-origin, similars a la configuració CORS estàndard però no completament iguals. A més, HTTP/2 Server Push, WebRTC i altres API del navegador també tenen els seus propis controls de permís, no segueixen completament CORS HTTP.
Aquesta eina al servidor simula estrictament el procés preflight i les sol·licituds reals del navegador segons l'especificació W3C CORS, la lògica de comprovació de capçaleres CORS és generalment coherent amb els navegadors moderns. Si la comprovació de l'eina passa però el navegador encara reporta errors, les causes possibles són: ①el navegador guarda en memòria cau resultats preflight o respostes antigues, prem Ctrl+F5 per actualitzar forçosament o neteja la memòria cau i torna a provar; ②extensions del navegador (bloquejadors d'anuncis, protecció de privacitat, plugins de seguretat) modifiquen o bloquegen sol·licituds; ③Origin, capçaleres de sol·licitud, mètode, opció credentials que has omplert a l'eina no són coherents amb el que realment envia el frontend (per exemple el frontend realment envia algunes capçaleres personalitzades però tu no les has afegit a l'eina); ④la memòria cau dels nodes CDN/proxy no és coherent, el node que demana l'eina i el node que demana el navegador retornen resultats diferents; ⑤el navegador té polítiques de seguretat especials (com una pàgina HTTPS demana contingut mixt HTTP que es bloqueja, restriccions especials del protocol de fitxers locals file://)
