CORSとは？

Scrapeless Agent Browserは、ブラウザのクロスオリジンルールの下でウェブサイトがどのように動作するかを観察できるブラウザセッションを実行します。

クロスオリジンリソースシェアリング（CORS）は、サーバーがブラウザが別のオリジンで実行されているスクリプトに応答を公開できるかどうかを表明するHTTPヘッダーのメカニズムです。オリジンとは、スキーム、ホスト、ポートの組み合わせです。CORSは、あるオリジンから読み込まれたページが別のオリジンのAPIを呼び出したいことが多いため、重要です。ブラウザは、その応答がCORSのルールを満たさない限り、その読み取りを制限します。

CORSエラーは、ネットワーク障害やAPI認証の問題として誤解されることがあります。リクエストはサーバーに到達しているかもしれず、サーバーがデータを返したかもしれませんが、ブラウザはそのデータをページスクリプトに利用できるようにしません。ブラウザの判断をAPIのビジネス判断とは別に診断してください。

オリジン境界にCORSが適用される

2つのURLは、スキーム、ホスト、ポートが一致する場合にのみ同じオリジンを共有します。httpからhttpsに変更したり、サブドメインに移動したり、別のポートを使用したりすると、異なるオリジンが生成されます。あるページは、応答ボディにアクセスせずにいくつかのクロスオリジンリクエストを行うことができます。 MDN CORSガイド は、スクリプトによって行われるクロスオリジンHTTPリクエストのための同一オリジンポリシーの制御された緩和について説明しています。

サーバーは、Access-Control-Allow-Originのような応答ヘッダーで権限を伝えます。ブラウザは、その値をリクエストページのオリジンと比較します。ブラウザはページスクリプトの強制ポイントです。コマンドラインクライアントは、ブラウザのCORSルールを適用せずにHTTPリクエストを送信できるため、コマンドラインの成功した応答は、Webページが同じリソースを読み取れることを証明するものではありません。

CORSは認証システムではありません。サーバーは依然として呼び出し元を認証し、リソースの権限を確認しなければなりません。応答を読み取る権限をオリジンに付与することは、ユーザーがプライベートアカウントレコードを表示できるかどうかを決定することとは異なります。それらを別々のコントロールとして扱い、両方をテストしてください。寛容なCORS構成は、サーバー側のアクセスチェックを安全に置き換えることはできません。

単純リクエストとプリフライトリクエスト

いくつかのクロスオリジンリクエストの場合、ブラウザは実際のリクエストを送信し、その後で応答権限を確認します。他のリクエストにはプリフライトが必要です。ブラウザは、提案されたメソッドとヘッダーが許可されているかどうかを尋ねるために、最初にOPTIONSリクエストを送信します。 プリフライト定義 は、必要に応じてAccess-Control-Request-Headersを含むOriginおよびAccess-Control-Request-Methodフィールドを特定します。

カスタム認証ヘッダーまたは安全リストにないコンテンツタイプを持つリクエストは、プリフライトを引き起こす可能性があります。プリフライトが失敗すると、ブラウザは関連する実際のリクエストを送信しません。その違いは診断時に重要です。POSTがないアプリケーションサーバーログでも、OPTIONSリクエストが表示されることがあります。POSTルートのみを確認する開発者は拒否ポイントを見逃すかもしれません。

プリフライト承認は、要求されたメソッド、ヘッダー、オリジン、リソースルールにスコープされます。それは後のビジネスオペレーションが成功することを意味しません。実際のリクエストは、認証や検証に失敗する可能性があります。逆に、失敗したプリフライトは、APIがユーザーデータを拒否した証拠ではありません。データを含むリクエストは、決してアプリケーションに到達しないこともあります。

資格情報が応答ルールを変更する

クロスオリジンリクエストには、クッキーや他のブラウザ管理の資格情報が関与することがあります。ページが資格情報を持つ応答を期待する場合、ワイルドカードのAccess-Control-Allow-Origin値は十分ではありません。サーバーは許可されたオリジンを特定し、関連する資格情報応答ルールを適用する必要があります。 MDN資格情報エラーガイド は、ワイルドカードと資格情報の組み合わせが失敗する理由を説明しています。

リクエストの資格情報モードとクッキーポリシーは別々の入力です。ブラウザは、CORSヘッダーが正しいように見える場合でも、SameSite、Secure、またはドメイン設定のためにクッキーを省略することがあります。認証エラーは、CORSチェックが成功した後に発生する可能性があります。CORSフィールドを変更して、決して送信されなかったクッキーに対処する代わりに、開発者ツールでリクエストと応答を検査してください。

検証なしにすべてのリクエスト元を動的に許可すると、信頼できないページに対して機密の応答が公開される可能性があります。資格情報を必要とするデータに対して明示的なオリジンポリシーを維持し、応答がオリジンに依存する場合はキャッシュが適切に異なることを確認してください。セキュリティレビューには、公開テキストを返すテストエンドポイントではなく、実際に認証されたリソースが含まれるべきです。

ブラウザのCORS失敗を診断する方法

ページのオリジンと最終ターゲットオリジンから始めます。リダイレクトを含むログインホストにリダイレクトするリクエストは、元のAPI URLとは異なるポリシーが必要となる場合があります。ブラウザの開発者ツールで、存在する場合はOPTIONSのやり取りを検査し、送信された場合は実際のリクエストと応答ヘッダーを確認します。 CORSエラーカタログ は、一般的なコンソールメッセージを不足しているまたは互換性のない応答フィールドにマッピングします。

失敗したフェッチ呼び出しは、JavaScriptに対して一般的なエラーのみを表示するかもしれませんが、コンソールには特定のCORS理由が含まれます。両方の表面を記録してください。応答がAccess-Control-Allow-Originを欠いているか、異なるオリジンを名前付けしているか、許可されたメソッドやヘッダーを省略しているか、資格情報モードと矛盾しているかを確認してください。制御しているサーバーで1つの構成変更を加えた後、同じページとリクエストを再度テストしてください。

ブラウザ拡張を追加したり、セキュリティチェックを無効にしたりしないでください。これは本番環境の修正としては不適切です。そのようなローカルな変更は、リアルユーザーがブロックされるのを残しつつ、統合の欠陥を隠す可能性があります。APIがサードパーティであり、あなたのページオリジンを許可しない場合は、サポートされているサーバー側の統合アーキテクチャを使用するか、プロバイダーに文書化されたブラウザアクセスパスを問い合わせてください。

ブラウザの自動化とデータ収集におけるCORS

実際のブラウザセッションは、ブラウザのセキュリティルールに従ってページスクリプトを実行します。 Scrapeless Agent Browser は、リモートで制御されたブラウザ実行を提供し、クロスオリジンリクエストを行うページをその環境で観察できます。 Agent Browserの紹介 はブラウザ製品を説明しています。これは、未承認のAPIレスポンスを承認されたものに変えることはありません。

サーバーサイドのデータリクエストには異なるCORS境界があります：ブラウザCORSはバックエンドHTTPクライアントを支配しません。他の制御も依然として適用され、提供者の資格情報、ターゲットの権限、レートポリシーが含まれます。ページの自身の動作をテストまたは再現する必要がある場合はブラウザを選択してください。直接データ交換がタスクであり、提供者がそれをサポートしている場合は文書化されたサーバーAPIを選択してください。

関連する ブラウザネットワーク検査ガイド はページが使用するリクエストの観察について説明しています。観察は、その意図されたコンテキストの外でプライベートエンドポイントを使用する権限を意味しません。ブラウザトレースを確認する際は、タスクに必要な公開または明示的に承認されたデータに焦点を当て、資格情報を共有ログから外してください。

実用的なCORS判断チェックリスト

リソースの所有者とそれを呼び出すページのオリジンを特定します。ブラウザスクリプトが本当にレスポンスを読み取る必要があるかどうかを決定します。必要がある場合は、リソースサーバーを構成して、意図されるオリジン、メソッド、ヘッダー、および資格情報の動作のみを許可します。必要がない場合は、ブラウザがサードパーティAPIに直接アクセスする必要がない制御されたバックエンドで呼び出しを維持します。

本番環境で使用される正確なメソッドとヘッダーをテストします。カスタムフィールドなしのGETは動作するかもしれませんが、認証ヘッダーのあるJSON POSTはプリフライトをトリガーします。また、エラーパスもテストします：正しいCORSヘッダーを持つ成功レスポンスは、認証の失敗やリダイレクトがそれらを省略する場合には不十分です。ブラウザユーザーは、実際の失敗を可視化し、診断できる必要があります。

最後に、インシデントノートで三つの観察を分離します：ネットワークリクエストが行われたか、サーバーが操作を受け入れたか、ブラウザがレスポンスをページスクリプトに露出させたか。これらの答えは異なる場合があります。それらを区別することで、ブラウザポリシーの問題が無関係なサーバー承認を弱めることで「修正」されるのを防ぎます。

結論

CORSはリソースサーバーがどの他のオリジンがブラウザスクリプトからのレスポンスを読むことができるかを指定することを可能にします。その効果はページオリジン、リクエストの形状、プリフライト、および資格情報モードに依存します。それらの部分を診断しながら、認証とサーバーサイドの権限チェックを維持します。