CORS ist einer der am meisten missverstandenen Teile der Websicherheit, da es eng mit der Zugriffskontrolle verbunden ist, jedoch nicht tatsächlich Zugriffskontrolle ist.
Es teilt dem Browser mit, ob Frontend-Code von einem Ursprung eine Antwort von einem anderen Ursprung lesen darf. Das ist nützlich. Es ist jedoch nicht dasselbe, wie zu entscheiden, ob die Anfrage zunächst erlaubt werden sollte.
Was CORS tut
CORS beeinflusst hauptsächlich das Verhalten des Browsers:
- kann die Anfrage normal gestellt werden?
- löst sie einen Preflight aus?
- kann die Antwort dem Frontend-JavaScript zugänglich gemacht werden?
Deshalb kann ein Server eine Anfrage weiterhin empfangen, auch wenn der Browser später den Zugang zu den Antwortdaten blockiert.
Darum tut CORS auch nichts für Nicht-Browser-Clients wie curl, Backend-Dienste oder mobile Apps. Diese Clients setzen die Browsersicherheitsregeln von vornherein nicht durch.
Was es nicht tut
CORS ersetzt nicht:
- Authentifizierung
- Autorisierung
- CSRF-Schutz
- serverseitige Validierung
Wenn Ihr einziger Schutz besteht darin, dass „der Browser es aufgrund von CORS blockiert“, ist das Design nicht sicher genug.
Ein konkretes Beispiel
Diese Header-Konfiguration könnte für eine Browser-App korrekt sein:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Aber die tatsächliche API muss immer noch überprüfen, ob der Aufrufer authentifiziert und berechtigt ist, die Aktion auszuführen. CORS beantwortet Ihnen diese Frage nicht.
Weiterführende Literatur