In der deutschen Enterprise-Java-Welt, wo Spring Boot dominiert, ist das @CrossOrigin(origins = "*")-Annotation-Pattern ein bekannter Stolperstein: Es wird für lokale Tests gesetzt, um CORS-Fehler schnell loszuwerden, und bleibt dann unverändert im Code, wenn dieser in Produktion geht. Sobald jemand allowCredentials(true) ergänzt, damit Session-Cookies an eine separate API-Subdomain gesendet werden, blockiert der Browser die Antwort — Wildcard-Origin und Credentials schließen sich gegenseitig aus.
Die Same-Origin-Policy
Standardmäßig setzen Browser die Same-Origin-Policy durch: JavaScript-Code einer Seite von einem Ursprung (Domain + Schema + Port) kann keine Antworten von Anfragen an einen anderen Ursprung lesen. Das ist ein grundlegender Sicherheitsmechanismus, der verhindert, dass ein bösartiges Skript auf einer Seite Daten von einer anderen Seite stiehlt, bei der der Nutzer angemeldet ist.
Wie CORS diese Policy lockert
CORS (Cross-Origin Resource Sharing) ist eine Reihe von HTTP-Headern, mit denen ein Server bestimmten (oder allen) externen Ursprüngen explizit erlaubt, seine Antworten zu lesen. Der zentrale Header ist Access-Control-Allow-Origin, der festlegt, welche Domains die Erlaubnis haben.
Die Wildcard-plus-Credentials-Falle
Wird eine Anfrage mit credentials: 'include' gesendet — nötig, um ein Session-Cookie an eine API auf einer anderen Subdomain zu übermitteln —, lehnt der Browser Access-Control-Allow-Origin: * in der Antwort strikt ab. Die Spezifikation verbietet die Kombination aus Wildcard-Origin und Credentials ausdrücklich; der Server muss stattdessen den exakten anfragenden Ursprung zurückgeben.
Wofür man das braucht
- Einen CORS-Fehler diagnostizieren und genau herausfinden, welche Header auf dem Server fehlen.
- Eine zu freizügige
@CrossOrigin-Konfiguration in Spring Boot aufspüren, bevor sie in Produktion geht. - Den Unterschied zwischen „einfachen" Anfragen und Preflight-Anfragen (OPTIONS) verstehen.
CORS schützt den Server nicht vor Angriffen
Ein weitverbreiteter Irrtum ist die Annahme, CORS sei eine serverseitige Sicherheitsmaßnahme — tatsächlich schränkt es nur ein, was JavaScript im Browser lesen darf. Ein Angreifer, der curl, Postman oder ein Backend-Skript direkt verwendet, umgeht CORS vollständig, da diese Werkzeuge keine Same-Origin-Policy anwenden. CORS sollte niemals echte Authentifizierung und Autorisierung auf dem Server ersetzen.