WhatsMyIp.me の無料 IP チェッカー ツール

クロスオリジンリソース共有 (CORS) を理解する

クロスオリジンリソース共有 (CORS) を理解する

クロスオリジン リソース共有 (CORS) は、2006 年に World Wide Web Consortium (W3C) によって導入され、Web サーバーに、同一オリジン ポリシーを超えてサーバーのリソースへのアクセスが許可される他のオリジン (ドメイン、スキーム、またはポート) を指定する方法を提供しました。これは Web セキュリティの大きな進化であり、厳格なセキュリティ プロトコルを維持しながら、よりインタラクティブで統合された Web アプリケーションを実現しました。

CORS (Cross-Origin Resource Sharing) の仕組みを理解することは、現代の Web 開発にとって非常に重要です。このセクションでは、CORS が Web セキュリティを強化する仕組み、シンプル リクエストとプリフライト リクエストを区別する仕組み、および CORS ヘッダーの重要性について説明します。

クロスオリジンリソース共有とは何ですか?

CORS (クロスオリジンリソース共有)) HTTP ヘッダーを使用して、あるオリジン (ドメイン) で実行されている Web アプリケーションに、別のオリジンのサーバーから選択されたリソースにアクセスする権限を与えるようにブラウザに指示するメカニズムです。 これは、悪意のある攻撃から保護しながら、さまざまな Web サービス間のよりオープンな通信を可能にするため、Web セキュリティにおける重要な進歩です。

CORS が Web セキュリティを強化する仕組み: 技術的な洞察

CORS は、Web アプリケーションが Web サイトとは異なるオリジンでホストされているサーバーにリクエストを送信できるようにするセキュリティ機能です。

CORS 以前は、同一オリジン ポリシーによって、Web アプリケーションはサイトと同じドメインにのみリクエストを行うように制限されていました。このポリシーは、悪意のあるサイトが機密データにアクセスするのを防ぐ重要なセキュリティ対策ですが、最新の Web アプリケーションに必要な正当なクロスオリジン インタラクションも制限します。

CORS を使用すると、サーバーは、リソースへのアクセスが許可されているオリジンをブラウザに伝える特定のヘッダーを含めることができます。以下は、CORS がセキュリティを強化する基本的な例です。

  1. ウェブアプリケーション https://example.com リクエストを試みる https://api.example.org/data.
  2. ブラウザは自動的にCORSリクエストを送信します。 https://api.example.org/data.
  3. サーバー https://api.example.org CORSポリシーをチェックして、 https://example.com 許可されています。
  4. もし https://example.com 許可されている場合、サーバーは適切なCORSヘッダーで応答します。 Access-Control-Allow-Origin: https://example.comブラウザが Web アプリケーションにリソースへのアクセスを許可する必要があることを示します。

CORS がない場合、同一オリジン ポリシーによってリクエストがブロックされますが、CORS を使用すると、サーバーは信頼できるオリジンからのクロスオリジン リクエストを安全に許可できます。

シンプルリクエストとプリフライトリクエストの違いを理解する

CORS リクエストは、シンプル リクエストとプリフライト リクエストの 2 種類に分類されます。これらの違いは、使用される方法とリクエストとともに送信されるヘッダーに基づいています。

  • シンプルなリクエスト: CORSで定義された特定の基準を満たすリクエストです。シンプルなリクエストでは、GET、POST、HEADメソッドを使用できます。さらに、次のような安全でユーザー定義ではないヘッダーのみを使用する必要があります。 Accept, Accept-Language, Content-Language、 そして Content-Type 値は application/x-www-form-urlencoded, multipart/form-data、 または text/plain簡単なリクエストの例を次に示します。
fetch('https://api.example.org/data', {
  method: 'GET',
  headers: {
    'Accept': 'application/json',
  }
});
  • 事前リクエスト: これらのリクエストは、単純なリクエストの基準を満たしておらず、実際のリクエストを送信する前に、OPTIONS メソッドを使用した最初の「プリフライト」リクエストが必要です。このプリフライトは、ターゲット リソースの CORS ポリシーに基づいて、実際のリクエストを送信しても安全かどうかを確認します。プリフライト リクエストは、メソッドが GET、POST、HEAD 以外の場合、またはカスタム ヘッダーが使用されている場合に使用されます。次に例を示します。
fetch('https://api.example.org/data', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  },
  body: JSON.stringify({key: 'value'})
});

この場合、ブラウザはまずOPTIONSリクエストを送信します。 https://api.example.org/data POSTリクエストが Content-Type の application/json カスタムヘッダー X-Custom-Header 許可されています。

CORS ヘッダーの説明: CORS ヘッダーとは何か、どのように機能するか

CORS は、サーバーとブラウザ間の通信に特定の HTTP ヘッダーに依存します。これらのヘッダーは、ブラウザがリクエストをブロックするか、続行を許可するかを決定します。主要な CORS ヘッダーは次のとおりです。

  • Access-Control-Allow-Origin: このヘッダーは、どのオリジンがリソースにアクセスできるかを指定します。特定のオリジンに設定できます。 https://example.com、 または * すべてのオリジンを許可する（ただし * 資格情報なしでのアクセスは許可されません。
  • Access-Control-Allow-Methods: このヘッダーは、リソースへのアクセス時にどの HTTP メソッドが許可されるかを示すために、プリフライト リクエストへの応答として使用されます。
  • Access-Control-Allow-Headers: プリフライト リクエストへの応答として、このヘッダーは実際のリクエストで使用できるヘッダーを指定します。
  • Access-Control-Expose-Headers: このヘッダーにより、サーバーはブラウザがアクセスを許可されるヘッダーをホワイトリストに登録できます。
  • Access-Control-Allow-Credentials: このヘッダーは、資格情報フラグがtrueの場合にリクエストへの応答を公開できるかどうかを示します。 true リクエストに Cookie または認証の詳細が含まれる場合。
  • Access-Control-Max-Age: このヘッダーは、プリフライト リクエストの結果をキャッシュできる期間を示します。

CORS ヘッダーを理解して適切に実装することは、必要なクロスオリジン リクエストを許可しながら Web アプリケーションを保護するために不可欠です。これらのヘッダーを設定することで、開発者はどのクロスオリジン リクエストを許可するかを微調整し、信頼できるソースのみが Web リソースにアクセスできるようにすることができます。

CORSの実装

クロスオリジン リソース共有 (CORS) の実装は、異なるオリジンのリソースとやり取りする最新の Web アプリケーションにとって不可欠です。このセクションでは、アプリケーションで CORS を有効にする方法、一般的な CORS エラーをデバッグする方法、および Web 開発者向けのベスト プラクティスについて説明します。

アプリケーションで CORS を有効にする: ステップバイステップ ガイド

CORS を有効にするには、リクエストに応じて適切な CORS ヘッダーを送信するようにサーバーを構成する必要があります。プロセスは、使用しているサーバー テクノロジ (Apache、Nginx、Node.js など) によって異なります。異なるサーバー環境で CORS を有効にする方法は次のとおりです。

  • アパッチ: Apacheサーバーの場合、次のディレクティブを .htaccess ファイルまたはサーバー構成ファイル:
<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
    Header set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
    Header set Access-Control-Allow-Headers "Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"
</IfModule>

この設定では、すべてのオリジン（*）を使用して、指定されたメソッドとヘッダーを使用してリクエストを送信します。 Access-Control-Allow-Origin 信頼できるオリジンへのアクセスを制限する値。

  • エンギンクス: Nginx では、サーバー ブロックに以下を追加することで CORS を有効にできます。
location / {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With';
        add_header 'Content-Length' '0';
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        return 204;
    }
    add_header 'Access-Control-Allow-Origin' '*';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With';
}
  • Node.js (エクスプレス): Expressを使用するNode.jsアプリケーションでは、CORSは cors ミドルウェア:
const express = require('express');
const cors = require('cors');

const app = express();

app.use(cors({
    origin: '*', // Adjust this to your specific origin
    methods: ['GET', 'POST', 'OPTIONS', 'DELETE', 'PUT'],
    allowedHeaders: ['Content-Type', 'Access-Control-Allow-Headers', 'Authorization', 'X-Requested-With'],
}));

app.get('/data', (req, res) => {
    res.json({ message: 'This is CORS-enabled for all origins!' });
});

app.listen(3000, () => {
    console.log('Server running on port 3000');
});

一般的な CORS エラーのデバッグ: ヒントとコツ

CORSエラーは通常、ブラウザがサーバーのCORSポリシーによりリクエストをブロックしたときに発生します。一般的なエラーには、 Access-Control-Allow-Origin ヘッダーまたはメソッドが許可されていません。これらのエラーをデバッグするには:

  1. ブラウザ開発ツールを使用する: 最新のブラウザでは、コンソールに詳細なエラー メッセージが表示されます。これらのメッセージには、不足している内容や誤って構成されている内容が示されることがよくあります。
  2. サーバー構成を確認する: 必要な CORS ヘッダーを送信するようにサーバーが正しく構成されていることを確認します。ヘッダーが欠落していたり、値が正しくなかったりすることがよくある問題です。
  3. ツールを使ったテスト: Postman や cURL などのツールは、さまざまなオリジンからのリクエストをシミュレートし、サーバーが正しい CORS ヘッダーで応答するかどうかを識別するのに役立ちます。
  4. CORS ポリシーを確認する: サーバーのCORSポリシーがWebアプリケーションの要件と一致していることを確認します。たとえば、アプリケーションが資格情報（Cookie、HTTP認証）を送信する必要がある場合は、 Access-Control-Allow-Credentials に設定されています true そして Access-Control-Allow-Origin 設定されていません *.

Web 開発者向けの CORS 構成のベスト プラクティス

CORS を安全かつ効率的に実装するには、ベスト プラクティスを遵守する必要があります。

  • 正確な起源を指定する: 代わりに * のために Access-Control-Allow-Originでは、リソースへのアクセスを許可するオリジンを正確に指定します。これにより、不要なクロスオリジン リクエストへの露出が制限されます。
  • 資格情報は慎重に使用してください: アプリケーションが認証情報を使用する場合は、 Access-Control-Allow-Credentials に設定されています true、正確な起源を指定してください *資格情報には、Cookie、HTTP 認証、クライアント側 SSL 証明書が含まれることに注意してください。
  • 公開ヘッダーを制限する: 必要なヘッダーのみを公開する Access-Control-Expose-Headersヘッダーを多すぎる数公開すると、機密情報が誤って漏洩する可能性があります。
  • プリフライトキャッシュ期間の検証： 使用 Access-Control-Max-Age プリフライト応答をキャッシュして、プリフライト要求の数を減らします。ただし、期間が CORS ポリシーの変更頻度と一致することを確認してください。
  • 動的 CORS ポリシーを実装する: より複雑なアプリケーションの場合は、動的CORSポリシーを実装して、 Access-Control-Allow-Origin リクエストの発信元に基づきます。これはサーバー上でプログラム的に実行できます。
  • CORSポリシーを定期的に確認する: Web アプリケーションが進化するにつれて、CORS ポリシーを定期的に確認して更新し、セキュリティと機能の要件を満たしていることを確認します。

これらのガイドラインに従い、CORS を構成およびデバッグする方法を理解することで、開発者は Web アプリケーションがオリジン間で安全かつ効果的に通信できることを保証できます。

CORS の実践

クロスオリジン リソース共有 (CORS) を実装することは、機能を有効にするだけではありません。最新の Web アプリケーションのコンテキスト内でそれがどのように機能するかを理解することです。このセクションでは、CORS の実際の例、CORS ポリシーの管理、および効果的な実装のためのツールとテクニックについて説明します。

CORS の実際の例: 理論から実践へ

CORS は、異なるオリジン間でリソースを安全に要求できるようにする Web 開発の基本的な部分です。CORS が重要な役割を果たす実際のシナリオをいくつか示します。

  • シングルページアプリケーション (SPA) での API の使用: SPAは異なるドメインでホストされているAPIを利用することが多い。例えば、Reactアプリケーションは https://myapp.com ユーザーデータを取得する必要があるかもしれない https://api.userdata.comCORSがなければ、このクロスオリジンリクエストはブラウザによってブロックされます。適切なCORSヘッダーを設定することで（Access-Control-Allow-Origin: https://myapp.com) を API サーバーにデプロイすることで、SPA は必要なデータを安全に要求できます。
// Example fetch request in an SPA
fetch("https://api.userdata.com/user", {
  method: "GET",
  headers: {
    "Content-Type": "application/json",
  },
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error fetching user data:', error));
  • コンテンツ配信ネットワーク (CDN): CDNは、世界中のさまざまな場所から静的アセット（画像、スクリプト、スタイルシート）を提供します。 https://example.com 画像をリクエストする https://cdn.example.comCORS は、静的アセットに対するこれらのクロスオリジン リクエストが安全に処理されることを保証します。
  • サードパーティのウィジェットと統合: Web サイトには、外部サーバーのリソースにアクセスする必要があるサードパーティのウィジェット (チャットボット、ソーシャル メディア フィードなど) が統合されていることがよくあります。CORS を使用すると、これらのウィジェットをさまざまなオリジン間でシームレスに機能させることができ、セキュリティを損なうことなくユーザー エクスペリエンスを向上できます。

CORS ポリシーの管理: 効果的な実装のためのツールとテクニック

CORS ポリシーを効果的に管理するには、利用可能なツールとテクニックを理解する必要があります。

  • サーバー構成: CORS ポリシーを管理する最初のステップは、Web サーバーを構成することです。これには、アプリケーションのニーズに基づいて必要な CORS ヘッダーを設定することが含まれます。ほとんどの Web サーバー (Apache、Nginx、IIS) では、構成ファイルまたは .htaccess (Apache の場合) を通じてこれらのヘッダーを指定できます。
  • Webフレームワーク向けミドルウェア: ウェブフレームワーク（Node.jsの場合はExpress.js、Pythonの場合はDjango）を使用している場合、CORSポリシー管理を簡素化するミドルウェアパッケージが多数提供されています。たとえば、 cors Express のパッケージを使用すると、アプリケーション コード内で CORS ポリシーを直接定義できます。
// Example using the cors middleware in an Express.js application
const cors = require('cors');
const express = require('express');
const app = express();

// Define CORS options
const corsOptions = {
  origin: 'https://example.com',
  optionsSuccessStatus: 200,
};

app.use(cors(corsOptions));

app.get('/data', (req, res) => {
  res.json({ message: 'CORS-enabled route' });
});

app.listen(3000, () => console.log('Server running on port 3000'));
  • 動的 CORS 処理: 複数の信頼できるオリジンからのリクエストを許可する必要のあるアプリケーションでは、動的なCORS処理を実装することができます。これには、プログラムで Access-Control-Allow-Origin 受信リクエストの送信元に基づいてヘッダーを作成します。
// Example of dynamic CORS handling
app.use((req, res, next) => {
  const allowedOrigins = ['https://example.com', 'https://api.example.com'];
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }
  next();
});

CORS ポリシーのテストとデバッグのためのツール

  • ブラウザ開発者ツール: ブラウザ開発者ツールのネットワーク タブは、CORS エラーを検査し、CORS ヘッダーがリアルタイムでどのように送受信されているかを理解するのに非常に役立ちます。
  • オンラインツール: ツール CORS テスター そして 郵便配達員 さまざまなオリジンからサーバーにリクエストを送信し、応答を検査することで、CORS ポリシーをテストできます。
  • コマンドラインツール: curl は、コマンドラインから CORS ポリシーをテストするための強力なツールです。さまざまなオリジンからのリクエストをシミュレートし、サーバーの応答内の CORS ヘッダーを検査するために使用できます。
# Example curl command to test CORS
curl -H "Origin: https://example.com" \
     -I https://api.example.com/data

開発者は、これらの実際のアプリケーションと管理戦略を理解することで、CORS を最大限に活用し、Web アプリケーションがオリジン全体のリソースと安全にやり取りできることを保証できます。

SPA でクロスオリジン API リクエストを有効にする場合でも、CDN を通じてアセットを提供する場合でも、サードパーティのウィジェットを統合する場合でも、CORS は、適切に管理されていればセキュリティと機能性の両方を提供する、最新の Web エコシステムの重要な部分です。

CORS のセキュリティへの影響

クロスオリジン リソース共有 (CORS) の実装は、Web アプリケーションのセキュリティに重大な影響を及ぼします。CORS により、Web アプリケーションは異なるオリジンからリソースを要求できるようになりますが、適切に構成されていない場合は潜在的な脆弱性も生じます。

このセクションでは、CORS のセキュリティ面について詳しく説明し、クロスサイト スクリプティング (XSS) 攻撃の軽減と厳格な CORS ポリシーの重要性に焦点を当てます。

CORS と Web セキュリティ: クロスサイト スクリプティング (XSS) 攻撃の軽減

クロスサイト スクリプティング (XSS) 攻撃により、攻撃者は、安全で信頼できる Web サイトのコンテンツに悪意のあるスクリプトを挿入できるようになります。

これらの攻撃は、アプリケーションが適切な検証やエスケープを行わずに信頼できないデータを Web ページに含め、攻撃者が被害者のブラウザ コンテキストでスクリプトを実行できるようにした場合に発生します。CORS は、Web アプリケーションと対話できるオリジンを制御することで、XSS 攻撃を軽減する上で非常に重要です。

アプリケーションが、悪意のあるスクリプトを含む可能性のあるユーザー生成コンテンツを許可するシナリオを考えてみましょう。

適切なコンテンツ サニタイズと厳格な CORS ポリシーがなければ、このアプリケーションは XSS 攻撃のベクトルになる可能性があります。CORS は XSS を直接防止するものではありませんが、指定されたオリジンのみがアプリケーションにリクエストを送信できるようにすることで、より広範なセキュリティ戦略に貢献し、攻撃対象領域を減らします。

例えば、あなたのアプリケーションが https://safe-app.com ホストされているAPIを使用します https://api.safe-app.com設定することで Access-Control-Allow-Origin ヘッダー https://safe-app.comを使用すると、アプリケーションから発信されたリクエストのみが API にアクセスできるようになります。この制限により、API とのやり取りを信頼できる発信元に制限することで、潜在的な XSS 攻撃を軽減できます。

Access-Control-Allow-Origin: https://safe-app.com

ただし、XSS やその他の種類の攻撃を効果的に軽減するには、CORS ポリシーを、ユーザー入力の検証やサニタイズなどの他のセキュリティ対策と組み合わせることが重要です。

厳格な CORS ポリシーの重要性: Web アプリケーションの保護

厳格なCORSポリシーを実装することは、さまざまなセキュリティ脅威からWebアプリケーションを保護するために不可欠です。 Access-Control-Allow-Origin に *は、あらゆるオリジンがサーバーにリクエストを送信できるようにすることで、アプリケーションがデータ盗難、CSRF 攻撃、その他の脆弱性にさらされる可能性があります。

厳格な CORS ポリシーでは、許可されるオリジン、メソッド、ヘッダーを指定します。この詳細さにより、信頼できる Web アプリケーションのみがリソースと対話できるようになり、機密データとアプリケーションの整合性を保護するセキュリティ レイヤーが提供されます。

たとえば、特定のドメインからのアクセスを許可し、資格情報 (Cookie、HTTP 認証) を使用するアプリケーションを考えてみましょう。

Access-Control-Allow-Origin: https://trusted-domain.com
Access-Control-Allow-Credentials: true

この構成により、 https://trusted-domain.com アプリケーションへの資格情報を使用したリクエストは許可されますが、他のオリジンからのリクエストは拒否されます。この制限は、機密情報を処理したり、ユーザーに代わってアクションを実行したりするアプリケーションにとって非常に重要です。

さらに、許可されたメソッドとヘッダーを指定すると、セキュリティがさらに強化されます。

Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, X-Custom-Header

この設定により、指定されたヘッダーを持つ GET および POST リクエストのみが受け入れられるようになり、不正なリクエストや悪意のあるリクエストのリスクが軽減されます。

安全な CORS 実装のベスト プラクティス

  1. 許可されたオリジンを指定する: ワイルドカードを使用するのではなく、常に特定のオリジンを定義します *この方法により、信頼できるドメインのみがアプリケーションにリクエストを送信できるようになります。
  2. 資格情報によるアクセス制限: 資格情報を許可する際には注意してください。 Access-Control-Allow-Credentials に設定されています true 必要な場合にのみ使用され、起源が明示的に定義されます。
  3. 許可されるメソッドとヘッダーを定義する: 許可するメソッドとヘッダーを指定します。この制限により、セキュリティが強化されるだけでなく、API を操作する開発者に明確なドキュメントが提供されます。
  4. プリフライトリクエストを使用する: プリフライト リクエストを利用して、クロスオリジン リクエストを受け入れる前に検証します。プリフライト リクエストは検証の層を追加し、実際のリクエストが CORS ポリシーに準拠していることを確認します。
  5. CORSポリシーを定期的に確認する: アプリケーションが進化するにつれて、アプリケーションのアーキテクチャとドメインの相互作用の変更を反映するために、CORS ポリシーを定期的に確認して更新します。
  6. CORSを他のセキュリティ対策と組み合わせる: CORS は包括的なセキュリティ戦略の一部である必要があります。CORS ポリシーをコンテンツ セキュリティ ポリシー (CSP)、入力検証、出力エンコード、およびその他のセキュリティのベスト プラクティスと組み合わせて、XSS やその他の Web の脆弱性から保護します。

CORS のセキュリティ上の影響を理解し、厳格な CORS ポリシーを実装することで、開発者は、最新の Web アプリケーションに必要なクロスオリジンのインタラクションを可能にしながら、クロスオリジン攻撃から Web アプリケーションを保護することができます。

高度な CORS トピック

Web アプリケーションの複雑さが増すにつれて、クロスオリジン リソース共有 (CORS) のニュアンスを理解することがますます重要になります。このセクションでは、基本的な構成を超えた CORS と API セキュリティ、一般的な問題のトラブルシューティングなど、高度な CORS トピックについて説明します。

CORS と API セキュリティ: 安全なクロスオリジン リクエストの確保

API は現代の Web アプリケーションのバックボーンであり、さまざまなサービス間でのデータ交換と機能を促進します。CORS は、承認されたオリジンのみが API にアクセスできるようにすることで、API セキュリティにおいて重要な役割を果たします。CORS が API セキュリティを強化する仕組みは次のとおりです。

  • トークンベースの認証多くのAPIは、アクセスを保護するためにトークンベースの認証（OAuth 2.0、JWTなど）を使用します。CORSポリシーは、次のようなトークンヘッダーを許可するように慎重に構成する必要があります。 Authorization、信頼できるオリジンからのものです。例えば、 Authorization クロスオリジンリクエストのヘッダーに、サーバー側で明示的にリストする必要があります。 Access-Control-Allow-Headers.
Access-Control-Allow-Headers: Authorization
  • サードパーティAPIの利用: Web アプリケーションがサードパーティ API を使用する場合、これらの API の CORS ポリシーを理解することが重要です。サードパーティ API に制限的な CORS ポリシーがある場合は、ドメインでサーバー側プロキシを使用して API へのリクエストを中継し、CORS 制限を回避する必要がある場合があります。
  • カスタムヘッダーの公開: APIがアプリケーション固有の情報にカスタムヘッダーを使用する場合、これらのヘッダーは、 Access-Control-Expose-Headersこれにより、クライアント側アプリケーションはこれらのヘッダーの値を読み取ることができます。
Access-Control-Expose-Headers: X-My-Custom-Header

基本的な CORS を超えて: 高度な構成とトラブルシューティング

高度な CORS 構成により、より複雑なシナリオに対応できます。

  • 動的オリジン検証: 動的なオリジンセットからのリクエストを許可する必要のあるアプリケーション（各テナントが独自のドメインを持つマルチテナントアプリケーションなど）では、動的なオリジン検証を実装する必要があります。これには、プログラムで次のチェックが含まれます。 Origin ヘッダーを許可されたオリジンのリストと比較し、 Access-Control-Allow-Origin それに応じてヘッダーを作成します。
const allowedOrigins = ['https://tenant1.example.com', 'https://tenant2.example.com'];
const origin = request.headers.origin;
if (allowedOrigins.includes(origin)) {
    response.setHeader('Access-Control-Allow-Origin', origin);
}
  • WebSocket の CORS: WebSocket は HTTP リクエストと同じように CORS の対象ではありませんが、WebSocket 接続のセキュリティ保護は非常に重要です。最初の WebSocket ハンドシェイク リクエスト (HTTP リクエスト) に適切な CORS 検証が含まれていることを確認することをお勧めします。
  • プリフライトキャッシュの最適化: の Access-Control-Max-Age ヘッダーを使用して、プリフライト リクエストの結果をキャッシュできる期間を指定できます。CORS ポリシーの変更頻度に基づいてこの値を最適化すると、プリフライト リクエストの数が減り、アプリケーションのパフォーマンスが向上します。
Access-Control-Max-Age: 86400

一般的な CORS の問題のトラブルシューティング

CORS を適切に設定しても、問題が発生する可能性があります。一般的な CORS の問題をトラブルシューティングするための戦略は次のとおりです。

  • CORS ヘッダーが欠落しているか正しくない: サーバーが期待されるCORSヘッダーを送信するように正しく設定されていることを確認してください。 curl ヘッダーを手動で検査するために使用できます:
curl -I -H "Origin: https://example.com" https://api.example.com/resource
  • JavaScript Fetch API の不透明なレスポンス: Fetch APIでリクエストを行う際、不透明なレスポンス（no-corsリクエストからのレスポンス）は、レスポンスに関してアクセスできる情報の種類を制限するため、問題を引き起こす可能性があります。 mode: 'no-cors' 絶対に必要な場合を除き、Fetch API リクエストでは使用しないでください。
  • 資格情報に関する CORS エラー: リクエストに認証情報（クッキー、HTTP認証）が含まれる場合は、 Access-Control-Allow-Credentials に設定されています true、そして Access-Control-Allow-Origin ワイルドカードではない（*).
  • プリフライトリクエストのデバッグ: プリフライトリクエストが失敗する場合は、サーバーが処理しているかどうかを確認してください。 OPTIONS リクエストが正しく処理され、適切な CORS ヘッダーで応答することを確認します (Access-Control-Allow-Methods, Access-Control-Allow-Headers).

これらの高度な CORS トピックを詳しく調べることで、開発者はクロスオリジン リソース共有のために Web アプリケーションを保護および最適化する方法をより深く理解できます。API セキュリティ、複雑な CORS 構成、または困難な CORS 問題のトラブルシューティングのいずれを扱う場合でも、CORS を深く理解することは、現代の Web 開発に不可欠です。

結論

CORS を理解することは、安全な Web インタラクションにとって不可欠です。CORS を正しく実装すると、アプリケーションが侵害から保護され、厳格なポリシーによって XSS 攻撃から保護され、高度なトピックを調査することで Web 開発が最適化されます。

関連記事