Erkläre die Same-Origin Policy und CORS.
Kurzantwort
Die Same-Origin Policy ist die Browser-Regel, dass ein Skript aus einem Origin (Schema + Host + Port) die Antworten eines anderen Origins nicht lesen kann, was authentifizierte Sitzungen schützt. CORS ist eine kontrollierte Lockerung: Ein Server gibt Access-Control-Allow-Origin-Header zurück, um bestimmten Origins ausdrücklich das Lesen seiner Antworten zu erlauben, und lockert so die SOP, statt sie zu umgehen.
Die Same-Origin Policy (SOP) ist die grundlegende Sicherheitsgrenze des Webs. Ohne sie könnte jede Website, die du besuchst, mithilfe deiner eigenen Cookies still dein angemeldetes Webmail, deine Bank oder deine Admin-Konsole auslesen. Die SOP verhindert das.
Die Same-Origin Policy
Ein Origin ist das Tripel aus Schema + Host + Port (https://app.example.com:443). Die SOP besagt, dass ein Skript, das in einem Origin läuft, im Allgemeinen die Antwort einer Anfrage an einen anderen Origin nicht lesen kann. Beachte die Feinheit: Der Browser sendet die Cross-Origin-Anfrage oft trotzdem (genau deshalb existiert CSRF), aber er verhindert, dass das Skript das Ergebnis liest. Das hält eine bösartige Seite davon ab, Daten aus deinen authentifizierten Sitzungen anderswo abzugreifen.
Warum es CORS gibt
Die SOP ist bewusst streng, aber legitime Anwendungen brauchen ständig Cross-Origin-Daten — ein Frontend auf app.example.com, das eine API auf api.example.com aufruft. Cross-Origin Resource Sharing (CORS) ist der Mechanismus, mit dem der Server dem Teilen zustimmt. Es lockert die SOP auf kontrollierte Weise; es schaltet sie nicht ab.
Wie CORS funktioniert
Der Browser fügt einen Origin-Header hinzu; der Server antwortet mit Access-Control-Allow-Origin und benennt die Origins, die die Antwort lesen dürfen. Für Anfragen, die den Zustand ändern können oder nicht-einfache Header/Methoden nutzen, sendet der Browser zuerst eine Preflight-OPTIONS-Anfrage, und der Server muss Methode und Header über Access-Control-Allow-Methods / -Headers genehmigen, bevor die eigentliche Anfrage gesendet wird.
Der häufige Sicherheitsfehler
Um Cookies cross-origin zu senden, musst du Access-Control-Allow-Credentials: true setzen — und in diesem Fall verbietet die Spezifikation den Platzhalter Access-Control-Allow-Origin: *; du musst einen bestimmten Origin zurückgeben. Den Origin der Anfrage naiv mit aktivierten Anmeldedaten zurückzuspiegeln ist eine klassische Fehlkonfiguration, die jeder Website das Lesen authentifizierter Antworten ermöglicht.
Prüfer achten auf die Definition Schema/Host/Port, auf die Feinheit, dass das Lesen blockiert wird, nicht das Senden, auf CORS als Server-Zustimmung, die die SOP lockert (nicht abschaltet), und auf die Falle aus Anmeldedaten plus Platzhalter.
Wahrscheinliche Anschlussfragen
- Was macht zwei URLs zum 'gleichen Origin'?
- Was ist eine CORS-Preflight-Anfrage und wann wird sie gesendet?
- Warum ist Access-Control-Allow-Origin: * mit Anmeldedaten unzulässig?