CORSの仕組み

本編と同じ、独自要求ヘッダー・本文なしのGET、mode: "cors"、credentials: "omit"の例です。両条件ともAPIはHTTP 200と同じ商品情報を返します。表示上のシミュレーションで、実際の通信は行いません。

Origin: https://app.exampleはブラウザが要求に付けます。APIの許可は応答ヘッダーの一部です。

HTTP/1.1 200 OK
Content-Type: application/json

{"name":"ノート","price":300}

API側で許可するオリジンを固定値として設定することもできます。ページのJavaScriptが許可を発行するものではありません。

ブラウザは応答ヘッダーを受信した時点で許可を確認できます。応答本文をすべて受信し終えることは、CORS検査の前提ではありません。JavaScriptへの公開はブラウザ内部の処理です。

• API側で共有先を決め、Originを無条件で反射しないようにします。資格情報を使わない公開リソースではAccess-Control-Allow-Origin: *が適切な場合もあり、一律に危険というわけではありません。
• Access-Control-Allow-Originに複数のOriginをカンマで並べることはできません。要求元に応じたOriginを返す場合は、Vary: Originで応答の違いを示します。

本編のGETとは別の模式例です。ページはhttps://app.example、取得先はhttps://api.example/products/1。要求本文・独自要求ヘッダーなしのPUTを、mode: "cors"、credentials: "omit"で送ります。有効なプリフライトキャッシュはないものとします。

PUTというメソッドのため、ブラウザが先にOPTIONS要求を自動的に送ります。アプリが手動で送る手順ではありません。

OPTIONS /products/1 HTTP/1.1
Host: api.example
Origin: https://app.example
Access-Control-Request-Method: PUT

HTTP/1.1 204 No Content

両条件ともOPTIONSへの応答はHTTP 204です。許可なしでは必要な許可ヘッダーがありません。許可ありでは、CORSの許可先とPUTの許可の両方を確認します。独自要求ヘッダーはないため、要求・応答の許可ヘッダー一覧は使いません。

事前確認が通っても、PUTの処理成功や応答の読み取り成功を保証しません。実際のPUTへの応答にもCORSの確認が必要です。送信後のCORS検査に失敗しても、送信済みの要求を取り消すわけではありません。

• GETでも独自の要求ヘッダーなどによってプリフライトが必要です。GET以外でも、条件を満たすPOSTなどはプリフライトが不要です。メソッドと要求ヘッダーがCORS-safelistedの条件などを満たすかで決まります。
• 応答のContent-Typeがapplication/jsonであることだけでは、事前確認が必要になる理由になりません。プリフライトキャッシュを再利用できる場合は、毎回OPTIONSが見えるとは限りません。
• プリフライトの許可は、ログインやAPIの認証・認可の代わりにはなりません。