More than 3 years have passed since last update.

CORSについてざっくり理解する

CORS

Last updated at 2019-12-05Posted at 2019-12-05

はじめに

API開発をしていると以下のようなエラーに遭遇することがあります

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).

なにが原因でこのエラーが起こり、どう解消したらいいのかをざっくりまとめてみる
- 結論を言ってしまうと、同一オリジンポリシーに引っかかっているのでCORSの設定をする必要があります

CORSとは

Cross-Origin Resource Sharingの略で、ざっくり言うと違うオリジンからのアクセスを許可する仕組みのこと
- 同一オリジンポリシー（後述）にという仕組みによって、異なるオリジンのリソースへのアクセスは制限されている
オリジンとはURL中のスキーム、ホスト、ポートの組み合わせのこと
- http://example.comだと
  - スキーム：http
  - ホスト：example.com
  - ポート: 80（省略可能なので明示されているケースは少ない）
CORSやオリジンについて詳しくは以下のサイトを参照してください
- オリジン間リソース共有 (CORS)
- Origin (オリジン)

どのような場面でCORSの設定が必要か

現在のブラウザは同一オリジンポリシーが導入されているため、デフォルトでは違うオリジンからのアクセスは遮断されてしまう。
WebクライアントとAPIを分ける場合などで、異なるオリジン間の通信を行うためにはCORSの設定をする必要がある。

具体的な設定方法

(i) 単純リクエストの場合

単純リクエストとは、以下のすべての条件を満たすもの
（オリジン間リソース共有 (CORS)から引用）

- 許可されているのは以下のメソッドのみです。
  - GET
  - HEAD
  - POST
 - ユーザーエージェントによって自動的に設定されたヘッダー (たとえば  `Connection`、 `User-Agent`、 または Fetch 仕様書で "forbidden header name" として定義されている名前のヘッダー)を除いて、手動で設定できるヘッダーは、 Fetch 仕様書で "CORS-safelisted request-header" として定義されている以下のヘッダーだけです。
   - Accept
   - Accept-Language
   - Content-Language
   - Content-Type (但し、下記の要件を満たすもの)
   - DPR
   - Downlink
   - Save-Data
   - Viewport-Width
   - Width
 - Content-Type ヘッダーで許可されているのは以下の値のみ
   - application/x-www-form-urlencoded
   - multipart/form-data
   - text/plain
- リクエストに使用されるどの XMLHttpRequestUpload にもイベントリスナーが登録されていないこと。これらは正しく XMLHttpRequest.upload を使用してアクセスされます。
- リクエストに ReadableStream オブジェクトが使用されていないこと。

設定すべきこと

サーバー側のResponse Headerに以下を追加する。

Access-Control-Allow-Origin: <オリジン名>

Access-Control-Allow-Originの値でアクセスを許可するオリジンを指定する。
値に*を指定するとすべてのアクセスを許可できる。

(ii) 単純リクエストではない場合

実際のリクエストを送る前に安全かを確かめるためにプリフライトリクエストが送られる。
プリフライトリクエストは以下の特徴を持っている
- OPTIONSメソッドを使用
- 以下の情報がリクエストヘッダに含まれる
  - 実際のリクエストのHTTPメソッド情報
    - Access-Control-Request-Method: <実際のリクエストのHTTPメソッド>
  - 実際のリクエストのヘッダー情報（単純リクエストのヘッダの条件から外れる場合）
    - Access-Control-Request-Headers: <実際のリクエストのカスタムヘッダ>

設定すべきこと

サーバー側でOPTIONSメソッドを受け取れるようにする
OPTIONSメソッドを受けとったら、以下のヘッダ・値をレスポンスヘッダに追加して返す
- Access-Control-Allow-Origin: <許可するオリジン名>
- Access-Control-Allow-Methods: <許可するHTTPメソッド名>
- Access-Control-Request-Headers: <許可するカスタムヘッダ名>
プリフライトリクエストのレスポンスで許可されれば実際のリクエストが送信される。実際のリクエストに対する設定は単純リクエストの場合と同じ。
プリフライトリクエスト
実際のリクエスト

※ ユーザー認証情報（CookieやBASIC認証）を送信する場合

設定すべきこと

上記に加えて以下のことを設定する必要がある
サーバー側
- Access-Control-Allow-Originの値を*以外にする
- Access-Control-Allow-Credentials: trueを指定する
クライアント側
- クレデンシャルを扱うことを明示する
詳しくはCORSリクエストでクレデンシャル(≒クッキー)を必要とする場合の注意点を参照してください

補足

rack-corsやcorsのようにCORSの設定をサポートするライブラリを利用するのが楽そう

参考URL

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up