🗂

CORSとは誰が何の情報を基に制御しているか

に公開
JavaScript
CORS
mdn
tech

結論 ~ CORSとは誰が何の情報を基に制御しているか ~

早速結論です。

追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組み

https://developer.mozilla.org/ja/docs/Web/HTTP/CORS

重要な点は誰が、何を制御しているかです。
1: HTTPヘッダー（Access-Control-Allow-Originなど）を追加するのはWEBサーバー
2: CORSのエラーを制御するのはブラウザ

このようにWEBサーバーとブラウザが連携して？ クロスオリジンのリクエストを制御しています。

いつブラウザのCORSの制御が行われる

プリリクエスト (Preflight Request)

プリリクエスト CORS で行われる事前確認のためのリクエストです。
つまり、APIの本リクエストが行われる前にWEBサーバー側に事前確認のリクエストを送っているのです。

特定の HTTP メソッドやヘッダーが使用される場合、ブラウザはまず OPTIONS メソッドでリクエストを送信し、サーバーに問い合わせます。
例えば、Content-Type: application/json や、Authorization ヘッダーが含まれているリクエスト、または PUT や DELETE メソッドのリクエストはプリリクエストが必要です。
目的は、ブラウザが実際のリクエストを送信する前に、サーバーが許可しているかを確認することです。

シンプルリクエスト

いかなるリクエストでも CORS のプリフライト（OPTIONS）が発生するわけではありません。
CORS の仕様上、以下の条件をすべて満たすリクエストは「シンプルリクエスト」として扱われ、プリフライトは行われません。

ただし、プリフライトがない＝CORS制御がない、というわけではありません。
サーバーが適切な CORS レスポンスヘッダ（特に Access-Control-Allow-Origin）を返さない場合、ブラウザはレスポンスをブロックします。

以下のすべての条件を満たすと、シンプルリクエストとみなされます：

  • メソッドが GET, POST, または HEAD のいずれかである。
  • カスタムヘッダー（Authorization や X-Requested-With など）が使用されていない。
  • Content-Type が以下のいずれかである：
    • text/plain
    • multipart/form-data
    • application/x-www-form-urlencoded

CORSで利用されるヘッダー

CORSヘッダー種類

  1. Access-Control-Allow-Origin
    サーバーがリクエスト元のオリジン (例: https://example.com) を許可するかどうかを指定します。
    許可するオリジンを指定、もしくは * ですべてのオリジンを許可します。
例：
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods
  1. サーバーが許可する HTTP メソッド (GET, POST, PUT, など) を指定します。
例：
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers
  1. クライアントがリクエストで使用できるカスタムヘッダーを指定します。
例：
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials
  1. クッキーや認証情報を含むリクエストを許可する場合は true に設定します。
例：
コードをコピーする
Access-Control-Allow-Credentials: true

CORSヘッダーはいつ付与されるか

プリリクエストのレスポンス で CORS ヘッダーを付与する

プリリクエストが成功すると、ブラウザは実際のリクエストを送信します。
このときも、サーバーはレスポンスに CORS ヘッダーを付与します。

参考情報

https://developer.mozilla.org/ja/docs/Web/HTTP/CORS

Discussion