CORSとは何ですか？ブラウザのクロスオリジンアクセスの説明

CORSとは何ですか？

クロスオリジンリソースシェアリング、またはCORSは、サーバーがブラウザにどの他のオリジンがスクリプト駆動のリクエストを介してレスポンスを読み取ることができるかを通知するHTTPヘッダーのメカニズムです。オリジンはスキーム、ホスト、およびポートによって定義されます。CORSは承認されたレスポンスに対してブラウザの同一オリジンポリシーを緩和します；それはユーザーを認証せず、ビジネスアクションを認可せず、非ブラウザクライアントがHTTPリクエストを送信するのを止めることはありません。

有益な定義には、メカニズムとその境界の両方が含まれます。CORSは交換の特定の部分に影響を与えますが、隣接する責任はHTTP、ブラウザ、選択された輸送、アプリケーション、またはサーバーのデータモデルに残ります。これらの層を分離することで、エラーレポートの再現性が高まり、構成変更がアクセス制御の決定と誤解されることを防ぎます。

API開発者にとって、最初の質問は誰が値または動作を作成するかです。次の質問は誰がそれを解釈するかです。最後の質問は、どの観察可能な結果が解釈が機能したことを証明するかです。これらの三つの答えが、用語辞典の用語をテスト可能なインターフェース契約に変えます。

ブラウザがCORSの決定をどのように行うか

ページスクリプトが、ページオリジンとは異なるオリジンのURLに対してfetchまたはXMLHttpRequestを呼び出します。ブラウザは呼び出し元のオリジンを識別するOriginフィールドを追加します。一部のリクエストに対して、実際のリクエストを直接送信し、他のリクエストに対しては、意図されたメソッドと非安全リストフィールドを説明するOPTIONSプリフライトを最初に送信します。

サーバーはオリジンを評価し、アクセス制御レスポンスフィールドを返します。Access-Control-Allow-Originは、許可されたオリジンの名前を示すか、資格のない場合にはワイルドカードを使用します。他のフィールドは、メソッド、リクエストフィールド、資格情報、またはページスクリプトが読むことができる選択されたレスポンスフィールドを許可することがあります。

ブラウザはレスポンスをリクエストコンテキストと比較します。ポリシーが一致しない場合、スクリプトは保護されたレスポンスを読み取ることがブロックされますが、サーバーはHTTPリクエストを処理した可能性があります。この違いは、コンソールにCORSエラーが表示される一方でサーバーログに着信リクエストが表示される理由を説明しています。

認証されたリクエストには厳しいルールがあります。ワイルドカードオリジンはブラウザの資格情報と一緒に使用できず、サーバーは資格情報を明示的に許可する必要があります。CookieのSameSiteルールとアプリケーションの認可は独立して適用されます。

権限を定義するCORSフィールド

次の用語は、しばしば一つのラベルにまとめられるコンポーネントを区別します。これらは、ネットワークトレースの装飾としてではなく、参加者間のインターフェースとして読んでください。

なぜCORSがウェブデータ収集で重要なのか

CORSは、到着するバイト、これらのバイトがどのように解釈されるか、またはブラウザコードが結果を観察できるかを変更する可能性があります。収集ワークフローは、ツールを変更する前にその効果を特定するべきです。要求されたURL、最終URL、レスポンスステータス、表現タイプ、関連するプロトコルフィールド、および1つの期待されるコンテンツマーカーを記録します。そのコンパクトな記録は、正しいページとアクセスメッセージ、同意画面、リダイレクトターゲット、空のアプリケーションシェル、または互換性のないエンコーディングを区別します。

直接HTTPは、必要なデータがオープンサーバーによってレンダリングされたレスポンスに存在する場合、最も単純な取得パスです。承認されたコンテンツがJavaScriptの実行、ブラウザ管理の状態、ナビゲーション、またはブラウザのセキュリティポリシーに依存する場合、ブラウザは重要になります。これら2つのパスは同じように見えるように強制されるべきではありません：ブラウザはクッキー、圧縮、リダイレクト、CORS、およびストレージをプラットフォームのルールに従って管理しますが、直接クライアントは異なるデフォルトのセットを露出します。

セッションの継続性は、1つのレスポンスが次のリクエストの状態を確立する場合に重要です。認可されたシーケンスを1つの制約されたクライアントコンテキスト内に保持し、必要なロケールとネットワークオリジンを維持し、無関係なジョブからの状態を混在させることを避けます。プロキシはネットワークオリジンを変更します；ヘッダーを再現したり、表現をデコードしたり、スクリプトを実行したり、制限されたコンテンツへのアクセスを付与したりすることはありません。

解析は、表現の検証の後にのみ開始されます。フィールドを抽出する前に、最終ホスト、利用可能な場合の標準的なアイデンティティ、メディアタイプ、デコード状態、および必要なビジネスマーカーを確認してください。この順序により、パーサーがエラードキュメントを技術的に成功したように見える空のレコードに変えてしまうことを防ぎます。

仲介者は明示的な注意が必要です。コンテンツ配信ネットワークはエンコードされたバリアントを選択でき、ゲートウェイはOPTIONSに応答でき、キャッシュは交渉された応答を再利用でき、アプリケーションサーバーはクッキーまたは認証フィールドを設定できます。アプリケーションコードと最終ページ出力のみを比較すると、決定を下したかもしれないレイヤーをスキップします。

Scrapeless Universal Scraping APIは、チームが許可された公開コンテンツの管理された取得を必要とする場合に関連します。JavaScriptでレンダリングされたページを含めます。取得契約は依然としてターゲット、許可されたフィールド、期待される表現、受け入れマーカー、および停止条件を定義する必要があります。製品機能はソース条件、プライバシー審査、またはアプリケーションレベルの検証に取って代わるものではありません。

実際の製品に一致するCORS設定

CORSは、具体的な製品の動作、互換性要件、または診断決定を変更するときにアーキテクチャにおいて位置を与えます。これらのユースケースは、まず仕事を説明し、次にプロトコルの機能を説明します。

CORS、同一オリジンポリシー、CSRF、認証

CORSはHTTPの一つのレイヤーに属し、隣接するレイヤーと混同してはいけません。健全な実装は、どのコンポーネントが値を選択するか、どのコンポーネントがそれを変更できるか、最終的な表現が正しいことを証明する証拠が何かを特定します。

比較は、レイヤーの境界を保持する場合にのみ有用です。二つのメカニズムは一つのリクエスト内で共存でき、一方を置き換えても自動的に他方を置き換えるわけではありません。選択された動作を入力、観察可能な出力、障害状態、所有権に関して文書化します。

CORSの誤設定と誤った修正

• すべてのオリジンを反映させる。 検証されていない入力をエコーすることで、攻撃者のオリジンに対してブラウザの読み取りアクセスを許可することがあります。
• 認証情報のあるワイルドカードの使用。 認証されたブラウザリクエストには、ワイルドカードの許可ではなく、明示的に許可されたオリジンが必要です。
• CORSを認証と扱う。 CORSはブラウザの応答アクセスを管理し、サーバーはすべての操作を認証し、承認する必要があります。
• 成功した応答にのみヘッダーを追加しています。 エラーおよびプリフライト応答は、ブラウザが有用な診断情報を公開するために必要なポリシーフィールドも必要です。
• アクセスを解決するためにno-corsを使用しています。 結果として得られた不透明な応答は通常の読み取り可能なAPI応答ではなく、不足しているサーバー権限を付与しません。
• キャッシュのバリエーションを忘れること。 動的オリジン応答は、1つのテナントの許可が別のテナントに提供されないように、キャッシュ動作でオリジンを考慮する必要があります。

多くの失敗は、ライブラリやブラウザが自動的に行ったことについての前提を取り除いた後、診断が容易になります。最小限のトレースをキャプチャし、秘密情報を削除し、1つの制御された変数を一度に変更します。目標は戻された表現の安定した説明であり、無関係なヘッダー調整のコレクションではありません。

ページからオリジンまでのCORS診断

このシーケンスは、ローンチ前のデザインレビューとして、そして動作の変更後のプロダクション診断として機能します。それはプロトコルの証拠をアプリケーションの結果に関連付けて保ちます。

1. ページのオリジンとターゲットオリジンをスキーム、ホスト、ポートとしてメモします。
2. ブラウザのネットワークパネルを調査して、失敗した交換がプリフライトか実際のリクエストかを判断します。
3. 応答内のOriginリクエストフィールドと正確なAccess-Control-Allow-Origin値をチェックします。
4. プリフライトの場合、要求されたメソッドとフィールド名をサーバーの許可リストと比較します。
5. 資格情報については、明示的なオリジンの許可、資格情報の許可、クッキー規則、およびアプリケーションの承認を別々に確認します。
6. リダイレクトおよびゲートウェイ応答を確認します。異なるレイヤーが必要なフィールドを省略している可能性があります。
7. 実際のブラウザコンテキストで検証します。コマンドラインの成功は、ブラウザポリシーが通過することを証明しません。

小さな受け入れられたサンプルと同じ削除規則で拒否されたサンプルを保存することでレビューを終了します。将来の変更は、メモリやスクリーンショットだけでなく、既知のページのアイデンティティ、期待されるフィールド、およびデコードされたコンテンツと比較できます。

CORSのためのセキュリティと可視性

CORSは、ブラウザ、ゲートウェイ、キャッシュ、およびオリジンサーバーを越える可能性のあるリクエストパスに参加します。各ホップは、理解できる値のみを受け入れ、存続しなければならないフィールドを保持し、ログに資格情報や個人データをコピーすることを避けるべきです。プロトコルの構文は承認ではありません。

操作記録は、要求されたURL、最終URL、ステータス、表現タイプ、関連フィールド名、および制限されたコンテンツマーカーを記録する必要があります。完全なボディと資格情報の値は、定常的な診断にはほとんど必要なく、不必要な保持リスクを生む可能性があります。

ブラウザの動作と直接HTTPの動作は異なるテストサーフェスです。CORS、クッキーの保存、自動解凍、およびリダイレクト処理は、ブラウザまたはライブラリによってアプリケーションコードが結果を確認する前に実行される可能性があります。キャプチャを比較する際には、クライアントとそのデフォルトを記録します。

CORSを定義する標準

Fetch Standard CORSプロトコル 現在のブラウザのCORS処理を定義します。この主要な情報源は、この文書で使用される語彙と境界を修正しますが、実装の動作は依然として選択したクライアントおよび展開で観察する必要があります。

MDNのCORSガイド シンプルおよびプリフライト交換を説明します。この主要な情報源は、この文書で使用される語彙と境界を修正しますが、実装の動作は依然として選択したクライアントおよび展開で観察する必要があります。

ウェブオリジン仕様 ウェブセキュリティで使用されるオリジン概念を定義します。この主要な情報源は、この文書で使用される語彙と境界を修正しますが、実装の動作は依然として選択したクライアントおよび展開で観察する必要があります。

MDNの同一オリジンポリシーガイド CORSが緩和できるブラウザの境界を説明します。この主要な情報源は、この文書で使用される語彙と境界を修正しますが、実装の動作は依然として選択したクライアントおよび展開で観察する必要があります。

正しいCORSメンタルモデル

CORSはサーバーフィールドによって制御されるブラウザ強制の応答読み取り許可です。それは、認証、承認、クッキーポリシー、およびリクエスト偽造防御を置き換えるのではなく、補完します。

そのルールを受け入れテストに入れます。どの参加者が信号を送信するか、どの参加者がそれを解釈するか、どの中間者がパスを変更できるか、そしてどのコンテンツマーカーが成功を証明するかを示します。これにより、CORSは失敗後に付加されたラベルではなく、可視化可能なシステムの一部になります。

参照

• Scrapeless Universal Scraping API ドキュメント
• Scrapeless Universal Scraping API 製品概要
• Scrapeless のヘッダー、クッキー、セッション、表示検証に関するガイド
• GitHub の Scrapeless