Der Server simuliert die Preflight-Anfrage und die tatsächliche Anfrage, um schnell festzustellen, ob das Problem bei Allow-Origin, Allow-Headers oder credentials liegt.
Simuliert serverseitig CORS Preflight-Anfragen und echte Anfragen, prüft die 6 Antwort-Header einzeln, lokalisiert präzise Cross-Origin-Konfigurationsfehler und liefert Korrekturcode für mehrere Frameworks wie Nginx/Node.js/Spring.
Dies ist das klassischste CORS-Problem! Weil Postman und curl überhaupt nicht der Same-Origin-Policy des Browsers unterliegen — sie sind HTTP-Clients, keine Browser, sie fangen Antworten nicht ab, und senden auch nicht automatisch Preflight-Anfragen OPTIONS. Cross-Origin-Fehler sind ein ausschließlich dem Browser vorbehaltener Sicherheitsmechanismus; nur die JavaScript-Ausführungsumgebung des Browsers führt CORS-Prüfungen durch. Dass Postman eine Verbindung herstellen kann zeigt nur dass die API selbst Daten zurückgeben kann, zeigt nicht dass die CORS-Konfiguration korrekt ist. Sie müssen den Browser verwenden, oder dieses Tool (das den CORS-Fluss des Browsers auf dem Server simuliert) zur Überprüfung, und dort werden Sie das Problem entdecken.
99% der CORS-Fehler sind Backend-Konfigurationsprobleme (oder Konfigurationsprobleme in der Nginx/Gateway-Schicht), das Frontend kann sehr wenig tun. Der Kern von CORS ist dass der Server dem Browser über Antwort-Header «autorisiert» Cross-Origin-Zugriff zu erlauben; das Frontend kann nur withCredentials konfigurieren, Anfrage-Header setzen etc., es kann die Sicherheitsbeschränkungen des Browsers nicht umgehen. Die im Internet genannten Frontend-Proxys (devServer-Proxy, Nginx-Reverse-Proxy der Frontend und API auf denselben Ursprung proxien) «täuschen» im Wesentlichen den Browser indem sie ihn glauben lassen es sei eine Same-Origin-Anfrage, sie lösen das CORS-Problem nicht wirklich; in Produktion müssen bei unterschiedlichen Ursprüngen von Frontend und Backend das Backend trotzdem CORS korrekt konfigurieren.
Weil GET normalerweise die Bedingungen einer einfachen Anfrage erfüllt, der Browser sendet die Anfrage direkt; während POST wenn Sie Content-Type: application/json senden (90% der POST-APIs sind das), gehört nicht mehr zu einer einfachen Anfrage, löst Preflight OPTIONS aus. Die Preflight-Anfrage erfordert dass der Server korrekte CORS-Header zurückgibt; viele Leute haben CORS-Header nur für GET/POST konfiguriert aber die OPTIONS-Methode nicht verarbeitet, oder die OPTIONS-Antwort hat keine Header, deshalb wird ein Fehler gemeldet. Die Methoden PUT/DELETE/PATCH sind an sich keine einfachen Methoden, sie lösen unweigerlich Preflight aus.
In der Entwicklungsumgebung gibt es mehrere Lösungen: ① Integrierter Proxy des Frameworks (devServer.proxy von Vue CLI, server.proxy von Vite, Proxy von Create React App): Proxiert API-Anfragen auf denselben Ursprung wie der Frontend-Entwicklungsserver, der Browser glaubt es sei eine Same-Origin-Anfrage ohne Cross-Origin; ② Deaktivieren von Browser-Sicherheitsparametern (z.B. Chrome mit Startparameter --disable-web-security), nur für temporäre lokale Tests, absolut nicht für normales Browsen; ③ Konfigurieren von CORS im Backend unter Erlaubung des Localhost-Ursprungs (empfohlen, Verhalten konsistent mit Produktion). In Produktion muss das Backend CORS korrekt konfigurieren: Whitelist erlaubter Ursprünge konfigurieren, Allow-Methods/Allow-Headers/Allow-Credentials korrekt setzen, Vary: Origin hinzufügen, oder Gateway/Nginx zur einheitlichen CORS-Verwaltung verwenden.
Nein, der Antwort-Header Access-Control-Allow-Origin darf nur einen Wert haben, entweder einen spezifischen Ursprung (wie https://a.com), oder *. Der Browser akzeptiert keine mehreren Ursprünge (z.B. Schreiben von https://a.com,https://b.com ist ungültig, der Browser betrachtet es als nicht übereinstimmend). Die korrekte Art der Multi-Ursprung-Konfiguration ist: Der Server pflegt eine Whitelist erlaubter Ursprünge, bei jedem Empfang einer Anfrage liest er den Wert von Origin im Anfrage-Header, prüft ob dieser Origin in der Whitelist ist, wenn ja setzt er Access-Control-Allow-Origin auf diesen spezifischen Origin-Wert, gibt gleichzeitig den Header Vary: Origin zurück; wenn nicht, gibt er keine CORS-Header zurück oder gibt einen Fehler zurück. Versuchen Sie nicht mehrere Allow-Origin-Header zurückzugeben oder mehrere Werte durch Komma zu trennen, der Browser erkennt sie nicht.
Die Preflight-Anfrage OPTIONS muss keine Geschäftslogik noch Antworttext zurückgeben, sie muss nur die korrekten CORS-Antwort-Header und Statuscode 200/204 zurückgeben das reicht. Der Browser betrachtet bei Empfang korrekter CORS-Header Preflight als bestanden, er wird den Body-Inhalt der OPTIONS-Antwort nicht lesen. Also die beste Praxis ist: OPTIONS-Anfragen direkt in der Nginx/Gateway-Schicht abfangen, 204 No Content und korrekte CORS-Header zurückgeben, ohne an den Backend-Anwendungsserver weiterzuleiten; dies entlastet das Backend und vermeidet auch 405-Fehler verursacht durch Backend-Routen die OPTIONS nicht unterstützen. Aber stellen Sie sicher dass die CORS-Header der OPTIONS-Antwort konsistent mit den CORS-Headern der echten Anfrage sind.
Cross-Origin-Anfragen mit Cookie erfordern das gleichzeitige Erfüllen von drei Bedingungen: ① XMLHttpRequest.withCredentials = true im Frontend oder credentials: 'include' in fetch; ② Backend-Antwort-Header Access-Control-Allow-Credentials: true; ③ Access-Control-Allow-Origin darf nicht * sein, muss spezifischer Ursprung sein. Die drei Bedingungen sind unentbehrlich. Beachten Sie außerdem die Cookie-Attribute: Das Cookie muss SameSite=None; Secure gesetzt haben (HTTPS-Umgebung) um in Cross-Origin-Anfragen mitgeführt werden zu können; wenn das Cookie SameSite=Lax oder Strict ist, wird es in Cross-Origin-Anfragen nicht mitgeführt; das Domain-Attribut des Cookies muss korrekt konfiguriert sein; beachten Sie auch die Auswirkungen von Drittanbieter-Cookie-Richtlinien (Browser wie Chrome haben Beschränkungen für Drittanbieter-Cookies).
CORS ist das Lockern von Cross-Origin-Zugriffsbeschränkungen, CSRF ist ein Cross-Site-Request-Forgery-Angriff, sie sind unterschiedliche Konzepte. Korrekt konfiguriertes CORS verursacht keine direkten CSRF-Schwachstellen — weil CORS nur JS erlaubt Antworten zu lesen, während CSRF ist wenn ein Angreifer den Benutzer dazu veranlasst Anfragen ohne sein Wissen zu senden (wie img-Tags, automatisches Formularabsenden), diese Anfragen werden auch ohne CORS mit Cookie gesendet. CSRF-Abwehr erfordert die Verwendung von CSRF-Token, SameSite-Cookie, Prüfung von Origin/Referer und anderen Lösungen, man kann CSRF nicht durch Deaktivieren von CORS abwehren. Aber wenn Sie bei der CORS-Konfiguration Allow-Origin auf * setzen und Anmeldeinformationen erlauben, wird dies das CSRF-Risiko verstärken, deshalb kann in Szenarien mit Anmeldeinformationen absolut nicht * verwendet werden, Sie müssen die Ursprungs-Whitelist streng einschränken.
Das Laden von Cross-Origin-Ressourcen mit normalen <img>, <script>, <link>-Tags (CDN-Bilder, JS-Skripte, CSS) hat standardmäßig keine CORS-Probleme; dies sind «eingebettete Ressourcen» keine «AJAX-Anfragen», der Browser erlaubt das Laden aber JS kann den Inhalt nicht lesen. Aber wenn Sie Cross-Origin-Bilder in Canvas manipulieren möchten, oder diese Ressourcen mit fetch/XHR laden und ihren Inhalt lesen möchten, dann brauchen Sie CORS, und gleichzeitig müssen Sie das crossorigin-Attribut zum Tag hinzufügen. Cross-Origin-Dateidownload (Klick auf a-Tag zum Herunterladen) erfordert standardmäßig ebenfalls kein CORS. Umleitungen beeinflussen CORS: Wenn die Preflight-Anfrage OPTIONS eine 3xx-Umleitung zurückgibt, wird der Browser sie direkt ablehnen (Preflight redirect is not allowed); wenn die Umleitung der echten Anfrage zwischen unterschiedlichen Ursprüngen erfolgt, muss jeder Sprung korrekt CORS-Header zurückgeben.
Wichtige Punkte der empfohlenen Nginx-Konfiguration: ① Verwendung der map-Direktive zur Übereinstimmung mit der Origin-Whitelist, dynamisches Setzen der Variable $cors_origin; ② OPTIONS-Anfragen geben direkt 204 zurück ohne an Backend weiterzuleiten; ③ add_header vergessen Sie nicht den Parameter always hinzuzufügen um sicherzustellen dass Fehlerantworten ebenfalls den Header führen; ④ Vary: Origin hinzufügen; ⑤ Allow-Methods/Allow-Headers/Credentials korrekt konfigurieren. Beispielkonfigurationen finden Sie in den Korrekturempfehlungen der Erkennungsergebnisse dieses Tools; wir bieten geprüfte Konfigurationsfragmente für wichtige Frameworks wie Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin.
Schritte zur CORS-Überprüfung: ① Zuerst verwenden Sie die Online-Erkennung dieses Tools, geben URL, Origin, Methode, Header, Anmeldeinformationsoption ein, sehen Sie ob jede Prüfung des Preflight und der echten Anfrage besteht; ② Öffnen Sie das Network-Panel der Browser-DevTools, markieren Sie Disable cache um Cache zu deaktivieren (Vermeidung von Altkachel-Interferenz), lösen Sie die Cross-Origin-Anfrage aus, überprüfen Sie dass die Antwort-Header des Preflight OPTIONS und der echten Anfrage korrekt sind; ③ In Console sehen Sie nach ob es CORS-bezogene Fehler gibt; ④ Testen Sie verschiedene Szenarien: GET-Anfragen ohne benutzerdefinierte Header, POST-Anfragen mit application/json, PUT/DELETE-Methoden, mit Cookie/ohne Cookie, mit benutzerdefinierten Headern; ⑤ Simulieren Sie eine OPTIONS-Anfrage mit curl: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint, überprüfen Sie dass die Antwort-Header korrekt sind.
Verschiedene Browser haben Unterschiede in den Implementierungsdetails der CORS-Spezifikation: ① Safari hat strengere Beschränkungen für Max-Age des Preflight-Caches (alte Versionen nur 600 Sekunden), die Cookie-Richtlinie (ITP Intelligent Tracking Prevention) ist ebenfalls strenger, kann Cross-Origin-Cookie-Probleme verursachen; ② Chrome hat strengere Prüfungen für Wildcards mit Anmeldeinformationen, Allow-Headers/Allow-Methods erlauben ebenfalls nicht *, einige Firefox-Versionen können nachsichtiger sein; ③ Alter IE (IE11) verwendet XDomainRequest anstelle von standardmäßigem XMLHttpRequest, die CORS-Implementierung hat viele Fallen (z.B. keine Unterstützung für benutzerdefinierte Header, nur Unterstützung für GET/POST); ④ Verschiedene Browser haben subtile Unterschiede bei der Verarbeitung des Vary-Headers, Umleitungsverarbeitung, Sicherheits-Header-Verarbeitung. Die Lösung ist streng gemäß CORS-Spezifikation zu konfigurieren, sich nicht auf das kompatible Verhalten eines bestimmten Browsers zu verlassen.
Empfohlen wird ein Wert zwischen 3600 (1 Stunde) und 86400 (24 Stunden). Zu kurz setzen (wie 60 Sekunden): Der Preflight-Cache läuft schnell ab, sendet häufig OPTIONS-Anfragen, erhöht die Anfragezeit und Serverlast, die Auswirkung ist in schwachen mobilen Netzwerkumgebungen bemerkbar. Zu lang setzen (wie 31536000, also ein Jahr): Wenn Sie die CORS-Konfiguration aktualisieren (z.B. Hinzufügen erlaubter Methoden, Header), kann das alte Preflight-Ergebnis im Browser-Cache des Benutzers lange brauchen um abzulaufen, während dieser Zeit treten Probleme auf dass die Konfiguration keine Wirkung zeigt. Außerdem kürzen Chrome und Firefox Werte die 86400 Sekunden überschreiten automatisch auf 86400 Sekunden, egal wie Sie es setzen es nützt nichts. In der Entwicklungsumgebung können Sie -1 setzen um den Preflight-Cache zu deaktivieren, erleichtert das Debugging.
WebSocket (ws:// und wss://) unterliegen nicht dem HTTP-CORS-Mechanismus, weil WebSocket ein unabhängiges Protokoll ist, es sind keine HTTP-AJAX-Anfragen. Aber die Handshake-Phase von WebSocket ist eine HTTP-Anfrage; der Server kann den Origin-Header prüfen um zu entscheiden ob er die Verbindung erlaubt — dies ist eine Berechtigungsprüfung auf WebSocket-Ebene, nicht Standard-CORS, aber das Prinzip ist ähnlich. Wenn die WebSocket-Verbindung abgelehnt wird, müssen Sie die Origin-Prüfkonfiguration des WebSocket-Servers überprüfen, nicht die HTTP-CORS-Header. Bibliotheken wie Socket.IO können ihre eigene Art der Cross-Origin-Konfiguration haben, ähnlich der Standard-CORS-Konfiguration aber nicht exakt gleich. Außerdem haben andere Browser-APIs wie HTTP/2 Server Push, WebRTC ebenfalls ihre eigene Berechtigungsprüfung, folgen nicht vollständig dem HTTP-CORS.
Dieses Tool auf dem Server simuliert streng gemäß W3C-CORS-Spezifikation den Preflight- und echten Anfragefluss des Browsers, die Prüflogik der CORS-Header ist grundsätzlich konsistent mit modernen Browsern. Wenn das Tool erkennt dass es besteht aber der Browser trotzdem einen Fehler meldet, sind mögliche Ursachen: ① Der Browser hat Preflight-Ergebnisse oder alte Antworten gecacht, führen Sie erzwungenes Neuladen Ctrl+F5 durch oder löschen Sie den Cache und versuchen Sie es erneut; ② Browser-Erweiterungen (Werbeblocker, Datenschutz, Sicherheitsplugins) haben die Anfrage modifiziert oder abgefangen; ③ Der Origin, die Anfrage-Header, die Methode, die Anmeldeinformationsoption die Sie im Tool eingegeben haben sind nicht konsistent mit dem was das Frontend tatsächlich sendet (z.B. das Frontend führt tatsächlich einen benutzerdefinierten Header mit den Sie nicht im Tool hinzugefügt haben); ④ Inkonsistenter Cache auf CDN/Proxy-Knoten, der Knoten den das Tool anfragt und der Knoten den der Browser anfragt geben unterschiedliche Ergebnisse zurück; ⑤ Der Browser hat spezielle Sicherheitsrichtlinien (wie Anfragen an gemischten HTTP-Inhalt in HTTPS-Seiten werden blockiert, spezielle Beschränkungen des file://-Protokolls lokaler Dateien).
