オリジン間リソース共有 - CORS（オリジン間リソース共有）

異なるオリジン間での HTTP リクエストを制御する仕組み。同一オリジンポリシーを緩和しつつ、不正なアクセスを防ぐ。

概念図

実例

CORS レスポンスヘッダの設定例

bash

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Express.js での CORS ミドルウェア設定

bash

// Express.js での CORS 設定
const cors = require("cors");
app.use(cors({
  origin: ["https://app.example.com"],
  methods: ["GET", "POST"],
  credentials: true,
  maxAge: 86400
}));

CORS の仕組み

ブラウザは同一オリジンポリシー（Same-Origin Policy）により、異なるオリジンへの JavaScript からのリクエストをデフォルトでブロックします。

CORS はサーバー側が HTTP ヘッダで「どのオリジンからのアクセスを許可するか」を宣言する仕組みです。

単純リクエスト（Simple Request）: GET, HEAD, POST（条件付き）は直接送信され、レスポンスの Access-Control-Allow-Origin ヘッダで検証される
プリフライトリクエスト（Preflight）: PUT, DELETE、カスタムヘッダを含むリクエストは、事前に OPTIONS メソッドで許可を確認する。Access-Control-Max-Age でプリフライト結果をキャッシュできる
認証情報付きリクエスト: credentials: "include" の場合、Access-Control-Allow-Origin にワイルドカード（*）は使用できない。具体的なオリジンを指定する必要がある

よくある設定ミスと対策

Access-Control-Allow-Origin: * の乱用: 全オリジンを許可するとセキュリティリスクが高い。信頼できるオリジンのみをホワイトリストで指定する
Origin ヘッダのリフレクション: リクエストの Origin ヘッダをそのまま Access-Control-Allow-Origin に返す実装は危険。攻撃者のオリジンも許可してしまう
null オリジンの許可: Access-Control-Allow-Origin: null はサンドボックス化された iframe から悪用される可能性がある
credentials と wildcard の同時使用: Access-Control-Allow-Credentials: true と Access-Control-Allow-Origin: * は同時に使用できない。ブラウザがエラーにする

概念図

実例

CORS の仕組み

よくある設定ミスと対策

関連トピック