私の観点からすると、クロスオリジンリソースシェアリング(CORS)およびコンテンツセキュリティポリシー(CSP)と呼ばれるテクノロジーは、目的と実装が非常に似ているようです。
どちらも、HTTP応答ヘッダーを介して、Webページの妥協のないバージョンに組み込まれているリソースの起源をホワイトリストに登録できるようです。私が見ることができる唯一の違いは、HTTP応答で承認できるものにおいてCSPがよりきめ細かいように見えることです。
CORSでは、ドメインの Same Origin Policy を緩和できます。
例えば通常、ユーザーが両方のexample.com
およびexample.org
、同一生成元ポリシーによりexample.com
AJAXへのリクエストからexample.org/current_user/full_user_details
および応答へのアクセスを取得します。
これはWebのデフォルトポリシーであり、複数のサイトに同時にログインしたときにユーザーのデータが漏洩するのを防ぎます。
CORSを使用すると、example.org
は、Originを許可するというポリシーを設定できますhttps://example.com
AJAXによって行われた応答を読み取ります。両方のexample.com
およびexample.org
は同じ会社によって運営されており、オリジン間のデータ共有はユーザーのブラウザで許可されます。サーバー側ではなく、クライアント側にのみ影響します。
一方、CSPは、現在のサイトで実行できるコンテンツのポリシーを設定します。たとえば、JavaScriptをインラインで実行できる場合、またはどのドメイン.js
ファイルをロードできます。これは、攻撃者がHTMLページにスクリプトを挿入しようとする [〜#〜] xss [〜#〜] 攻撃に対する別の防衛線として機能するのに有益です。通常、 出力はエンコードされます 、ただし、開発者は1つの出力フィールドのみを忘れていたと言います。ポリシーがインラインスクリプトの実行を妨げているため、攻撃は阻止されます。
CORSを使用すると、サイトAは、サイトBに(訪問者のブラウザと資格情報を使用して)サイトAから(潜在的にプライベート)データを読み取る許可を与えることができます。
CSPにより、サイトはitselfが(XSSに対する防御としてなど)予期しないソースから(潜在的に悪意のある)コンテンツをロードするのを防ぐことができます。
上記の回答はいずれも、CSPとCORSの明確で簡潔な違いを示していません。それらについての私の考え方は次のとおりです。
abc.comにリクエストを送信したいウェブサイトdef.netがあるとします。
したがって、CSPは上記の例でabc.comを保護し、same-Originポリシー(CORSの欠如)はdef.netを保護します。
CORSは、そのサービスを使用するための承認について第三者に確認します。そのため、第三者は許可を提供または拒否します。
たとえば、www.example.comのページがwww.example.orgにリクエストを行う必要がある場合、リクエストの前兆としてOrigin:www.example.comを指定してwww.example.orgに送信されたOPTIONSリクエストを送信する必要があります承認のため。現在、www.example.orgは許可を提供または拒否しています。
CSPは、特定の種類のコンテンツのロード元を指定することで、Webページが第三者から不注意に悪意のあるコンテンツをロードするのを防ぎます。したがって、たとえば、ディレクティブを使用して、次の各スクリプト、CSS、メディアなどに有効なソースを提供できます。
例:
コンテンツセキュリティポリシー:default-src 'none'; script-src 'self' www.google-analytics.com ajax.googleapis.com; connect-src 'self'; img-src 'self'; style-src 'self';