OPTIONS

使い方

OPTIONS リクエストは、リソースに対して何らかの操作を実行することなく、ターゲットリソースで許可されているメソッドと機能を取得します。サーバーはサポートするメソッドを列挙した Allow ヘッダーで応答します。

リクエストターゲットとしてアスタリスク（*）が使われた場合、そのリクエストは特定のリソースではなくサーバー全体に適用されます。

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

CORS プリフライト

実運用で最も一般的な OPTIONS の用途は CORS プリフライトリクエストです。CORS セーフリストに含まれないメソッド、カスタムヘッダー、またはセーフリスト（application/x-www-form-urlencoded、multipart/form-data、text/plain）に含まれない Content-Type を伴うクロスオリジンリクエストを送信する前に、ブラウザは自動的にターゲットサーバーへ OPTIONS リクエストを送信します。プリフライトは、サーバーが実際のリクエストを許可しているかどうかを確認します。

プリフライトリクエストには Origin、Access-Control-Request-Method、そして任意で Access-Control-Request-Headers が含まれます。サーバーは承認を示すために Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers で応答します。

リソースの機能

クライアントが特定のリソースで許可されているメソッドを問い合わせます。サーバーは 204 No Content と Allow ヘッダーで応答します。

リクエスト

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

レスポンス

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

サーバー全体への問い合わせ

ターゲットとして * を使うと、特定のリソースに依存せず、サーバーが一般にサポートするメソッドが明らかになります。

リクエスト

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

レスポンス

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

CORS プリフライト

ブラウザが、カスタムの X-Request-ID ヘッダーを伴うクロスオリジンの PUT リクエストを準備します。実際のリクエストを送信する前に、ブラウザはプリフライトの OPTIONS リクエストを発行して、サーバーがリクエスト元のオリジンからのそのメソッドとヘッダーを許可しているかを確認します。

プリフライトリクエスト

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

プリフライトレスポンス

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

Access-Control-Max-Age の値は、プリフライトの結果を 86,400 秒（1日）キャッシュするようブラウザに指示し、同じエンドポイントに対するプリフライトリクエストの繰り返しを回避します。

セキュリティ

OPTIONS レスポンスには、そのリソースがサポートするすべてのメソッドを列挙した Allow ヘッダーが含まれます。これは軽微な情報漏洩であり、セキュリティスキャナーは有効な OPTIONS エンドポイントを検出事項として報告することがよくあります。CORS プリフライトリクエストが機能するには OPTIONS が必要なため、OPTIONS を完全に無効化することは現実的な解決策ではありません。

推奨されるアプローチは、Allow ヘッダーを各エンドポイントが必要とするメソッドのみに制限することです。GET と POST を受け付けるリソースが、Allow の一覧で DELETE や PUT を公表すべきではありません。

一部のフレームワークは、POST リクエストを通じて PUT、PATCH、DELETE をトンネリングするための X-HTTP-Method-Override ヘッダーをサポートしています。これはメソッドに基づくアクセス制御を回避するため、この機能が明示的に有効化され監査されていない場合はセキュリティ上の懸念となります。

不要なプリフライトリクエストを避けるには、クロスオリジンリクエストを「シンプル」リクエストの条件に収めてください。すなわち、セーフリストのヘッダーとセーフリストのコンテンツタイプのみを伴う GET、HEAD、POST です。Content-Type: application/json を使うと常にプリフライトが発生します。Access-Control-Max-Age はプリフライト結果をキャッシュし、OPTIONS の往復の繰り返しを削減します。