Access-Control-Allow-Origin ヘッダーは、**クロスオリジンリソース共有（CORS）**の仕組みの一部で、他のオリジン（ドメイン）からのリクエストを許可するかどうかを制御するためのものです。
このヘッダーを設定することで、指定したオリジン（例: https://example.com）からの JavaScript による XMLHttpRequest や Fetch API などのクロスオリジンリクエストが許可されるようになります。
Access-Control-Allow-Origin: https://example.comこの場合、https://example.com からのリクエストは許可されますが、それ以外のオリジンからのリクエストは拒否されます。
Access-Control-Allow-Origin ヘッダーは1つのオリジンしか指定できないというHTTP仕様の制約があるため、リクエストの Origin に応じて動的に切り替える必要があります。
1つのオリジンしか指定できないというHTTP仕様の制約 🔗
よく使われる設定
| 設定値 | 意味 |
| * | すべてのオリジンからのアクセスを許可（ただし、認証情報付きリクエストには使えません） |
| https://example.com | 指定したオリジンのみ許可 |
| 複数オリジン | 明示的に複数オリジンを許可するには、動的にレスポンスを生成する必要があります（IISではWeb.configやモジュールで対応 |
IISマネージャーでの操作手順
① IISマネージャーを起動
- Windowsキー → 「IIS」または「インターネット インフォメーション サービス（IIS）マネージャー」で検索
- 起動後、左ペインで対象のサイトを選択
② HTTP応答ヘッダーを開く
- 対象サイトを選択した状態で、中央ペインの「機能ビュー」から
「HTTP 応答ヘッダー」 をダブルクリック
③ ヘッダーの追加
- 右ペインの「操作」から 「追加…」 をクリック
- 以下のように入力：
| 項目 | 値 |
|---|---|
| 名前 | Access-Control-Allow-Origin |
| 値 | https://example.com ※ |
※ * を指定するとすべてのオリジンを許可しますが、セキュリティ上の注意が必要です。
④ 必要に応じて他のCORSヘッダーも追加
たとえば、Cookieなどの認証情報を含むリクエストを許可する場合：
| 名前 | 値 |
|---|---|
Access-Control-Allow-Credentials | true |
⑤ 設定を保存してテスト
- 「OK」で保存し、IISを再起動する必要はありません
- ブラウザの開発者ツール（F12）で、レスポンスヘッダーに
Access-Control-Allow-Originが含まれているか確認できます
複数オリジンを許可したい場合
UIからは 1つのオリジンしか指定できないため、複数対応には以下のいずれかが必要です：
- URL Rewrite モジュールで条件分岐（前述のXML設定）
- アプリケーションコード側で動的にヘッダーを追加（ASP.NETなど）
- カスタムHTTPモジュールの実装
必要であれば、ASP.NETやPHPなどでの動的CORS対応方法もご案内できます。どの言語・環境で運用されているか教えていただければ、さらに具体的にお手伝いできますよ。
IIS CORS モジュールで複数オリジンを許可する方法
1. Web.config に CORS 設定を追加
IIS CORS モジュールは Web.config で制御できます。以下は複数オリジンを条件付きで許可する例です：
<configuration>
<system.webServer>
<cors enabled="true">
<add origin="https://example.com" />
<add origin="https://anotherdomain.com" />
</cors>
</system.webServer>
</configuration>この設定により、Origin ヘッダーが https://example.com または https://anotherdomain.com の場合に限り、レスポンスに Access-Control-Allow-Origin が追加されます。
2. IIS CORS モジュールの動作ポイント
- リクエストの Origin を自動判定し、Web.config に一致する場合のみ許可
Access-Control-Allow-Originは 一致した1つのオリジンのみがレスポンスに出力される*（ワイルドカード）は使えません（IIS CORS モジュールでは非対応）
3. モジュールのインストール（必要な場合）
IIS CORS モジュールは Windows Server に標準では含まれていない場合があります。以下からインストール可能です：
IIS に Microsoft CORS モジュールが含まれているかどうかを確認するには、以下の方法が使えます。
方法①：IIS マネージャーで確認
- IIS マネージャーを起動
- Windowsキー → 「IIS」または「インターネット インフォメーション サービス（IIS）マネージャー」
- 対象のサイトまたはサーバーを選択
- 中央ペインの「機能ビュー」に CORS 関連の項目があるか確認
CORSという名前のアイコンが表示されていれば、モジュールがインストールされています
方法②：PowerShell で確認
以下のコマンドを PowerShell で実行すると、インストール済みの IIS モジュール一覧が表示されます：
Get-WebGlobalModuleこの中に CorsModule が含まれていれば、CORS モジュールはインストール済みです。
方法③：%windir%\System32\inetsrv フォルダーを確認
以下の DLL ファイルが存在すれば、CORS モジュールがインストールされています：
Microsoft.IIS.CORS.dll
方法④：Web.config に セクションが使えるか確認
Web.config に以下のような記述をして、IISがエラーを出さずに読み込めるか確認する方法もあります：
エラーが出る場合は、モジュールが未インストールの可能性があります。
IIS CORSモジュールがインストールされていない場合
Microsoft公式サイトからダウンロードできます：
インストール後は、IISを再起動して有効化されます。
「CORS」は英語では通常、「コーズ」（/kɔːrz/）と発音されます。
IIS CORS Moduleのインストール
Powershellで確認
Cross-Origin Resource Sharing（CORS）とは？
Cross-Origin Resource Sharing（CORS）とは、異なるオリジン（ドメイン、ポート、プロトコル）間での安全なリソース共有を可能にする仕組みです。主に Webブラウザとサーバー間の通信において、セキュリティ制約を緩和するための標準仕様です。
なぜCORSが必要なのか？
通常、Webブラウザは「同一オリジンポリシー」に従い、異なるオリジンのリソースへのアクセスを制限します。これはセキュリティ上の理由からで、悪意あるサイトがユーザーの情報に勝手にアクセスするのを防ぐためです。
しかし、現代のWebアプリでは、APIサーバーとフロントエンドが別ドメインで動作することが多く、正当な理由でクロスオリジン通信が必要になる場面があります。そこで登場するのがCORSです。
CORSの仕組み
CORSでは、サーバー側がHTTPレスポンスヘッダーで明示的に許可することで、ブラウザがクロスオリジン通信を許可します。
主なレスポンスヘッダー：
| ヘッダー名 | 役割 |
|---|---|
Access-Control-Allow-Origin | 許可するオリジンを指定（例:https://example.com) |
Access-Control-Allow-Methods | 許可するHTTPメソッド（例GETPOST) |
Access-Control-Allow-Headers | 許可するカスタムヘッダー |
Access-Control-Allow-Credentials | Cookieなどの認証情報を許可するか |
プリフライトリクエストとは？
特定の条件（例: PUTメソッドやカスタムヘッダー使用）では、ブラウザは本リクエストの前に OPTIONSメソッドによる「プリフライトリクエスト」 を送信します。これにより、サーバーがCORSを許可しているかを事前に確認します。
CORSはセキュリティを緩めるのではなく「制御する」
CORSは単なる制限解除ではなく、サーバーが明示的に「このオリジンからのアクセスは許可する」と宣言することで、安全に制御されたクロスオリジン通信を実現します。
もし、具体的なCORS設定例（IIS、Apache、Node.jsなど）や、プリフライトの挙動をコード付きで見たい場合は、そちらもご案内できますよ。どの環境で使われているか教えていただければ、さらに深掘りできます。
Leave a Comment