TIL 26. What is CORS?

Today's topic

今回のpostではCORSについて議論します.Djangoを使用してAPIを作成し、初期設定を行うたびに

pip install django-cors-headers

django-cors-headersをインストールして設定します.py fileで関連コンテンツをアップロードして開始しました.なぜ毎回cors-headersをインストールするのか知りたいので調べて、投稿に整理したいです.

👉 What is CORS?

CROSS-Origin Resource Sharing(COS)は、追加のHTTPヘッダ通知ブラウザを使用して、あるソースで実行されるWebアプリケーションが別のソースから選択されたリソースにアクセスできるようにするメカニズムです.

👉 What is"Origin"?

Origin(ソース)は、プロトコル、host、portを含むことを意味します.
ex) https://www.google.com/search?q=cors
プロトコル、host、port(:443)-非表示
同じソース(ison-origin)は、プロトコル、host、portが同じであることを意味します.

👉 What is 'SOP(same-origin policy)'?

その上で、SOPというルールがあります.これは、同じソース(origin)でしかリソースを共有できないルールです.ブラウザが他のサーバから要求した場合、このポリシーはブラウザを介してサーバ間で通信しない場合に適用されません.

👉 Why is SOP necessary?

最大の原因は警備側の原因です.これらの制限がない場合、他のソースからの悪意のあるユーザは、ソースコードを表示し、CSRFまたはXSSなどの方法を使用して情報を取得することができる.これを防ぐために、SOPのようなルールがあります.

しかし、異なるソースからリソースを必要とする場合が多くなり、この場合、CORSをSOPを迂回することによって異なるソースからリソースを要求する.

👉 Principle of CORS?

Webクライアントアプリケーションが他のソースからのリソースを要求すると、HTTPプロトコルを使用して要求が送信され、ブラウザは要求ヘッダでOriginというフィールドに要求を送信し、要求をソースに送信します.

ex) Origin : http://www.google.com

その後、サーバが要求に応答すると、応答ヘッダのアクセス制御Allow-Origin値は「このリソースへのアクセスを許可するソース」を低下させる.
その後、応答を受信したブラウザは、自身が発行した要求のOriginと、サーバが発行した応答のAccess-Clontrol-Allow-Originとを比較して、応答が有効かどうかを判断する.
基本的にはこのような流れであるが,3つの異なるCORSアクセス制御スキーム(ソースリソースを交差して共有する動作方式)があり,いずれの場合もスキームに従って調整される.
Requestには3種類あり、各リクエストについて詳しく説明します.

Preflight request

Simple Request

Credentialed request

👉 Preflight request

Preflight Requestは、プリリクエストと本リクエストに分けられます.まず,OPTIONS法によりHTTP要求を別のドメインのリソースに送信し,実際の要求が伝送時に安全であることを確保する.Cross-originリクエストは、ユーザデータに影響を与えるため、予め送信される(prefired).

Preflight request
OPTIONSリクエストは、2つの異なるリクエストヘッダを同時に送信する.上図では、フライト前に要求された「アクセス制御要求方法」は、実際の要求が送信されたときにPOST方法に送信され、「アクセス制御要求Headers」は、実際の要求が送信されたときにX-PINGOTHERおよびContent-Type Aカスタムヘッダとともにサーバに送信される.

Preflight response
サーバから受信方法とタイトルが表示されます.上記のPreflightレスポンスは、「Post」と「GET」が有用な方法であることを教えてくれます.最後の行はpreflightリクエストに対する応答をキャッシュできる秒数です.
Preflight requestを送信すると、プリリクエストが2回と実際のリクエストが2回発行されるため、ブラウザが同じリクエストをキャッシュして送信すると、プリリクエストは発行されず、すぐにこのリクエストが発行されます.
Preflightリクエストが完了すると、実際のリクエストが送信されます.
Preflightでは、重要なのは「Access Control Allow-Origin」であり、この値をヘッダ内でチェックすることでBrowserがCORS運転状態にあるかどうかを判断します.

👉 Simple request

Simple Requestは、Preflight Requestとは異なり、リクエストを送信するとすぐにクロスソースであるかどうかを確認しますが、以下のすべての条件を満たす必要があります.

-GET、HEAD、POST

受付、受付言語、コンテンツ言語、コンテンツタイプのHeader

コンテンツリーダーは、アプリケーション/x-www-form-urlcoded、マルチセクション/フォーム-data、テキスト/平面

のみを許可する.
Simple Request(Simple Request)とは、スタンバイリクエストを送信しない場合に、本リクエストをサーバに直接送信し、アクセス制御Allow-Originと同じ値を応答ヘアに送信し、ブラウザがCORSルールに違反しているかどうかをチェックする方法である.すなわち、preflightとsimple requestスキームの全体的な論理自体は同じであり、preflightリクエストの存在の有無のみが異なる.

👉 Credentialed request

第3の態様は、認証情報を含む要求である.他の方法よりもセキュリティを強化したい場合は、使用できます.
ブラウザが提供する非同期リソース要求API XMLHttpRequestオブジェクトまたはfetch APIには、ブラウザのCookie情報または認証に関連するヘッダがほとんど含まれていないため、個別のcrudtialオプションを指定する必要があります.

3種選択

同一ソース(デフォルト):同一ソース間の要求にのみ認証情報

を含めることができる.

include:すべてのリクエストに認証情報

を含めることができる.

省略:全ての要求に認証情報

は含まれない.
リソース要求で認証情報を含むオプションを使用する場合、ブラウザはアクセス制御-すべてのOriginだけでなく、他のソースのリソースを要求するときに追加のチェックを行います.
要求に検証情報が含まれている場合、ブラウザは、他のソースからのリソースを要求すると、CORSルールに違反しているかどうかを確認するルールに次の2つを追加します.
1.Access Control Allow-Originに*は含まれません.明示的なURLでなければなりません.
2.応答ヘッダには、アクセス制御のすべての認証情報が含まれている必要があります:true
📖 ソース:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://evan-moon.github.io/2020/05/21/about-cors/

My opinion

この記事では、初期設定時に「django-cors-headers」をインストールする理由とcorsの重要性について説明します.知れば知るほど知りたくなる世界.