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

ウェブ開発初心者の皆さん、 CORS（クロスオリジンリソースシェアリング） について聞いたことがありますか？ウェブアプリケーションを開発する上で、CORSは避けて通れない重要な概念です。本記事では、サブドメインやワイルドカードの扱い、no-corsオプションの使い方、そしてCORSに関連する脆弱性について、初心者にもわかりやすく解説します。

CORS（クロスオリジンリソースシェアリング）とは

CORSの基本概念をわかりやすく解説

CORS（Cross-Origin Resource Sharing）とは、異なるオリジン間でのリソース共有を可能にする仕組みです。CORSが生まれた背景には、同一オリジンポリシーというブラウザのセキュリティメカニズムがあります。同一オリジンポリシーは、プロトコル、ドメイン、ポートが一致しないオリジンからのリソースの取得を制限することで、悪意あるスクリプトによる攻撃を防ぐためのものです。しかし、APIサーバーやサードパーティのサービスを利用する場面が増える中で、この制約を安全に緩和する必要が出てきました。そこで登場したのがCORSです。CORSは特定のオリジンからのアクセスを許可することで、安全にリソースを共有する手段を提供します。

同一オリジンポリシーとサブドメインの関係

同一オリジンとは、プロトコル（http, https）、ドメイン名、ポート番号がすべて一致していることを指します。例えば、https://example.comとhttps://api.example.comは、サブドメインが異なるため同一オリジンではありません。このため、サブドメイン間でのリソース共有にはCORSの設定が必要になります。

CORSが必要になる場面とその理由

ウェブアプリケーションが以下の場合、CORSの設定が必要です。

• フロントエンドとバックエンドが異なるオリジンに存在する
• 外部APIを利用する
• CDNなど外部のリソースを読み込む

CORSを適切に設定することで、セキュアに異なるオリジンからのリソースを利用できます。例えば、フロントエンドのアプリケーションがバックエンドAPIからデータを取得する際、CORS設定によって不正なリクエストを防ぎ、信頼できるオリジンからのみデータを受け取ることができます。

CORSの仕組みと設定方法

CORSの仕組みを理解するためには、まず基本的なリクエストの流れを把握することが重要です。ブラウザとサーバー間でどのように通信が行われ、どのように許可されるかを知ることで、プリフライトリクエストの重要性も理解しやすくなります。

プリフライトリクエストとは

プリフライトリクエストとは、ブラウザが実際のリクエストを送信する前に、サーバーに対して許可されているメソッドやヘッダーの確認を行うために送信されるリクエストです。これは特に、カスタムヘッダーやPUT/DELETEなどの特定のHTTPメソッドを使用する際に重要です。プリフライトリクエストは、サーバーがリクエストを受け入れるかどうかを判断し、必要な情報を返すための仕組みです。このプロセスを正しく理解し、設定することで、CORSリクエストのセキュリティと機能性を保つことができます。

Access-Control-Allow-Originとワイルドカード（*）の使い方

サーバー側でCORSを設定する際、レスポンスヘッダーにAccess-Control-Allow-Originを追加します。このヘッダーには、許可するオリジンを指定します。

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

すべてのオリジンを許可する場合、ワイルドカード（*）を使用します。

Access-Control-Allow-Origin: *

しかし、ワイルドカードの使用はセキュリティ上のリスクがあるため、注意が必要です。例えば、すべてのオリジンからのアクセスを許可してしまうことで、悪意のある第三者からの不正なリクエストや、重要なデータの漏洩のリスクが増大します。このため、信頼できるオリジンのみを指定することが推奨されます。

no-corsオプションの役割と使用時の注意点

フェッチAPIやXMLHttpRequestを使用する際に、no-corsオプションを指定すると、シンプルなリクエストのみが許可されます。これは、セキュリティを強化するためですが、レスポンスの内容にアクセスできないなどの制約があります。

fetch('https://api.example.com/data', {
  mode: 'no-cors'
});

no-corsを指定すると、エラーは出ませんが、期待したデータを取得できない場合があるので注意が必要です。

サブドメイン間のリソース共有設定

サブドメイン間でリソースを共有する場合、Access-Control-Allow-Originヘッダーに共有を許可するサブドメインを指定します。

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

もしくは、オリジンを動的に設定することで、特定のサブドメインからのリクエストを許可できます。

CORSに関する脆弱性とその対策

CORS設定ミスによる脆弱性のリスク

CORSの設定を誤ると、悪意のあるサイトからの不正なリクエストを許可してしまう可能性があります。特に、認証情報や個人情報を扱うサイトでは、CORSの設定を慎重に行う必要があります。

ワイルドカード指定が招くセキュリティ上の問題

Access-Control-Allow-Originにワイルドカード（*）を使用すると、全てのオリジンからのアクセスを許可してしまいます。これは、XSS攻撃やCSRF攻撃のリスクを高めるため、信頼できるオリジンのみを指定することが推奨されます。

安全なサブドメイン間通信のためのベストプラクティス

• 特定のサブドメインのみを許可する

• 認証情報を含むリクエストでは、ワイルドカードを使用しない

• プリフライトリクエストを適切に処理する

  （CORSのリクエストの中には、実際のリクエストを送る前にブラウザがサーバーに確認を行う「プリフライトリクエスト」が含まれます。このリクエストは、特にカスタムヘッダーや認証情報が含まれる場合に重要です。プリフライトリクエストが正しく処理されないと、ブラウザはリソースへのアクセスをブロックしてしまいます。）

これらの対策を講じることで、サブドメイン間での安全なリソース共有が可能になります。

CORSの実践的な設定例とトラブルシューティング

具体的なCORS設定例（サーバー別）

Node.js（Express）での設定例

const express = require('express');
const app = express();
const cors = require('cors');

app.use(cors({
  origin: 'https://example.com',
  optionsSuccessStatus: 200
}));

Apacheでの設定（.htaccess）例

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

開発環境でのCORS設定とデバッグ方法

開発環境では、CORSエラーが発生した場合にブラウザのデベロッパーツールを使用して詳細を確認します。例えば、Google Chromeの場合、F12キーを押すか右クリックして「検証」を選択し、コンソールタブでエラーメッセージを確認します。ネットワークタブではリクエストとレスポンスのヘッダーを詳しく確認できます。また、一時的にCORSを無効化する拡張機能を使用して原因を特定することも有効です。ただし、本番環境では必ず正しいCORS設定を行ってください。

この記事のまとめ

CORSは、ウェブアプリケーション開発において重要な概念であり、正しく理解し適切に設定することで、セキュアかつ機能的なアプリケーションを構築できます。本記事では、初心者の方にもわかりやすくCORSの基本から設定方法、サブドメインやワイルドカードの扱い、脆弱性対策について解説しました。CORSに関する正しい知識を身につけて、安全なウェブ開発を進めていきましょう。

参考資料

• MDN Web Docs: HTTPアクセス制御（CORS）
• OWASP: CORSのセキュリティ
• クロスオリジンリソース共有 - Wikipedia