🗂
CORSとは誰が何の情報を基に制御しているか
結論 ~ CORSとは誰が何の情報を基に制御しているか ~
早速結論です。
追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組み
重要な点は誰が、何を制御しているかです。
1: HTTPヘッダー（Access-Control-Allow-Originなど）を追加するのはWEBサーバー
2: CORSのエラーを制御するのはブラウザ
このようにWEBサーバーとブラウザが連携して？ クロスオリジンのリクエストを制御しています。
いつ、ブラウザのCORSの制御が行われる
シンプルリクエスト
いかなるリクエストでもCORSの制御が発生する訳では有りません。
CORSの仕様上プリリクエストを必要としないリクエストです。
以下の条件をすべて満たす場合に、シンプルリクエストとみなされます：
- メソッドが GET, POST, または HEAD のいずれかである。
- カスタムヘッダー (Authorization など) が使用されていない。
- Content-Type が以下のいずれかである：
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded
プリリクエスト (Preflight Request)
プリリクエスト CORS で行われる事前確認のためのリクエストです。
つまり、APIの本リクエストが行われる前にWEBサーバー側に事前確認のリクエストを送っているのです。
特定の HTTP メソッドやヘッダーが使用される場合、ブラウザはまず OPTIONS メソッドでリクエストを送信し、サーバーに問い合わせます。
例えば、Content-Type: application/json や、Authorization ヘッダーが含まれているリクエスト、または PUT や DELETE メソッドのリクエストはプリリクエストが必要です。
目的は、ブラウザが実際のリクエストを送信する前に、サーバーが許可しているかを確認することです。
CORSで利用されるヘッダー
CORSヘッダー種類
- Access-Control-Allow-Origin
サーバーがリクエスト元のオリジン (例: https://example.com) を許可するかどうかを指定します。
許可するオリジンを指定、もしくは * ですべてのオリジンを許可します。
例：
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods
- サーバーが許可する HTTP メソッド (GET, POST, PUT, など) を指定します。
例：
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers
- クライアントがリクエストで使用できるカスタムヘッダーを指定します。
例：
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials
- クッキーや認証情報を含むリクエストを許可する場合は true に設定します。
例：
コードをコピーする
Access-Control-Allow-Credentials: true
CORSヘッダーはいつ付与されるか
プリリクエストのレスポンス で CORS ヘッダーを付与する
プリリクエストが成功すると、ブラウザは実際のリクエストを送信します。
このときも、サーバーはレスポンスに CORS ヘッダーを付与します。
参考情報
Discussion