ブラウザベースのアクセスで CORS オプションリクエストを有効にする

アカウントでこの機能を有効にするには、 Netskopeサポートにお問い合わせください。

クロスオリジンリソース共有（CORS）は、サーバーが外部のオリジンからのリソースへのアクセスを許可することを可能にするHTTPヘッダーの仕組みです。CORS ブラウザがサーバーに、HTTPメソッドとヘッダーを含む実際のリクエストを許可するかどうかを問い合わせるプリフライトリクエスト。

ブラウザはCORSリクエストを開始する前にプリフライトOPTIONSリクエストを送信しますが、このリクエストには認証クッキーを含めることはできません。ブラウザベースのアクセス機能は、すべての受信リクエストに対して認証を強制するように設計されています。その結果、認証されていないリクエストはすべて自動的に認証のためにIDプロバイダー（IdP）にリダイレクトされます。

このセキュリティ対策は、クロスオリジンリソース共有（CORS）オプションリクエストに依存するプライベートアプリに影響を与える可能性があります。このようなリクエストがブラウザベースのアクセスソリューションを経由してルーティングされる場合、CORSプロトコルの特性上、認証クッキーを伝送することができません。そのため、これらのリクエストは認証されていないものとして扱われ、認証のためにIDプロバイダーにリダイレクトされます。

CORS が問題である場合、 Netskope CORS OPTIONS リクエストサポート機能 (テナントレベルのフラグ) を有効にすることを推奨します。これにより、認証されていない OPTIONS リクエストが許可されます。

Enablement

この機能を使用するには、ブラウザベースのアクセスアプリ定義内で、認証されていない CORS を許可するトグルを有効にして、クロスオリジンリソース共有 (CORS) OPTIONS リクエストを許可します。この機能は、Any BrowserアプリとEnterprise Browserアプリの両方でサポートされています。

これはどのように作動しますか？

CORSプリフライトリクエストの例を以下に示します。

OPTIONS /doc HTTP/1.1
Host: bar.company.com
Origin: https://foo.company.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
<..>

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.company.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
<..>

上記の例では、プライマリドメイン（オリジン）はfoo.company.comです。セカンダリドメインはbar.company.comです。この使用ケースには、 foo.company.com がbar.company.comにリソースをリクエストすることが含まれます。このプロセスでは、プリフライトOPTIONSリクエストに続いて、 bar.company.comから目的のリソースに対するGETリクエストが行われます。

取引の順序は以下のとおりです。

リクエスト #0 : GET foo.company.com (認証クッキーなし)
このリクエストは IdP に転送され、認証後、Browser Access はドメインcompany.comのクッキーを設定します。
Request #1: GET foo.company.com (with authentication cookie set for the domain company.com)
This request returns a javascript with the fetch API to fetch a resource from bar.company.com.
リクエスト #2 : OPTIONS bar.company.com 。（認証クッキーなし）
発信元: foo.company.com .
セカンダリドメイン（ bar.company.comなど）で「認証なしのCORSを許可する」機能が有効になっている場合アプリケーション定義では、認証クッキーがなくてもOPTIONSリクエストは宛先に転送されます。
Request #3 : GET bar.company.com (with authentication cookie set for the domain company.com).

前提条件

foo.company.com （プライマリ）とbar.company.com （セカンダリ）の両方のリクエストは、同じ送信元（パブリック）IPアドレスから発信される必要があります。
プライマリ（オリジン）ドメインとセカンダリ（CORSリソース）ドメインが同じ場合（例： foo.company.comとbar.company.com ）、フェッチ要求にはクレデンシャル: 'include'オプションが含まれることが期待されます。このヘッダーを使用したJavaScriptのフェッチの例を以下に示します。
```
fetch('https://app-api.subdomain.domain.com/api/data', {
  method: 'GET'
  credentials: 'include', // Include cookies
  headers: {
    'Content-Type': 'application/json',
    // Other headers if needed
  },
})
```
CORS リソースへの HTTP 応答には、次の HTTP ヘッダーが含まれている必要があります: Access-Control-Allow-クレデンシャル: true

このヘッダーにより、ブラウザは（OPTIONSプリフライトリクエストが成功した後）GETリクエストの認証クッキーをCORSリソースリクエストに追加できるようになります。

重要な注意点

foo.company.com （プライマリ）とbar.company.com （セカンダリ）の両方がブラウザベースのアクセスアプリケーションとして定義され、ポリシーによって許可されることが想定されます。セカンダリドメイン（ bar.company.com ）のみ、CORSリソースドメインでは、「認証なしCORSを許可する」機能を有効にする必要があります。
foo.company.com （オリジン）ドメインは、ブラウザベースのアクセスを介してCORSリソース（ bar.company.com ）に対して認証され、有効な認証クッキーを持っていることが想定されます。認証なしでのアクセスを許可するようOPTIONSリクエストを送信します。