私の観点からすると、クロスオリジンリソース共有 (CORS)そしてコンテンツ セキュリティ ポリシー (CSP)目的と実装は非常に似ているようです。
どちらも、HTTP 応答ヘッダーを介して、Web ページの侵害されていないバージョンに組み込まれているリソースのソースをホワイトリストに登録できるようです。私が見つけた唯一の違いは、CSP では HTTP 応答で承認できる内容がより細かく設定されているように見えることです。
ベストアンサー1
CORSは、同一起源ポリシードメインに対して緩和される。
たとえば、通常、ユーザーが と の両方にログインするとexample.com、example.org同一生成元ポリシーによりexample.comへの AJAX リクエストの送信example.org/current_user/full_user_detailsや のレスポンスへのアクセスが防止されます。
これは Web のデフォルト ポリシーであり、複数のサイトに同時にログインしたときにユーザーのデータが漏洩するのを防ぎます。
CORS を使用すると、example.orgオリジンが AJAX によって行われた応答を読み取ることを許可するポリシーを設定できます。これは、 と の両方が同じ会社によって実行され、オリジン間のデータ共有がユーザーのブラウザーで許可されるhttps://example.com場合に実行されます。これはクライアント側にのみ影響し、サーバー側には影響しません。example.comexample.org
一方、CSPは、現在のサイトで実行できるコンテンツに関するポリシーを設定します。たとえば、JavaScriptをインラインで実行できるかどうか、どのドメイン.jsからファイルをロードできるかなどです。これは、不正なアクセスに対する別の防御線として機能するのに役立ちます。クロススレッド攻撃者はHTMLページにスクリプトを挿入しようとします。通常出力はエンコードされるただし、開発者が 1 つの出力フィールドのみを忘れていたとします。ポリシーによってインライン スクリプトの実行が防止されるため、攻撃は阻止されます。