Warum CORS im Browser existiert
Browser setzen die Same-Origin-Policy durch, um zu verhindern, dass bosartige Websites sensible Daten von anderen Domains lesen. CORS lockert diese Einschrankung kontrolliert, indem Server deklarieren konnen, welche Ursprunge, Methoden und Header erlaubt sind. Ohne CORS-Header wird jede Cross-Origin-Fetch- oder XMLHttpRequest blockiert, selbst wenn der Server die Anfrage erfolgreich verarbeitet hat.
CORS-Header verstehen
Der Header Access-Control-Allow-Origin gibt vertrauenswurdige Ursprunge an. Access-Control-Allow-Methods listet erlaubte HTTP-Methoden wie GET, POST und DELETE auf. Access-Control-Allow-Headers deklariert, welche benutzerdefinierten Anfrage-Header akzeptiert werden. Access-Control-Expose-Headers steuert, welche Antwort-Header der Browser lesen kann, und Access-Control-Max-Age speichert Preflight-Ergebnisse zwischen.
Einfache vs. Preflight-Anfragen
Einfache Anfragen verwenden GET, HEAD oder POST mit Standard-Inhaltstypen und uberspringen den Preflight-Schritt. Jede Anfrage mit anderen Methoden, benutzerdefinierten Headern oder Nicht-Standard-Inhaltstypen lost einen Preflight-OPTIONS-Aufruf aus. Der Server muss auf den Preflight mit den richtigen CORS-Headern antworten, bevor der Browser die eigentliche Anfrage sendet.
Haufige Fallstricke und Best Practices
Vermeiden Sie Platzhalter-Ursprunge in der Produktion; verwenden Sie stattdessen eine Whitelist spezifischer Domains. Kombinieren Sie nie Platzhalter-Ursprunge mit Anmeldedaten, da Browser die Antwort ablehnen werden. Setzen Sie ein vernunftiges Max Age, um den Preflight-Overhead zu reduzieren, ohne veraltete Richtlinien zwischenzuspeichern. Testen Sie CORS immer vom tatsachlichen Client-Ursprung.





