CORSコンフィグジェネレーター

クロスオリジンリソース共有(CORS)設定を素早く作成、様々なサーバー環境をサポート

ネットワークプロトコルネットワークCORS生成

CORSコンフィグジェネレーター

クロスオリジンリソース共有(CORS)設定を素早く作成、様々なサーバー環境をサポート

秒 (0-86400)

Node.js/Express 設定

const corsOptions = {
  origin: ["https://example.com"],
  methods: ['GET', 'POST', 'PUT', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Accept', 'Origin'],
  maxAge: 3600,
  preflightContinue: false,
  optionsSuccessStatus: 204
}

// Expressアプリケーションでミドルウェアを使用
const express = require('express')
const cors = require('cors')
const app = express()

// CORSミドルウェアを適用
app.use(cors(corsOptions))

// または特定のルートにのみ適用
app.get('/api/resource', cors(corsOptions), (req, res) => {
  // リクエストを処理
})

CORSヒント

クロスオリジンリソース共有（CORS）は、HTTPヘッダーに基づくメカニズムで、サーバーが自身以外のオリジン（ドメイン、プロトコル、ポート）からリソースをロードすることをブラウザに許可するための仕組みです。

CORS保護は現代のブラウザのセキュリティ機能で、ウェブページが異なるオリジンのサーバーにリクエストを送信することを防ぎ、クロスサイトリクエストフォージェリ攻撃からユーザーを保護します。

CORSの使用シナリオ:

  • フロントエンドJavaScriptが異なるドメインのAPIにアクセスできるようにする
  • クロスドメインのAjaxリクエストまたはFetchリクエストをサポート
  • フォント、CSS、その他のリソースへのクロスドメインアクセスを許可
  • マイクロサービスアーキテクチャ内のサービス間通信を設定

セキュリティヒント: 通常、許可されるオリジンとして「*」ワイルドカードを使用することは避け、信頼できる特定のドメインを明示的に指定して、潜在的なセキュリティリスクを減らすべきです。

CORS設定ジェネレーター完全ガイド - 安全なクロスオリジンリソース共有設定

CORS設定とウェブセキュリティにおけるその重要な役割を理解する

クロスオリジンリソース共有（CORS）は、現代のブラウザが実装する基本的なセキュリティメカニズムで、あるドメイン上のウェブページが別のドメインでホストされているリソースをどのようにリクエストし、やり取りするかを制御します。当社のCORS設定ジェネレーターツールは、適切なCORSヘッダーとサーバー設定を作成する複雑なプロセスを簡素化し、Webアプリケーションが適切なセキュリティ境界を維持しながら、ドメイン間で安全に通信できるようにします。このツールは、アクセス制御を適切に実装することで、機密データを保護しながら正当なクロスオリジン機能を有効にするよう、開発者が正確にカスタマイズされたCORS設定を生成するのに役立ちます。
適切なCORS設定は、現代のWebアプリケーションにとって不可欠です。特に分散アーキテクチャ、サードパーティAPI、マイクロサービスを活用するアプリケーションにおいて重要です。適切なCORS設定がなければ、ブラウザはセキュリティ対策としてクロスオリジンリクエストをデフォルトでブロックし、多くの一般的なWebアプリケーションアーキテクチャが機能しなくなります。当社のジェネレーターは、Node.js/Express、Apache、Nginxなどの様々なサーバー環境向けに標準化された設定を作成し、開発者がバックエンドの技術スタックに関係なく、一貫したCORSポリシーを実装できるようにします。これにより開発ワークフローが簡素化され、アプリケーションをクロスサイトリクエストフォージェリ（CSRF）やデータ窃盗の脆弱性にさらす可能性のあるセキュリティ設定ミスのリスクが軽減されます。
CORSポリシーの生成には、許可されるオリジン、HTTPメソッド、ヘッダー、認証情報の処理、キャッシュ指示など、さまざまなセキュリティパラメータを慎重に検討する必要があります。手動設定は間違いやすく、機能を損なうほど制限的すぎるポリシーや、セキュリティを損なうほど緩すぎる設定になる可能性があります。当社のツールは、明確な説明と安全なデフォルト値で各設定オプションをガイドし、開発者がCORS実装について情報に基づいた決定を下せるよう支援します。生成された設定は、セキュリティ要件とクロスオリジン機能のニーズのバランスを取り、現代のWebアプリケーションで作業するフロントエンド開発者、APIアーキテクト、セキュリティエンジニアに即座に価値を提供します。

CORS設定ジェネレーターの実践的応用

APIゲートウェイとマイクロサービスアーキテクチャ：APIゲートウェイとマイクロサービスを使用して分散システムを開発する組織は、フロントエンドアプリケーションとバックエンドサービス間の安全な通信を確保するために、正確なCORS設定が頻繁に必要です。APIアーキテクトは、当社のCORSジェネレーターを使用して、複数のサービスエンドポイントで一貫して実装できる標準化されたヘッダー設定を開発します。このアプローチにより、マイクロサービスは適切に分離されたままで、認可されたクライアントアプリケーションからの正当なクロスオリジンリクエストを許可できます。例えば、フィンテック企業は、支払い処理APIが特定のフロントエンドドメインからのリクエストのみを受け入れ、他のすべてのクロスオリジンリクエストをブロックするように設定する場合があります。当社のジェネレーターは、開発者が各サービスに手動で複雑なヘッダールールを書く必要なく、これらのセキュリティ境界を維持する設定を作成します。
サードパーティAPI統合とSaaSアプリケーション：APIサービスとSaaSプラットフォームを提供する企業は、セキュリティ境界を維持しながら、適切なCORS設定を通じてサードパーティ統合を可能にする必要があります。プラットフォームエンジニアは当社のジェネレーターを使用して、パートナードメインとサブスクリプションステータスに基づいてクロスオリジンアクセスを選択的に許可する設定を作成します。例えば、マーケティング分析プラットフォームは、顧客ドメインからのリクエストを受け入れ、未認証のアクセスを防止するようにデータAPIを設定する場合があります。ジェネレーターは、顧客関係の進化に応じて動的に調整できる、正確に範囲を絞ったCORSポリシーの作成を支援します。これにより、API アクセスが安全かつビジネスに一貫したものであることが保証されます。この機能は、APIプロバイダーが統合のオープン性とセキュリティ要件のバランスを取る必要があるパートナーエコシステムのシナリオで特に価値があります。
安全なコンテンツ配信ネットワーク（CDN）とアセットホスティング：専用CDNで静的アセット（フォント、スタイルシート、画像、JavaScriptライブラリなど）をホストする組織は、これらのリソースをWebアプリケーションからアクセス可能にするために適切なCORS設定が必要です。DevOpsエンジニアは当社のジェネレーターを使用して、特定のアプリケーションがCDNホストリソースにアクセスできるようにし、他のドメインによる不正使用を防止する設定を作成します。例えば、プレミアムフォントをホストする出版会社は、自社のウェブサイトのみがこれらのアセットを使用できるようにCORSヘッダーを設定します。ジェネレーターは、CDN環境とエッジサーバーに特化した設定を作成し、適切なキャッシュ指示とアクセス制御を設定することで、セキュリティとパフォーマンスを最適化します。これにより、静的リソースが保護されたまま、認証されたアプリケーションに効率的に配信されることが保証されます。
開発およびテスト環境：複数の環境（開発、ステージング、本番）を使用するソフトウェア開発チームは、開発ライフサイクルの異なるセキュリティ要件に対応するために柔軟なCORS設定が必要です。フロントエンド開発者は当社のジェネレーターを使用して、開発とテスト中はクロスオリジンアクセスを許可し、本番環境ではより厳格な制御を実装する環境固有の設定を作成します。例えば、開発環境ではローカルテスト用にlocalhostオリジンを許可し、本番環境では検証済みの本番ドメインへのアクセスのみを制限する場合があります。ジェネレーターは、大量の手動再設定なしでこれらの段階的なセキュリティポリシーを作成するのに役立ち、開発ワークフローを簡素化しながら、各段階で適切なセキュリティ境界を維持します。このアプローチにより、開発プロセス中のセキュリティショートカットが本番環境に持ち込まれることを防止します。
マルチリージョンおよび国際Webアプリケーション：複数の地理的リージョンで運用するグローバル組織は、特定の地域にサービスを提供するドメインとサブドメインにデプロイすることが多く、それらが安全に相互通信する必要があります。システムアーキテクトは当社のジェネレーターを使用して、組織の異なるリージョンドメイン間のクロスオリジンリクエストを許可し、外部リクエストをブロックするCORS設定を作成します。例えば、多国籍企業はapi.us.example.comがapp.eu.example.comからのリクエストを受け入れる必要がある場合があります。ジェネレーターは、これらの複雑なドメイン関係を考慮した正確なオリジン仕様を作成し、外部ドメインに対するセキュリティ境界を維持します。これらの設定により、同じアプリケーションの地理的に分散したコンポーネントが調和して動作し、未認証のソースからのクロスオリジン脅威に対する保護を維持できます。

安全なCORS設定を生成する方法

特定のニーズに合わせてカスタマイズされた安全なCORS設定を作成するには、このステップバイステップガイドに従ってください：

ステップ1：許可するオリジンを設定する

許可するオリジンセクションで、どのドメインがリソースにアクセスできるかを指定することから始めます。最大限のセキュリティのため、ワイルドカード（*）オプションは避けてください。これはどのドメインからもリソースへのアクセスを許可します。代わりに、「特定のドメインを許可」オプションを選択し、信頼できる各ドメインを個別に追加します。例えば、「https://yourtrustedapp.com」と入力すると、そのドメインのみが許可されます。プロトコル（https://）を含めることを忘れないでください。また、サブドメインは異なるオリジンとして扱われることに注意してください（app.example.comとapi.example.comは異なるオリジン）。開発環境をサポートする必要がある場合は、本番ドメインの横に開発ドメイン（「http://localhost:3000」など）を追加できます。信頼できるドメインをすべて追加したら、スペルミスがないか慎重に確認してください。わずかなミスでも、ブラウザが正当なリクエストをブロックする原因となります。

ステップ2：許可するHTTPメソッドを指定する

許可するHTTPメソッドセクションで、APIまたはリソースがクロスオリジンリクエストから受け入れるべきHTTPメソッドを選択します。最小権限の原則に従い、アプリケーションが実際に必要とするメソッドのみを有効にしてください。読み取り専用リソースの場合は、GETとOPTIONS（プリフライトリクエストに必要）のみに制限することを検討してください。更新を受け入れるリソースの場合は、APIの実際のニーズに基づいて、POST、PUT、PATCH、またはDELETEを選択的に有効にします。データを変更するメソッド（POST、PUT、PATCH、DELETE）を有効にする際は特に注意が必要です。これらには追加のセキュリティ考慮事項が必要です。OPTIONSメソッドは通常有効にしておく必要があります。ブラウザはこれを使用してプリフライトリクエストを行い、他のメソッドを使用して実際のクロスオリジンリクエストを行う前に権限を確認します。ここでの選択は、クロスオリジンクライアントがリソースに対して実行できる操作に直接影響します。

ステップ3：ヘッダーと認証情報を設定する

許可するヘッダーセクションで、クロスオリジンリクエストで許可すべきHTTPリクエストヘッダーを指定します。アプリケーションが必要とする一般的なヘッダーを有効にします。例えば、リクエスト形式を指定するための'Content-Type'、認証トークンのための'Authorization'、アプリケーションが必要とするカスタムヘッダーなどです。認証情報ベースの認証（Cookie、HTTP認証、またはクライアント証明書）の場合は、認証情報を許可オプションを適切に設定します。重要：認証情報を許可する場合、許可されるオリジンにワイルドカード（*）を使用することはできません - 明示的なオリジンを指定する必要があります。次に、プリフライトリクエストの数を減らすために適切なプリフライトキャッシュ時間を設定します。推奨値の3600秒（1時間）は、パフォーマンスと必要に応じてCORSポリシーを更新する柔軟性のバランスを取ります。最後に、APIがクライアントアプリケーションがアクセスする必要があるカスタムヘッダーを返す場合は、これらを公開するヘッダーセクションに追加します。

ステップ4：サーバー設定を生成して実装する

すべてのCORSパラメータを設定したら、フォーマットオプションからターゲットサーバー環境（Node.js/Express、Apache、Nginx、またはHTTPヘッダー）を選択します。生成された設定コードを確認し、要件を満たしていることを確認します。「コピー」ボタンを使用して設定をコピーし、プラットフォームのドキュメントに従ってサーバー環境に実装します。Node.jsアプリケーションの場合は、'cors'パッケージをインストールし、設定をExpressアプリケーションに適用します。Apacheサーバーの場合は、生成された指示を.htaccessファイルまたはサーバー設定に追加します。Nginxの場合は、サーバーまたはロケーションブロックに指示を含めます。実装後、クロスオリジンリクエストを通じてCORS設定を徹底的にテストし、正当なリクエストが許可され、未認証のオリジンがブロックされていることを確認します。ブラウザの開発者ツールを使用してサーバーが返すCORSヘッダーを検査し、問題をデバッグすることを検討してください。

CORS実装の技術的詳細

CORSの基礎となるメカニズムを理解することで、より効果的で安全な設定を作成するのに役立ちます：

プリフライトリクエストとその役割

プリフライトリクエストはCORSプロトコルの重要なセキュリティメカニズムで、ブラウザはこれを使用して、特定のクロスオリジンリクエストを実際に送信する前に、それらを実行する権限があるかどうかを確認します。リクエストがサーバーデータを変更する可能性がある場合（POSTやPUTリクエストなど）や、非シンプルヘッダーを使用する場合、ブラウザはまず自動的にサーバーにOPTIONSリクエストを送信します。このプリフライトリクエストには、実際のリクエストが使用しようとしているHTTPメソッドとヘッダーを示すヘッダーが含まれます。サーバーは適切なAccess-Control-Allow-*ヘッダーで応答し、予期されるリクエストが許可されるかどうかを示す必要があります。このプリフライトメカニズムは重要なセキュリティチェックポイントを提供し、明示的に受け入れを選択していないサーバーに潜在的に危険なクロスオリジンリクエストが送信されるのを防ぎます。当社のCORS設定ジェネレーターは、サポートされているすべてのサーバープラットフォーム向けに、これらのプリフライトリクエストを処理するために必要なサーバーサイド処理を自動的に作成し、サーバーが指定した権限で正確にこれらのブラウザセキュリティチェックに応答することを保証します。

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

CORS設定はWebアプリケーションのセキュリティ状態に直接影響し、どの外部ドメインがAPIエンドポイントやリソースと対話できるかを制御します。寛容すぎるCORS設定—特にワイルドカードオリジン（*）の使用—は、アプリケーションをクロスサイトリクエストフォージェリ攻撃に対して脆弱にする可能性があり、悪意のあるサイトがユーザーの認証セッションを使用してAPIに未認証のリクエストを行うことができます。Access-Control-Allow-Credentials: trueヘッダーを使用する場合、ワイルドカードオリジンではなく正確な許可オリジンを指定することが特に重要です。認証情報を使用したワイルドカードオリジンを許可すると、深刻なセキュリティ脆弱性が生じるためです。最小権限の原則がCORS設定を導くべきです：アプリケーションが正当に必要とする特定のオリジン、メソッド、ヘッダーのみを許可します。当社のジェネレーターは、潜在的に安全でない設定に関する明確な警告を提供し、リソースを保護しながら必要なクロスオリジン機能を有効にする安全なデフォルト値を提供することで、セキュリティのベストプラクティスを促進します。このアプローチは、データの露出や未認証の操作につながる可能性のある一般的なセキュリティ設定ミスを防ぐのに役立ちます。

基本的なCORSヘッダーの説明

各CORSヘッダーは、リソースへのクロスオリジンアクセスを制御する上で特定のセキュリティ機能を持っています。Access-Control-Allow-Originはどのドメインがリソースにアクセスできるかを指定し、最も基本的なCORSヘッダーです—ブラウザはこのオリジンマッチングを厳格に実施します。Access-Control-Allow-Methodsは、外部ドメインがリソースをリクエストする際に使用できるHTTPメソッドを宣言し、必要に応じてクロスオリジンリクエストを読み取り専用操作に制限できます。Access-Control-Allow-Headersは、クロスオリジンリクエストに含めることができるHTTPヘッダーを制御し、Authorizationなどの特定のヘッダーを許可しながら他のヘッダーをブロックすることができます。Access-Control-Allow-Credentialsは、ブラウザがクロスオリジンリクエストでCookieや認証情報を送信できるかどうかを決定し、クロスオリジンの認証セッションを維持するために重要です。Access-Control-Max-Ageは、ブラウザがプリフライト応答をキャッシュすべき時間を指定し、プリフライトリクエストを減らすことでパフォーマンスを最適化します。Access-Control-Expose-Headersは、特定のレスポンスヘッダーをクロスオリジンクライアントに見えるようにし、クライアントがAPIレスポンスのカスタムヘッダーにアクセスする必要がある場合に必要です。当社のジェネレーターは、特定のニーズに基づいてこれらのヘッダーの適切な組み合わせを作成し、完全で一貫性のあるCORS設定を保証します。

CORS設定に関するよくある質問

CORSと従来の同一オリジンポリシーの違いは何ですか？

同一オリジンポリシー（SOP）とクロスオリジンリソース共有（CORS）は、異なる目的を果たしながら、安全なウェブブラウジング環境を作り出します。同一オリジンポリシーはブラウザのデフォルトのセキュリティメカニズムで、あるオリジンのドキュメントやスクリプトが別のオリジンのリソースとどのように対話できるかを制限します。これは制限的なベースラインで、デフォルトでクロスオリジンリクエストをブロックします。一方、CORSはこのポリシーの制御された緩和策です—サーバーが同一オリジンポリシーの制限にもかかわらず、どのオリジンがそのリソースにアクセスすることを許可されるべきかを宣言する構造化された方法を提供します。SOPはブラウザによって強制される制限である一方、CORSはHTTPヘッダーを通じて実装され、サーバーがブラウザにどのクロスオリジンリクエストが同一オリジンポリシーの例外として許可されるべきかを伝えます。当社のCORSジェネレーターは、同一オリジンポリシーに対するこれらの制御された例外を有効にするサーバーサイド設定を作成します。適切なCORSヘッダーがなければ、ブラウザはSOPを強制し、サーバーが技術的にそれらを処理できる場合でも、クロスオリジンリクエストをブロックします。これが、CORS設定が異なるドメイン間でリソースを共有する必要がある現代のWebアプリケーションにとって重要である理由です。

認証情報を有効にする際にワイルドカード（*）オリジンを使用できないのはなぜですか？

ブラウザは認証情報とワイルドカードオリジンの組み合わせを厳格に禁止しています。これは深刻な脆弱性を防ぐための重要なセキュリティ対策です。ブラウザがAccess-Control-Allow-Origin: *とAccess-Control-Allow-Credentials: trueの組み合わせを許可した場合、任意のウェブサイトがユーザーの認証情報（Cookie、HTTP認証、またはクライアント証明書）を使用してAPIに認証されたリクエストを行うことができる危険なシナリオが生じます。これは事実上、クロスサイトリクエストフォージェリ（CSRF）攻撃に対する同一オリジンポリシーの保護を排除することになります。例えば、この組み合わせが許可された場合、悪意のあるサイトはユーザーの認証Cookieを使用して銀行APIにリクエストを送信し、資金を移動したり機密情報にアクセスしたりする可能性があります。この脆弱性を防ぐため、すべての主要ブラウザは厳格なルールを強制しています：Access-Control-Allow-Credentialsがtrueに設定されている場合、Access-Control-Allow-Originヘッダーはワイルドカードではなく正確なオリジンを指定しなければなりません。当社のCORSジェネレーターは、ワイルドカードオリジンを選択した場合に認証情報オプションを無効にし、逆もまた同様にすることで、このセキュリティ制約を強制します。これにより、生成された設定が常にこの重要なブラウザセキュリティ要件に準拠することが保証されます。

CORSプリフライトリクエストはAPIのパフォーマンスにどのように影響しますか？

CORSプリフライトリクエストはAPIのパフォーマンスに大きな影響を与える可能性があります。多くのクロスオリジンシナリオでは、実際のデータリクエストの前に追加のHTTPリクエスト（OPTIONS）が追加されるためです。各プリフライトリクエストは遅延を生じさせます。ブラウザは実際のリクエストを続行する前にOPTIONSレスポンスを待つ必要があるためです。これにより、非シンプルなクロスオリジンリクエストのHTTPリクエストとサーバーの往復回数が事実上2倍になります。パフォーマンスへの影響は、頻繁なAPI呼び出しを行うアプリケーションや高遅延接続で特に顕著です。この性能損失を軽減するために、Access-Control-Max-Ageヘッダーが重要です—これはブラウザにプリフライト結果を指定された時間（秒単位）キャッシュするよう指示し、その時間範囲内での同じリソースへの追加のプリフライトリクエストを防ぎます。当社のジェネレーターは、パフォーマンス最適化と必要に応じてCORSポリシーを更新する柔軟性のバランスを取る合理的なデフォルト値として、この値を3600秒（1時間）に設定することを推奨しています。高トラフィックアプリケーションの場合、この値をさらに増やすことを検討するかもしれません（最大86400秒/24時間、ただしブラウザ自体が上限を課す場合があります）。さらに、本番環境での最大のパフォーマンスを得るには、サーバーがOPTIONSリクエストに迅速に応答することを確認し、最小限の処理オーバーヘッドでプリフライトリクエストを処理する特定の最適化ルートの実装を検討してください。

CORS設定が正しく機能しているかどうかを適切にテストするにはどうすればよいですか？

CORS設定のテストには体系的なアプローチが必要です。不正確な設定は診断が難しい曖昧なブラウザエラーメッセージとして現れることが多いためです。最も効果的なテスト戦略には、APIとは異なるドメインでホストされる単純なクロスオリジンテストクライアントの作成が含まれます。これは、APIエンドポイントにさまざまなタイプのリクエストを行うJavaScriptを含む基本的なHTMLページかもしれません。ChromeまたはFirefoxの開発者ツール（ネットワークタブ）を使用して、プリフライトOPTIONSリクエストとそれに続く実際のリクエストを観察します。OPTIONSリクエストが正しいAccess-Control-Allow-*ヘッダーを含む200または204レスポンスを受信することを確認します。さまざまなHTTPメソッド、カスタムヘッダー、認証情報を含むリクエストなど、さまざまなシナリオをテストして、設定がアプリケーションのすべての要件を処理することを確認します。一般的なテストの問題には、localhost:3000とlocalhost:8080がブラウザによって異なるオリジンとして扱われることを忘れたり、プロトコルの違い（httpとhttps）を無視したりすることが含まれます。CORSエラーが表示される場合は、許可されたオリジンがリクエストページのオリジン（プロトコル、ドメイン名、ポートを含む）と完全に一致することを確認し、サーバーが実際にレスポンスでCORSヘッダーを送信していること（設定だけでなく）を確認し、プリフライトリクエストが正しく処理されていることを確認してください。当社のジェネレーターは一般的なサーバー環境の設定を生成しますが、特定のサーバーセットアップに合わせて調整する必要があるかもしれません。

寛容すぎるCORSポリシーにはどのようなセキュリティリスクがありますか？

寛容すぎるCORSポリシーは深刻なセキュリティ脆弱性をもたらす可能性があり、クロスサイト攻撃に対する同一オリジンポリシーの保護を弱めます。最も顕著なリスクは、Access-Control-Allow-Origin: *とAccess-Control-Allow-Credentials: trueの組み合わせを設定することから来ます（ブラウザはこの特定の組み合わせをブロックしますが、誤って設定されたプロキシはそうしないかもしれません）。認証情報がなくても、過度にオープンなCORSポリシーは、機密APIやデータを未認証のウェブサイトに公開する可能性があります。例えば、内部管理APIが任意のオリジンを許可している場合、悪意のあるサイトがそれにリクエストを行い、機密データや操作にアクセスする可能性があります。もう一つの一般的なリスクは、不適切なオリジン検証です—例えば、信頼できるドメインを含む任意のオリジンを承認する単純な文字列マッチング（yourcompany.comだけでなくattacker.com/evil.yourcompany.comも許可する）。さらに、誤って設定されたCORSは、ポリシーが信頼されていないオリジンからの状態変更リクエストを許可する場合、クロスサイトリクエストフォージェリ攻撃を可能にする可能性があります。これらのリスクを軽減するには、最小権限の原則に従い、アプリケーションが正当に必要とする特定のオリジン、メソッド、ヘッダーのみを許可してください。内部APIの場合、ワイルドカードオリジンは決して使用しないでください。セキュリティレビューの一部としてCORS設定を定期的に監査し、機密操作に追加の認証メカニズムの実装を検討してください。当社のジェネレーターは、必要なクロスオリジン機能を有効にしながら、これらのセキュリティのベストプラクティスを奨励する設定を作成します。

関連するWeb開発ツールを探索

これらの補完的なツールでWeb開発ワークフローを強化：

CORSとWebセキュリティに関する権威あるリソース