Access-Control-Allow-Credentials

Verwendung

Quellenübergreifende Anfragen schließen Anmeldedaten wie Cookies, Authorization-Header und TLS-Client-Zertifikate standardmäßig aus. Wenn ein Client den Credentials-Modus auf include setzt, muss der Server Access-Control-Allow-Credentials mit dem Wert true zurückgeben, damit der Browser Antwortbody und Antwort-Header dem aufrufenden Skript zugänglich macht.

Während eines Preflight-Austauschs signalisiert dieser Header, ob die eigentliche Anfrage Anmeldedaten mitführen darf. Lässt die Preflight-Antwort den Header weg oder setzt sie einen anderen Wert als true, blockiert der Browser die Anfrage mit Anmeldedaten vollständig.

Bei einfachen CORS-Anfragen (solchen ohne Preflight-Schritt, etwa einem einfachen GET) prüft der Browser den Header dennoch nach dem Empfang der Antwort. Fehlt der Header, wird die Antwort stillschweigend verworfen und erreicht den aufrufenden Code nie.

Hinweis

Wenn Anmeldedaten mitgesendet werden, muss der Header Access-Control-Allow-Origin eine explizite Quelle angeben. Der Platzhalter * ist bei Anfragen mit Anmeldedaten nicht zulässig.

true

Der einzige gültige Wert. Der Header mit true weist den Browser an, die Antwort offenzulegen, wenn Anmeldedaten vorhanden sind.

Access-Control-Allow-Credentials: true

Das Weglassen des Headers oder das Senden eines beliebigen anderen Werts hat dieselbe Wirkung: Der Browser behandelt die Antwort als ohne Anmeldedaten und hält den Body von JavaScript zurück.

Beispiel

Eine Frontend-Anwendung sendet einen quellenübergreifenden fetch-Aufruf mit mitgesendeten Anmeldedaten. Der Server antwortet mit dem Credentials-Header, einer expliziten Quelle und einer Vary-Direktive, damit Caches zwischen den Quellen unterscheiden.

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Vary: Origin

Beim Preflight für eine POST-Anfrage mit Anmeldedaten bestätigt der Server sowohl die erlaubte Methode als auch die Unterstützung für Anmeldedaten.

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 3600
Vary: Origin

Fehlersuche

Quellenübergreifende Anfragen mit Anmeldedaten scheitern stillschweigend, sobald ein beliebiger Teil der CORS-Kette falsch konfiguriert ist.

Cookies werden quellenübergreifend nicht gesendet, obwohl der Server Access-Control-Allow-Credentials: true zurückgibt. Der clientseitige Code muss sich aktiv für das Senden von Anmeldedaten entscheiden. In der Fetch API übergeben Sie credentials: ‘include’ in den Anfrageoptionen. In XMLHttpRequest setzen Sie withCredentials = true, bevor Sie send() aufrufen. Ohne dieses Flag entfernt der Browser Cookies und Authorization-Header aus quellenübergreifenden Anfragen, unabhängig von der Antwort des Servers.

Die Konsole zeigt “Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.” Wenn Access-Control-Allow-Credentials auf true steht, muss der Header Access-Control-Allow-Origin eine explizite Quelle enthalten. Lesen Sie den eingehenden Origin-Header, prüfen Sie den Wert gegen eine Positivliste, spiegeln Sie die passende Quelle zurück und fügen Sie der Antwort Vary: Origin hinzu. Dieselbe Regel gilt für Access-Control-Allow-Headers und Access-Control-Allow-Methods: Platzhalter in diesen Headern werden bei Anfragen mit Anmeldedaten als wörtliche Zeichenketten behandelt.

Im fetch()-Aufruf fehlt credentials: ‘include’. Die Fetch API verwendet standardmäßig credentials: ‘same-origin’, wodurch Anmeldedaten bei quellenübergreifenden Anfragen ausgeschlossen werden. Übergeben Sie { credentials: ‘include’ } explizit. Prüfen Sie den Network-Tab in den DevTools und sehen Sie sich die Anfrage-Header an. Fehlt der Cookie-Header in der ausgehenden Anfrage, hat sich der Client nicht dafür entschieden.

Bei XMLHttpRequest fehlt withCredentials = true. Ähnlich wie die Fetch API sendet XMLHttpRequest keine Cookies quellenübergreifend, sofern withCredentials nicht auf true gesetzt ist. Diese Eigenschaft muss gesetzt werden, bevor xhr.open() oder xhr.send() aufgerufen wird. Bibliotheken wie Axios stellen dies als { withCredentials: true } in der Anfragekonfiguration bereit.

Das Cookie-Attribut SameSite blockiert die quellenübergreifende Zustellung. Moderne Browser verwenden standardmäßig SameSite=Lax, wenn kein SameSite-Attribut gesetzt ist. Lax-Cookies werden bei quellenübergreifenden POST- oder Subressourcen-Anfragen nicht gesendet. Setzen Sie SameSite=None und Secure für Cookies, die quellenübergreifend übertragen werden müssen. Überprüfen Sie das Attribut in den DevTools unter Application

Cookies. Ohne Secure lehnen Browser Cookies mit SameSite=None vollständig ab.

Der Ausstieg aus Drittanbieter-Cookies blockiert Anmeldedaten. Chrome und andere Browser schränken Drittanbieter-Cookies ein. Quellenübergreifende Anfragen, die auf Cookies einer anderen Domain angewiesen sind, brechen zunehmend. Wechseln Sie nach Möglichkeit zu tokenbasierter Authentifizierung über den Authorization-Header oder setzen Sie die Storage Access API ein, um den Cookie-Zugriff explizit anzufordern. Testen Sie in Chrome mit aktiviertem Flag “Third-party cookie phaseout”, um Probleme vor dem Rollout sichtbar zu machen.