OPTIONS

Verwendung

Eine OPTIONS-Anfrage ruft die erlaubten Methoden und Fähigkeiten einer Zielressource ab, ohne eine Aktion auf der Ressource auszuführen. Der Server antwortet mit einem Allow-Header, der die unterstützten Methoden auflistet.

Wird ein Sternchen (*) als Anfrageziel verwendet, gilt die Anfrage dem Server als Ganzes statt einer bestimmten Ressource.

OPTIONS * HTTP/1.1
Host: api.example.re

CORS-Preflight

Die in der Praxis häufigste Verwendung von OPTIONS ist die CORS-Preflight-Anfrage. Bevor der Browser eine quellenübergreifende Anfrage mit einer Methode außerhalb der CORS-Positivliste, mit benutzerdefinierten Headern oder mit einem Content-Type außerhalb der Positivliste (application/x-www-form-urlencoded, multipart/form-data, text/plain) sendet, schickt er automatisch eine OPTIONS-Anfrage an den Zielserver. Der Preflight prüft, ob der Server die eigentliche Anfrage zulässt.

Die Preflight-Anfrage enthält Origin, Access-Control-Request-Method und optional Access-Control-Request-Headers. Der Server antwortet mit Access-Control-Allow-Origin, Access-Control-Allow-Methods und Access-Control-Allow-Headers, um die Zustimmung zu signalisieren.

Fähigkeiten einer Ressource

Ein Client fragt die erlaubten Methoden für eine bestimmte Ressource ab. Der Server antwortet mit 204 No Content und einem Allow-Header.

Anfrage

OPTIONS /articles HTTP/1.1
Host: api.example.re

Antwort

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST, DELETE

Serverweite Abfrage

Die Verwendung von * als Ziel offenbart die Methoden, die der Server allgemein unterstützt, unabhängig von einer bestimmten Ressource.

Anfrage

OPTIONS * HTTP/1.1
Host: api.example.re

Antwort

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD

CORS-Preflight

Ein Browser bereitet eine quellenübergreifende PUT-Anfrage mit einem benutzerdefinierten X-Request-ID-Header vor. Vor dem Senden der eigentlichen Anfrage setzt der Browser eine OPTIONS-Preflight-Anfrage ab, um zu bestätigen, dass der Server die Methode und den Header von der anfragenden Quelle zulässt.

Preflight-Anfrage

OPTIONS /api/data HTTP/1.1
Host: api.example.re
Origin: https://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Request-ID

Preflight-Antwort

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

Der Wert von Access-Control-Max-Age weist den Browser an, das Preflight-Ergebnis 86.400 Sekunden (einen Tag) lang zwischenzuspeichern, wodurch wiederholte Preflight-Anfragen an denselben Endpunkt vermieden werden.

Sicherheit

OPTIONS-Antworten enthalten einen Allow-Header, der jede von der Ressource unterstützte Methode auflistet. Das ist eine geringfügige Informationspreisgabe, und Sicherheitsscanner melden einen aktivierten OPTIONS-Endpunkt häufig als Befund. OPTIONS vollständig zu deaktivieren ist keine praktikable Lösung, da CORS-Preflight-Anfragen OPTIONS benötigen, um zu funktionieren.

Der empfohlene Ansatz besteht darin, den Allow-Header auf die Methoden zu beschränken, die der jeweilige Endpunkt tatsächlich benötigt. Eine Ressource, die GET und POST annimmt, sollte in der Allow-Liste weder DELETE noch PUT ankündigen.

Manche Frameworks unterstützen einen X-HTTP-Method-Override-Header, um PUT, PATCH oder DELETE durch eine POST-Anfrage zu tunneln. Das umgeht methodenbasierte Zugriffskontrollen und stellt ein Sicherheitsrisiko dar, wenn die Funktion nicht ausdrücklich aktiviert und auditiert wurde.

Um unnötige Preflight-Anfragen zu vermeiden, halten Sie quellenübergreifende Anfragen innerhalb der Kriterien für “einfache” Anfragen: ausschließlich GET, HEAD oder POST mit Headern und Inhaltstypen von der Positivliste. Die Verwendung von Content-Type: application/json löst immer einen Preflight aus. Access-Control-Max-Age speichert Preflight-Ergebnisse zwischen, um wiederholte OPTIONS-Roundtrips zu reduzieren.