CORS徹底ガイド｜初心者でもわかる仕組み・エラー対策・API連携の実践テクニック

CORSとは

CORS（Cross-Origin Resource Sharing／クロスオリジンリソースシェアリング）は、異なるオリジン間でWebリソースを安全に共有するための仕組みです。

ここでいう「オリジン」とは、URLのスキーム（httpやhttps）、ホスト（ドメイン）、ポート番号の組み合わせで定義されます。たとえば「http://example.com」と「https://example.com」や、「http://example.com:8080」はそれぞれ異なるオリジンとなります。

出典：CORSを理解する｜Qiita

Webのセキュリティを守るため、ブラウザには「同一オリジンポリシー」というルールがあり、あるオリジンで読み込まれたWebページやJavaScriptが、別のオリジンにあるリソースへ自由にアクセスすることを原則として禁止しています。

これにより、悪意あるサイトからの個人情報漏洩や不正な操作を防いでいます。

しかし、現代のWebアプリでは、APIを使って異なるドメイン間でデータをやり取りする必要が増えています。

そこで登場したのがCORSです。追加のHTTPヘッダーを使い、サーバー側が「どのオリジンからのアクセスを許可するか」を明示的に指定できる仕組みになっています。CORSは、正しく設定することで、Webアプリの利便性とセキュリティを両立させるための重要な技術として機能します。

出典：クロスオリジンリソース共有 (CORS) - HTTP | MDN

同一オリジンポリシーとの関係

同一オリジンポリシーは“クロスオリジンの読み取り（JavaScriptからの参照）を制限する”ためのブラウザ機能です。

一方で、リンク遷移やフォーム送信、画像・スクリプトの埋め込みなど、クロスオリジンへの“送信”自体は歴史的に許可されてきたものも多く、問題になるのは“レスポンスをJavaScriptで読めるかどうか”です。CORSは、サーバーが許可した場合にこの読み取り制限を緩和します。

出典：同一オリジンポリシー / CORS

出典：RFC 6454 ｜ Webオリジンコンセプト

このルールは、JavaScriptなどのクライアントサイドスクリプトによる情報漏洩や不正操作を防ぐために非常に重要です。

たとえば、ユーザーがログインしている銀行サイト（オリジンA）を開いたまま、悪意のあるサイト（オリジンB）にアクセスしたとします。このとき、オリジンBのスクリプトからオリジンAの情報へ自由にアクセスできてしまうと、個人情報や資金が不正に取得される危険があります。

これを防ぐため、同一オリジンポリシーは「異なるオリジンからのデータの読み取り」を厳しく制限しています。

ただし、現代のWebサービスでは、API連携や外部サービス利用など、異なるオリジン間でのデータ共有が不可欠になっています。ここで登場するのがCORS（Cross-Origin Resource Sharing）です。

CORSは、サーバー側が特定のオリジンからのリクエストを許可することをHTTPヘッダーで明示し、同一オリジンポリシーの例外として安全にリソースを共有できる仕組みです。

CORSがなければ、たとえば、フロントエンドとバックエンドが異なるドメインで動作している場合、API通信がすべてブロックされてしまいます。CORSを適切に設定することで、信頼できるオリジンからのリクエストのみを許可し、セキュリティと利便性を両立できます。

このように、同一オリジンポリシーはWebの安全性を守るための基本ルールであり、CORSはその制限を安全に緩和するためのプロトコルとして機能します。両者の関係を理解し適切に活用することが、現代のWeb開発には不可欠です。

CORSの仕組みと主要なHTTPヘッダー

CORS（クロスオリジンリソースシェアリング）は、異なるオリジン間で安全にデータをやり取りするためにHTTPヘッダーを活用する仕組みです。

Webブラウザは、セキュリティの観点からJavaScriptによるクロスオリジン通信を基本的に制限しますが、CORS設定があることで、サーバー側が許可したオリジンからのアクセスだけを許可できます。

仕組みとしては、ブラウザがリクエストを送る際に「Origin」ヘッダーで自分のオリジン情報をサーバーに伝えます。受け取ったサーバーはレスポンスで「Access-Control-Allow-Origin」ヘッダーを返し、許可するオリジンを明示します。

たとえば「Access-Control-Allow-Origin: https://example.com」と設定すれば、そのオリジンからのリクエストだけが許可されます。

出典：初心者のためのCORSガイド - サブドメインと脆弱性対策を理解しよう

Access-Control-Allow-Origin: * は、公開コンテンツ（誰が読んでも同一で、Cookie等の認証情報を使わない）に限れば有効な選択肢です。一方、ユーザー別に内容が変わる／credentialsを使うAPIでは避け、許可オリジンを明示しましょう。

CORSでよく使われる主なHTTPヘッダー

出典：Cross-Origin エラーを完全に理解する

出典：開発者向けCORS

CORSでよく出てくる“シンプルリクエスト（旧称：単純リクエスト、simple request）”は、単にGET/POSTだからというだけで決まるわけではありません。

一般に、以下の3条件をすべて満たす場合にプリフライトリクエスト（preflight）が省略されます。

(1) メソッドがGET/HEAD/POST

(2) 手動で付与するリクエストヘッダーが一定の安全リスト内

(3) POSTのContent-Typeが application/x-www-form-urlencoded / multipart/form-data / text/plain のいずれか

これらの条件から外れる（例：Authorizationヘッダーを付ける、Content-Type: application/jsonで送る、PUT/DELETEを使う など）と、ブラウザは通常プリフライトリクエストを実行します。

一方で、カスタムヘッダーやPUT/DELETEなどを使う場合は「プリフライトリクエスト」となり、ブラウザが事前にOPTIONSメソッドでサーバーに確認を行います。

サーバーが適切なCORSヘッダーを返さない場合、リクエストはブロックされます。

このように、CORSはHTTPヘッダーを通じてブラウザとサーバー間で安全なクロスオリジン通信を実現しています。設定ミスや不十分なヘッダー指定があると、CORSエラーが発生するため、各ヘッダーの役割と仕組みを正しく理解しておくことが重要です。

CORSエラーの主な原因

CORSエラーは、Webブラウザが異なるオリジン（ドメイン・プロトコル・ポートが1つでも異なる場合）からのリソース取得をセキュリティ上の理由で制限する際に発生します。

この仕組みは、悪意のあるサイトからの不正アクセスや情報漏洩を防ぐために不可欠ですが、API連携や外部サービス利用が一般的になった現代のWeb開発では、CORSエラーは頻繁に遭遇するトラブルの一つです。

主なCORSエラーの原因

• サーバーがCORSを許可していない
  サーバー側で「Access-Control-Allow-Origin」などのCORS関連ヘッダーが設定されていない場合、ブラウザはリクエストをブロックします。

たとえば、No 'Access-Control-Allow-Origin' header is present on the requested resource. というエラーメッセージが表示されることがあります。

• 許可されていないオリジンからのアクセス
  サーバーが特定のオリジンのみを許可している場合、リクエスト元のオリジンがそのリストに含まれていなければ、CORSエラーとなります。
• プリフライトリクエストの失敗
  カスタムヘッダーやPUT・DELETEなどの特殊なHTTPメソッドを使う場合、ブラウザは事前にOPTIONSメソッドで「プリフライトリクエスト」を送信します。

サーバーがこれに正しく応答しない、または必要なヘッダー（Access-Control-Allow-MethodsやAccess-Control-Allow-Headersなど）が不足している場合、メインのリクエストも拒否されます。

• 認証情報付きリクエストの制限
  Cookieや認証トークンを含むリクエストを送信する場合、クライアント側でcredentials: 'include'などの設定が必要です。同時に、サーバー側でもAccess-Control-Allow-Credentials: trueを明示しなければなりません。どちらか一方でも設定が不足しているとCORSエラーとなります。
• SSL証明書やローカル環境の問題
  ローカル環境でバックエンドサーバーを起動する際、クライアントの証明書が未登録だったり、SSL証明書が正しく設定されていなかったりすると、CORSエラーが発生することがあります。

これらの原因を理解し、サーバー側で適切なCORS設定を行うことが、CORSエラー解決の第一歩です。

出典：CORSとは？初心者にもわかるクロスオリジンリソース共有の解説

CORSエラーの解決方法

CORSエラーの解決には、主にサーバー側で適切なCORS設定を行うことが重要です。CORSは異なるオリジン間の通信を制限する仕組みであり、サーバーが明示的に許可しない限り、ブラウザはリクエストをブロックします。

出典：同一オリジンポリシーを理解する。CORSエラーの原因と回避方法！

まず行うべきは、サーバーのレスポンスヘッダーに「Access-Control-Allow-Origin」を追加し、許可したいオリジン（例：http://localhost:8100やhttps://example.com）を指定することです。これにより、そのオリジンからのアクセスが許可され、CORSエラーを防げます。

複数のオリジンを許可したい場合は、サーバー側でリクエストの「Origin」ヘッダーを判別し、条件分岐で必要なオリジンのみ許可するように設定します。開発環境では一時的に「*」を指定して全てのオリジンを許可することも可能ですが、本番環境では信頼できるオリジンだけを明示することが推奨されます。

また、PUTやDELETEなどの特殊なHTTPメソッドやカスタムヘッダーを使う場合は、ブラウザが事前にOPTIONSメソッドでプリフライトリクエストを送信します。

サーバー側で「Access-Control-Allow-Methods」や「Access-Control-Allow-Headers」などのヘッダーも正しく設定しましょう。

認証情報を含む場合は、クライアント側で credentials: 'include' を指定し、サーバー側では Access-Control-Allow-Credentials: true を設定します。

ただしこの際、Access-Control-Allow-Origin: * は使えず、明示的なオリジン（例：https://example.com）を返す必要があります。

また、プリフライトリクエスト（OPTIONS）自体にはcredentialsは含まれません。プリフライトリクエストのレスポンスでcredentials許可が確認できて初めて、本リクエストにcredentialsが付きます。

もしAPIサーバーが自社管理でなく設定変更が難しい場合は、フロントエンドとAPIサーバーの間にプロキシサーバーを設置し、CORSエラーを回避するアプローチもあります。

証明書エラー（TLS/HTTPSの問題）とCORSエラーは別物です。

CORSは主に“ブラウザがクロスオリジンのレスポンスをJavaScriptに公開するか”を制御します。一方、HTTPSの証明書不備や混在コンテンツなどで通信が失敗している場合、CORSヘッダー設定以前にリクエストが成立せず、結果として似た見た目のエラーに見えることがあります。

まずはDevToolsのNetworkで、リクエストが到達してレスポンスヘッダーが返っているか（返っていないならネットワーク/TLS側の問題）を切り分けましょう。

まとめると、CORSエラーの根本解決は「サーバー側で正しいCORSヘッダーを設定すること」に尽きます。フロントエンド側での一時的な回避策もありますが、基本的にはサーバー側の設定が最も確実な対応策です。

出典：クロスオリジンリソース共有 (CORS) - HTTP | MDN

API連携でのCORS活用テクニック

API連携におけるCORS活用テクニックは、セキュリティを確保しつつ、フロントエンドとバックエンド間の通信を円滑に行うために不可欠です。ここでは、実際の設定例や運用上のポイントを中心に解説します。

API Gatewayやクラウドサービスを利用する場合は、管理コンソールや設定画面からCORSを有効化できます。※API Gateway等の具体的な設定方法は後述します。

Spring Bootなどのフレームワークを使う場合は、コントローラーメソッドやクラスに@CrossOriginアノテーションを付与することで、簡単にCORSを有効化できます。

アノテーションの属性で許可するオリジンやメソッド、ヘッダーなどを細かく制御し、セキュリティと柔軟性を両立させることも可能です。

API連携でCORSを活用する際は、以下の点も意識しましょう。

• 必要最小限のオリジンだけを許可し、セキュリティリスクを低減する
• プリフライトリクエスト（OPTIONSメソッド）への対応を忘れずに、必要なヘッダーやメソッドを明示する
• APIの仕様や認証方式に応じてCORS設定を調整し、想定外のエラーを防ぐ

このようなテクニックを押さえておくことで、安全かつ快適なAPI連携を実現できます。

出典：REST API で CORS を有効化

サーバー別CORS設定方法（Node.js・Apache・AWSなど）

Node.js（Express）でのCORS設定

Node.jsのExpressフレームワークでは、公式のcorsミドルウェアを利用するのが一般的です。

まず、npm install corsでパッケージをインストールします。

すべてのオリジンからのアクセスを許可する場合は、以下のように記述します。

javascript

const express = require('express');

const cors = require('cors');

const app = express();

app.use(cors()); // 全てのオリジンを許可

特定のオリジンのみ許可したい場合は、オプションを指定します。

javascript

app.use(cors({

  origin: 'https://example.com', // 許可するオリジン

  methods: ['GET', 'POST'],      // 許可するHTTPメソッド

  credentials: true              // 認証情報を含むリクエストを許可

}));

複数オリジンを許可したい場合は、配列や関数で動的に制御できます。

ApacheでのCORS設定

Apacheの場合は、.htaccessやサーバーの設定ファイルにヘッダーを追加します。

すべてのオリジンを許可する例

<IfModule mod_headers.c>

  Header set Access-Control-Allow-Origin "*"

</IfModule>

特定のオリジンのみ許可する場合

<IfModule mod_headers.c>

  Header set Access-Control-Allow-Origin "https://example.com"

</IfModule>

必要に応じて、Access-Control-Allow-MethodsやAccess-Control-Allow-Headersも追加します。

AWS（API Gateway/S3）でのCORS設定

API Gateway
AWS API Gatewayでは、管理画面からCORSを有効化できます。各メソッド（例：GET, POST）に対して「CORSの有効化」を選択し、許可するオリジンやメソッド、ヘッダーを設定します。

OPTIONSメソッドを追加し、CORS関連ヘッダー（Access-Control-Allow-Originなど）を明示します。

S3
S3バケットの「プロパティ」から「CORS設定」を編集し、JSON形式で許可ルールを記述します。
例：

　json

[

  {

    "AllowedOrigins": ["https://example.com"],

    "AllowedMethods": ["GET", "POST"],

    "AllowedHeaders": ["*"]

  }

]

サーバーごとにCORSの設定方法は異なりますが、共通して「どのオリジンからのアクセスを許可するか」を明示的に指定することが重要です。

開発環境ではワイルドカード（*）を使ってもよいですが、本番環境ではセキュリティのために必要最小限のオリジンだけを許可しましょう。

セキュリティ観点から見たCORSの注意点

CORS（Cross-Origin Resource Sharing）は、異なるオリジン間でのリソース共有を制御するための仕組みですが、セキュリティ観点ではいくつか重要な注意点があります。

まず、CORSはあくまで「ブラウザが適用するセキュリティ制約の緩和策」であり、サーバーサイドや非ブラウザ環境（curlやPostmanなど）からのアクセスには効果がありません。そのため、APIやリソースの公開範囲をCORSだけに頼るのは危険です。

特に注意すべきは、サーバー側での設定ミスです。たとえば「Access-Control-Allow-Origin: *」のように全てのオリジンからのアクセスを許可してしまうと、意図しない第三者や悪意あるサイトからもリソースが利用できてしまい、情報漏洩や不正利用のリスクが高まります。

また、信頼できないドメインを許可リストに加えてしまうと、攻撃者がそのドメインを利用して不正リクエストを送れる恐れがあります。

さらに、認証情報（Cookieやトークンなど）を含むリクエストの場合は、「Access-Control-Allow-Credentials: true」と「特定のオリジン指定」を組み合わせる必要があります。

ここでワイルドカード（*）を使うと、認証情報が外部に漏洩する危険性があるため、必ず個別の信頼できるオリジンを指定することが推奨されます。

加えて、CORSはXSS（クロスサイトスクリプティング）やCSRF（クロスサイトリクエストフォージェリ）など、他のWeb攻撃手法を防ぐものではありません。

CORS設定が適切でも、アプリケーション自体の認証・認可や入力値検証、XSS/CSRF対策など、総合的なセキュリティ対策が不可欠です。

まとめると、CORSは便利な仕組みですが、設定ミスや過信による脆弱性リスクがあるため、「最小限のオリジンのみ許可」「認証情報の扱いに注意」「他のセキュリティ対策と併用」という点に十分注意して運用することが重要です。

出典：【情報処理安全確保支援士】HTTPに関するセキュリティリスクについて（その5）： CORS（Cross-Origin Resource Sharing）について

まとめ

CORS（Cross-Origin Resource Sharing）設定のベストプラクティスは、セキュリティと利便性の両立に不可欠です。まず最も重要なのは、「最小限の許可」を徹底することです。

許可するオリジン・HTTPメソッド・ヘッダーは本当に必要なものだけに限定し、不必要にアクセスを開放しないよう厳密に設定しましょう。特に本番環境では、信頼できるオリジンのみを明示的に指定し、ワイルドカード（*）の使用は避けるべきです。

認証情報（Cookieやトークン）を含むAPI連携では、「Access-Control-Allow-Credentials: true」をサーバー側で設定し、クライアント側でもcredentials: 'include'を指定します。

この場合、オリジンはワイルドカードではなく必ず特定のドメインを指定してください。また、開発環境と本番環境でCORS設定を切り分ける運用も推奨されます。開発中は利便性を優先して広く許可し、本番ではセキュリティを重視して必要最低限に絞るのが理想です。

CORS設定後は、ブラウザのデベロッパーツールや専用のテストツールを活用して、リクエスト・レスポンスヘッダーを必ず確認しましょう。エラーが発生した場合は、サーバー側のCORSヘッダー設定を再確認し、プリフライトリクエスト（OPTIONSメソッド）への適切な応答も忘れずに実装してください。

CORSは万能な防壁ではなく、API自体の認証・認可やXSS・CSRF対策など、他のセキュリティ対策と併用することが不可欠です。

設定や運用ルールは、サービスや利用状況の変化に合わせて定期的に見直し、脆弱性が発見された場合は速やかに修正しましょう。
CORSの正しい設定は、安全なAPI連携とWebサービス運用の基盤です。これらのベストプラクティスを徹底し、セキュリティと利便性を両立させましょう。