Clever Geek Handbook

Common Origin Policy and CORS：ビジュアルガイド





良い一日、友達！Lydia Hallieによる



記事「CSVisualized：CORS」の翻訳をあなたの注意を引くために提示します。



すべての開発者はエラーに対処する必要がありましたAccess to fetched has been blocked by CORS policy。この問題をすばやく解決するには、いくつかの方法があります。ただし、時間をかけてCORSポリシーとは何かを詳しく見てみましょう。



多くの場合、他の場所にあるデータを表示する必要があります。これを行う前に、ブラウザはこのデータを受信するためにサーバーにリクエストを送信する必要があります。



サイトwww.mywebsite.comにあるサーバーからサイトのユーザーに関する情報を取得したいとしますapi.website.com。







優れた！サーバーにリクエストを送信し、JSONデータを受信しました。



次に、同様のリクエストを別のドメインに送信してみましょう。代わりにとの要求を送信する、のは、聞かせwww.mywebsite.comてそれを送信www.anotherdomain.com。







どうした？まったく同じリクエストを送信しましたが、今回はブラウザになんらかのエラーが表示されます。



CORSが実際に動作しているのを確認しています。このエラーが発生したのはなぜですか？それはどういう意味ですか？



共通起源ポリシー



Webには、Generic Origin Policy（以下、POP）と呼ばれるものがあります。デフォルトでは、リクエストの発信元と同じ発信元にあるリソースにのみアクセスできます。たとえば、にある画像を読み込むことができますhttps://mywebsite.com/image1.png。



ソースが別の（サブ）ドメイン、プロトコル、またはポートにある場合、ソースは異なります。







かっこいいですが、なぜPOPが必要なのですか？



それが存在せず、叔母がFacebookに投稿したバイラルリンクを誤ってクリックしたとします。このリンクは、銀行のサイトをロードし、Cookieを使用して正常にログインするiframeが埋め込まれた「悪意のあるサイト」にリダイレクトします。



「邪悪なサイト」の開発者は、彼がiframeにアクセスでき、あなたの銀行のサイトのDOMのコンテンツと対話して、あなたに代わって彼のアカウントに資金を転送できることを確認しました。







ええ...これは深刻なセキュリティ問題です。私たちは、誰もが私たちの知らないうちに何かにアクセスすることを望んでいません。



幸い、EPPは存在します。このポリシーは、他のソースからのリソースへのアクセスを制限します。







この場合、ソースはwww.evilwebsite.comソースからリソースにアクセスしようとしていますwww.bank.com。EPPはこのアクセスをブロックし、悪意のあるサイト開発者が銀行データにアクセスすることを禁止します。



わかりました、しかし...それはどのように機能しますか？



クライアント側CORS



EPPはスクリプトにのみ適用されますが、ブラウザはそれをJavaScriptリクエストに「拡張」します。デフォルトでは、1つのソースからのリソースにしかアクセスできません。







うーん、でも...私たちはしばしば別のソースからリソースを取得する必要があります。おそらく、フロントエンドはサーバーAPIにアクセスしてデータをロードする必要があります。他のソースからリソースを安全に取得するために、ブラウザーはCORSと呼ばれるメカニズムを実装します。



CORSは、Cross-Origin ResourceSharingの略です。ブラウザは他のソースからのリソースを許可していませんが、CORSを使用して、安全を維持しながらこの制限を変更できます。



ユーザーエージェント（ブラウザ）は、CORSを使用して、一部のHTTP応答ヘッダーに基づいてブロックされるクロスオリジン要求を許可できます。



別のソースに対してリクエストが行われると、クライアントは自動的にヘッダーをHTTPリクエストに追加しますOrigin。このヘッダーの値がリクエストのソースです。







ブラウザが別のソースからリソースを取得できるようにするには、サーバーの応答に特定のヘッダーも含まれている必要があります。



サーバー側CORS



バックエンド開発者は、で始まるカスタムヘッダーを含めることで、他のソースがリソースを取得できるようにすることができますAccess-Control-*。このようなヘッダーの値に基づいて、ブラウザーはリソース共有を許可します。



CORSヘッダーはいくつかありますが、そのうちの1つは必須ですAccess-Control-Allow-Origin。



このヘッダーの意味によって、リソースが受信できるソースが決まります。



アクセス可能https://mywebsite.comである必要があるサーバーを開発している場合は、このドメインをヘッダーに追加する必要がありますAccess-Control-Allow-Origin。







すごい。このヘッダーは、クライアントに送信されるサーバー応答に追加されます。 EPPhttps://api.mywebsite.comは、から送信されhttps://mywebsite.comたリクエストを通じてリソースを受け取ることを妨げなくなりました。







ブラウザのCORSメカニズムは、応答Access-Control-Allow-Originヘッダーと要求ヘッダーの値が一致することを確認しますOrigin。



この場合、リクエストのソースはhttps://www.mywebsite.com、リストで指定された応答ヘッダーAccess-Control-Allow-Originです。







優れた。これで、他のソースからリソースを取得できます。リストされていないソースからこれを行おうとするとどうなりAccess-Control-Allow-Originますか？







はい、CORSはリソースへのアクセスをブロックしました。 



The 'Access-Control-Allow-Origin' header has a value
  'https://www.mywebsite.com' that is not equal 
to the supplied origin.


この場合、ソースはにhttps://www.anotherwebsite.comリストされていませんAccess-Control-Allow-Origin。 CORSは、要求されたデータを正常に拒否しました。



CORSを使用すると、*許可されるソースを値として指定できます。これは、リソースがすべてのソースで利用可能になることを意味するため、注意してください。



Access-Control-Allow-Origin設定できる多くのタイトルの1つです。バックエンド開発者は、特定の要求を許可（拒否）するようにCORSを構成できます。



もう1つの一般的な見出しはAccess-Control-Allow-Methodsです。 CORSは、指定された方法を使用して送信された他のソースからの要求のみを許可します。







この場合、GET、POST、またはPUTメソッドを使用して送信された要求のみが許可されます。 PATCHやDELETEなどの他のメソッドはブロックされます。



CORSは、PUT、PATCH、およびDELETEメソッドを使用して送信された要求に関しては、それらを特別な方法で処理します。これらの「トリッキーな」クエリは、プリフライトクエリと呼ばれることもあります。



予備リクエスト



CORSは、単純な要求と暫定的な要求の2種類の要求を処理します。クエリとは、その値の一部によって異なります。



GETまたはPOSTメソッドを使用して送信され、追加のヘッダーが含まれていない場合、要求は単純です。その他のリクエストは暫定的なものです。



わかりましたが、事前リクエストとはどういう意味で、なぜそのようなリクエストが必要なのですか？



実際のリクエストを送信する前に、クライアントは、実際のリクエストに関する情報（メソッド、追加のヘッダーなど）を含む予備リクエストをサーバーに送信しますAccess-Control-Request-*。







サーバーは暫定要求を受信し、CORSヘッダーを含む空の暫定応答を送信します。ブラウザは暫定的な応答を受け取り、実際の要求が許可されるかどうかを確認します。







その場合、ブラウザは実際の要求を送信し、それに応じてデータを受信します。







そうでない場合、CORSは事前リクエストをブロックし、実際のリクエストは送信されません。事前リクエストは、サーバー上でリソースがアクセスおよび変更されるのを防ぐための優れた方法です。これにより、他のソースからの潜在的に不要な要求からサーバーが保護されます。



繰り返される要求の数を減らすためAccess-Control-Max-Ageに、CORS要求にヘッダーを追加することにより、暫定応答をキャッシュできます。これにより、予備リクエストの再送信が回避されます。



資格情報



Cookie、認証ヘッダー、およびTLS証明書は、デフォルトでは、単一のソースからの要求に対してのみインストールされます。ただし、別のソースからのリクエストでこれらの権限を使用する必要がある場合があります。おそらく、サーバーがユーザーを識別するために使用できるリクエストにCookieを含めたいと思います。



CORSにはデフォルトで権限が含まれていませんが、ヘッダーを使用してこれを変更できますAccess-Control-Allow-Credentials。



別のソースからのリクエストにCookieやその他の認証ヘッダーを含める場合は、フィールドをリクエストのwithCredentials値trueに設定し、ヘッダーAccess-Control-Allow-Credentialsをレスポンスに追加する必要があります。







これで、別のソースからのリクエストに資格情報を含めることができます。



この記事がお役に立てば幸いです。清聴ありがとうございました。


More articles:


All Articles