CORSを有効にできるのはいつですか？
私は、JSON/REST Web APIを開発しています。そのために、サードパーティのWebサイトがAJAXを介してサービスを呼び出すことができるようにしたいのです。したがって、私のサービスは有名なCORSヘッダーを送信しています。
Access-Control-Allow-Origin: *
これにより、サードパーティのサイトがAJAXを介して私のサービスを呼び出すことができます。これまでのところ順調です。
ただし、私のWeb APIのサブセクションは非公開であり、認証が必要です（OAuthとaccess_token Cookieを含むかなり標準的なもの）。サイトのこの部分でもCORSを有効にしても安全ですか？ ？
一方では、サードパーティのWebサイトに、私のサービスのこの部分とやり取りするAjaxクライアントが含まれているとよいでしょう。ただし、そもそも同じOriginポリシーがある理由は、これにはリスクがある可能性があるためです。後でアクセスするWebサイトがプライベートコンテンツにアクセスできるようにしたくない場合。
私が恐れているシナリオは、ユーザーがWeb APIまたは彼が信頼するWebサイトを介してWeb APIにログインし、ログアウトするのを忘れることです。これにより、彼が後にビストする他のすべてのWebサイトが、既存のセッションを使用してプライベートコンテンツにアクセスできるようになりますか？
だから私の質問：
- 非公開コンテンツでCORSを有効にしても安全ですか？
- CORS対応サーバーがCookieを介してsession_tokenを設定する場合、このCookieはCORSサーバーまたはメインWebページサーバーのドメインの下に保存されますか？
2番目の質問（CORS対応サーバーがCookieを使用してsession_tokenを設定する場合...？）への回答では、CookieはCORSサーバーのドメインの下に保存されます。メインWebページのJSコードは、document.cookie経由であってもCookieにアクセスできません。 Cookieは.withCredentialsプロパティが設定されている場合にのみサーバーに送信され、それでもサーバーがAccess-Control-Allow-Credentialsヘッダーを設定する場合にのみ受け入れられます。
最初の質問はもう少しオープンエンドです。それはかなり安全ですが、物事を回避する方法があります。たとえば、攻撃者はDNSポイズニング技術を使用して、プリフライトリクエストを実際のサーバーにヒットさせ、実際のCORSリクエストを不正なサーバーに送信する可能性があります。 CORSセキュリティに関するその他のリソースを次に示します。
最後に、あなたの懸念は、anyWebサイトにCORSデータへのアクセスを与えることです。これを防ぐために、Access-Control-Allow-Origin: *ヘッダーを使用しないでください。代わりに、ユーザーのOrigin値をエコーバックする必要があります。例えば：
Access-Control-Allow-Origin: http://www.example.com
このヘッダーでは、http://www.example.comのみが応答データにアクセスできます。
CORSの意図は、XHR要求に対するクロスオリジン要求を許可する一方で、サーバーにどのOriginがどのリソースにアクセスするかを指定する権限を与えることです。特に、CORSはOriginヘッダーフィールドを導入しました。これにより、サーバーは通常のXHR要求と可能性のあるXHR要求を区別できます。このヘッダーフィールドは、ユーザーが設定または変更することはできませんが、XHR要求用にブラウザーによって設定されます。
そのため、XHRでのみ使用されるように設計されたAPIがある場合、リクエストをCORSに準拠するように要求できます（要求する必要があります）。特に、リクエストがサーバー上の状態を変更できる場合、そうしないとCSRFに対して脆弱になります。
CSRF攻撃は、GETおよびPOST=リクエストを偽造するために他の方法を使用するCORSに関係なく可能です。CORSは、サーバーが許可する場合、JavaScriptを使用してXHRリクエストのサーバーの応答にアクセスすることのみを可能にします。