Web ブラウザーでの CORS の仕組みを理解する

Cross-Origin Resource Sharing (CORS) は、Web アプリケーションが別のドメインからリソース (データ、画像、スクリプトなど) を要求する方法を制御する Web ブラウザーの重要なセキュリティ機能です。最初の Web ページを提供したものよりも。これは主に、他の Web サイト上の機密情報にアクセスしようとする悪意のあるサイトからユーザーを保護するように設計されています。このブログでは、CORS がどのように機能するのか、そして Web 開発にとって CORS がなぜ重要なのかを説明します。
CORS とは何ですか?
簡単に言うと、CORS は、Web ページがさまざまなドメインからどのリソースを要求できるかを制御するブラウザーのメカニズムです。デフォルトでは、ブラウザーは Same-Origin Policy (SOP) を実装しており、Web ページがページのロード元のドメイン以外のドメインにリクエストを行うことを制限します。このポリシーは、Web サイト間の潜在的に有害なやり取りを防止する基本的なセキュリティ機能です。

ただし、正当なクロスオリジン リクエストが必要になるケースも数多くあります。たとえば、Web アプリケーションが別のサーバーでホストされている API からデータをフェッチする必要がある場合です。 CORS は、サーバーがリソースへのアクセスを許可されるドメインを指定できるようにすることで、このようなリクエストを安全な方法で可能にします。

CORS はどのように機能しますか?
CORS は、サーバーからの応答に HTTP ヘッダーを追加して、クロスオリジン要求が許可されているかどうかを示すことによって機能します。 CORS の動作を段階的に説明します。

クライアントがリクエストを行う
Web ページが別のオリジン (ドメイン、プロトコル、ポートによって定義される) に対してリクエスト (XMLHttpRequest、フェッチ、スクリプト インクルードなど) を実行しようとすると、ブラウザはリクエストが同一オリジン ポリシーに違反しているかどうかをチェックします。 🎜>

CORS プリフライト リクエスト (複雑なリクエストの場合)

一部のリクエスト、特に PUT、DELETE などのメソッドを使用したリクエスト、またはカスタム ヘッダーを使用したリクエストは「複雑」とみなされます。実際のリクエストを送信する前に、ブラウザはプリフライト リクエストと呼ばれる OPTIONS リクエストを送信します。このプリフライト リクエストは、サーバーに実際のリクエストを許可するかどうかを尋ね、許可されている HTTP メソッド、ヘッダー、およびオリジンを確認します。

サーバーが CORS ヘッダーで応答します

プリフライトまたは実際のリクエストを受信したサーバーは、リクエストが許可されているかどうかを示す特定のヘッダーを含む応答を送り返します。主要なヘッダーには次のものが含まれます:

Access-Control-Allow-Origin: このヘッダーは、リソースへのアクセスを許可するドメインを指定します。このヘッダーにリクエストの発信元が含まれている場合、ブラウザは応答を許可します。たとえば、サーバーは次のように応答する可能性があります:

Access-Control-Allow-Origin: https://example.com

Access-Control-Allow-Methods: このヘッダーは、サーバーがクロスオリジンリクエストを許可する HTTP メソッド (GET、POST、PUT など) を指定します。

Access-Control-Allow-Methods: GET, POST

Access-Control-Allow-Headers: 実際のリクエストにどのカスタム ヘッダーを含めることができるかを指定します。

Access-Control-Allow-Headers: Content-Type, Authorization

Access-Control-Allow-Credentials: サーバーが資格情報 (Cookie、HTTP 認証) を許可する場合、このヘッダーが含まれ、true に設定されます。

ブラウザが決定します

サーバーの応答を受信した後、ブラウザはヘッダーを評価します。サーバーが適切な CORS ヘッダーを通じてアクセス許可を付与すると、ブラウザーはクロスオリジン要求を許可し、応答を処理します。そうでない場合、ブラウザはリクエストをブロックし、Web ページはリソースにアクセスできなくなります。

単純な CORS リクエストの例

https://example.com でホストされている Web ページが、https://api.example.com/data でホストされている API に対して GET リクエストを実行しようとするシナリオを考えてみましょう。

fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

この場合、ブラウザはリクエストを https://api.example.com に送信します。 API サーバーが https://example.com からのリクエストを許可するように設定されている場合、次のヘッダーで応答します:

Access-Control-Allow-Origin: https://example.com

ヘッダーが存在しないか正しくない場合、ブラウザは CORS ポリシーにより応答をブロックします。

CORS プリフライトの例

より複雑なリクエストの場合、ブラウザはプリフライト リクエストを開始して、クロスオリジン リクエストが許可されているかどうかを確認します。以下は、プリフライトをトリガーする PUT リクエストの例です:

fetch('https://api.example.com/update', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ key: 'value' })
});

ブラウザは次のような OPTIONS リクエストを送信します。

OPTIONS /update HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

サーバーは、このリクエストが許可されているかどうかを示すヘッダーで応答する必要があります:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: Content-Type

これらのヘッダーが存在し、有効な場合、ブラウザは実際の PUT リクエストを続行します。

CORS の重要性

CORS は、Web サーバーがリソースへのアクセスを制御するためのきめ細かいメカニズムを提供するセキュリティ機能です。 CORS がなければ、悪意のある Web サイトはユーザーの同意なしに他のドメインから機密データを簡単に取得でき、クロスサイト リクエスト フォージェリ (CSRF) などのセキュリティ脆弱性を引き起こす可能性があります。

結論
API やサードパーティのリソースを使用する Web 開発者にとって、CORS を理解することは不可欠です。サーバー上で適切な CORS ポリシーを構成することで、開発者は正当なクロスオリジン対話を可能にしながら、アプリケーションの安全性を確保できます。

Web アプリを開発していて CORS エラーが発生した場合は、サーバーの構成をチェックし、必要なヘッダーが応答で送信されていることを確認することが重要です。

以上がWeb ブラウザーでの CORS の仕組みを理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。