Access-Control-Allow-Headers

Verwendung

Wenn ein Browser eine Preflight-OPTIONS-Anfrage sendet, listet der Header Access-Control-Request-Headers die nicht auf der Safelist stehenden Header auf, die der Client senden möchte. Der Server antwortet mit Access-Control-Allow-Headers und bestätigt, welche dieser Header akzeptiert werden.

Header auf der CORS-Safelist sind immer zulässig und müssen in dieser Liste nicht auftauchen. Zur Safelist gehören Accept, Accept-Language, Content-Language, Content-Type (mit Einschränkungen bei Medientyp und Wertlänge) sowie Range (mit Einschränkungen beim Format). Das explizite Auflisten eines Safelist-Headers hebt die zusätzlichen Einschränkungen für dessen Wert auf.

Mehrere Header-Namen erscheinen als kommagetrennte Liste.

Liste von Header-Namen

Eine kommagetrennte Menge von Header-Namen, die der Server in der eigentlichen Anfrage akzeptiert.

Access-Control-Allow-Headers: Content-Type, Authorization

* (Wildcard)

Bei Anfragen ohne Anmeldedaten wirkt das Sternchen als Wildcard und erlaubt jeden Header-Namen.

Access-Control-Allow-Headers: *

Hinweis

Bei Anfragen mit Anmeldedaten wird die Wildcard * als literale Zeichenkette behandelt, nicht als Wildcard. Sind Anmeldedaten im Spiel, muss jeder erlaubte Header explizit aufgeführt werden. Der Header Authorization wird niemals von der Wildcard abgedeckt und muss immer explizit genannt werden.

Beispiel

Eine Preflight-Anfrage fragt, ob Content-Type und ein benutzerdefinierter Header X-Request-ID erlaubt sind. Der Server bestätigt beide.

Anfrage

OPTIONS /api/data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-Request-ID

Antwort

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, X-Request-ID
Access-Control-Max-Age: 86400

Ein Server, der die Wildcard für Anfragen ohne Anmeldedaten einsetzt, antwortet mit einem einzigen Zeichen.

Access-Control-Allow-Headers: *

Fehlersuche

Preflight-Fehler im Zusammenhang mit Anfrage-Headern erzeugen Konsolenfehler und blockieren die eigentliche Anfrage.

Die Konsole zeigt “Request header field X is not allowed by Access-Control-Allow-Headers in preflight response.” Der Server hat den Header-Namen nicht im Wert von Access-Control-Allow-Headers aufgeführt. Ergänzen Sie den fehlenden Header in der Preflight-Antwort. In nginx: add_header Access-Control-Allow-Headers “Content-Type, Authorization, X-Request-ID”; in Apache: Header set Access-Control-Allow-Headers “Content-Type, Authorization, X-Request-ID”

Der Header fehlt in der Preflight-Antwort vollständig. Der Server verarbeitet die OPTIONS-Anfrage, nimmt Access-Control-Allow-Headers aber nicht in die Antwort auf. Viele Frameworks verlangen eine explizite CORS-Konfiguration für Preflight-Routen. Prüfen Sie, ob der OPTIONS-Handler bzw. die Middleware diesen Header zusammen mit Access-Control-Allow-Methods und Access-Control-Allow-Origin setzt.

Die Wildcard * funktioniert bei Anfragen mit Anmeldedaten nicht. Ist Access-Control-Allow-Credentials auf true gesetzt, wird die Wildcard als literale Zeichenkette * behandelt und passt auf nichts. Führen Sie jeden erlaubten Header explizit auf. Der Header Authorization wird selbst bei Anfragen ohne Anmeldedaten nie von der Wildcard abgedeckt und muss immer genannt werden.

Header-Namen wirken bei manchen Servern wie Groß-/Kleinschreibung-abhängig. Laut Protokoll sind HTTP-Header-Namen unabhängig von Groß- und Kleinschreibung, doch manche Server-Frameworks führen beim Abgleich mit der Erlaubnisliste einen Zeichenkettenvergleich mit Beachtung der Groß-/Kleinschreibung durch. Eine Anfrage, die content-type sendet, kann fehlschlagen, wenn der Server nur Content-Type aufführt. Passen Sie die Schreibweise an das an, was der Client sendet, oder normalisieren Sie beide Seiten in der CORS-Konfiguration auf Kleinbuchstaben.

Das Senden von Content-Type: application/json löst einen unerwarteten Preflight aus. Der Header Content-Type steht nur für die Werte application/x-www-form-urlencoded, multipart/form-data und text/plain auf der Safelist. Der Wert application/json fällt nicht darunter und erzwingt einen Preflight. Nehmen Sie Content-Type in die Liste von Access-Control-Allow-Headers auf. Um zu bestätigen, dass der Preflight ausgelöst wird, öffnen Sie in den DevTools den Tab Network und filtern Sie nach Methode, um die OPTIONS-Anfrage vor der eigentlichen Anfrage zu erkennen.