CORS設定ジェネレーター

Max-Age(秒):

CORS設定ジェネレーターの概要・基礎知識

CORS(Cross-Origin Resource Sharing)は、Webブラウザのセキュリティ機構である「Same-Origin Policy(同一オリジン制限)」を緩めて、異なるドメイン間のリソース共有を許可する仕組みです。フロントエンドを https://app.example.com 、APIサーバーを https://api.example.com のように別ドメインで運用する現代的なWeb構成では、CORS設定を正しく行わないとブラウザコンソールに「CORSエラー」が表示され、APIアクセスが失敗します。本ツールはサーバー環境(nginx/Apache/Express.js/Flask/Spring Boot/.htaccess)に応じて、コピペで動くCORS設定コードを生成します。

CORSで使う主要レスポンスヘッダー

ヘッダー名役割
Access-Control-Allow-Origin許可するオリジン(* または具体URL)
Access-Control-Allow-Methods許可するHTTPメソッド(GET、POST、PUT等)
Access-Control-Allow-Headers許可するリクエストヘッダー(Authorization等)
Access-Control-Allow-CredentialsCookie送信を許可するか(true 指定時 * は不可)
Access-Control-Max-Ageプリフライト結果のキャッシュ秒数(86400=24時間)

使い方の流れ

  1. Step 1で使っているサーバー環境を選びます(nginx、Apache、Express.js、Flask、Spring Boot、.htaccessから1つ)。
  2. Step 2で許可するオリジンを入力します。複数ある場合は改行で区切り、全許可なら「全オリジン許可(*)」をオンにします。
  3. Step 3で許可するHTTPメソッドにチェックを入れます。REST APIならGET/POST/PUT/DELETE/PATCH/OPTIONSが定番です。
  4. Step 4で許可するヘッダーを指定します。Content-TypeとAuthorizationはほぼ必須なので、プリセットボタンで素早く追加できます。
  5. Step 5でCredentials許可(Cookie送信)とMax-Age(プリフライトキャッシュ秒数)を設定し、「生成する」を押します。出力されたコードをサーバー設定ファイルに貼り付ければ完了です。

こんな場面で使う

  • SPA + API構成:React/Vue/NextのフロントエンドとExpress/Flask/Rails APIを別ドメインで動かすときの初期設定に使えます。
  • 本番/ステージング切り替え:本番は https://app.example.com のみ、ステージングは https://stg.example.com など、環境ごとに異なるオリジンを許可するコードを瞬時に生成できます。
  • 外部APIサービス公開:自社APIを公開し、サードパーティのWebサイトから呼び出してもらうための設定に使えます。
  • WebHook受信エンドポイント:Stripe・GitHub・Slackなどから直接POSTを受ける場合のCORS不要な構成と、ブラウザ経由で必要な構成を切り分けて設計できます。
  • WordPress REST API:.htaccessにCORSヘッダーを追加して、外部サイトからWP REST APIへアクセス可能にする場合に便利です。

使う前に知っておきたい注意点

  • Access-Control-Allow-Origin: *Allow-Credentials: true は併用できません。Cookieや認証情報を送る場合は具体的なオリジンを指定してください。
  • CORSはブラウザによる制限であり、サーバー側のセキュリティ機能ではありません。ブラウザ以外(curl、Postman、サーバー間通信)からのアクセスは制限されません。認可・認証は別途実装が必要です。
  • OPTIONSリクエスト(プリフライト)はブラウザが自動で送信します。サーバーはOPTIONSにも正しいCORSヘッダーを返さなければ本リクエストが失敗します。
  • 本ツールの生成コードは標準的な構成例です。プロジェクトのセキュリティ要件に合わせて、許可オリジンを最小限に絞ることを強く推奨します。
  • nginxの場合、add_header はステータスコード4xxや5xxのレスポンスには付与されないことがあります。always 指定が必要なケースもあるためご注意ください。

用語の補足

  • オリジン:プロトコル+ドメイン+ポート番号の組み合わせ。https://example.comhttp://example.comexample.com:8080 はすべて別オリジンです。
  • シンプルリクエスト:GET/POST(限定ヘッダーのみ)。プリフライトなしで送られます。
  • 非シンプルリクエスト:PUT/DELETE/PATCHや、カスタムヘッダー付きのリクエスト。事前にOPTIONSのプリフライトが送信されます。

よくある質問

公開APIや認証不要のエンドポイントなら問題ありません。ただし、Cookieや認証ヘッダーを使う場合は * が使えず、具体的なオリジンを指定する必要があります(Allow-Credentials: true との併用は不可)。社内向けや有料機能のAPIでは、許可オリジンを明示的に絞ってください。
ブラウザが本リクエストを送る前に「このリクエストを送って大丈夫か」を確認するための事前リクエストです。PUT/DELETE/PATCHなどの非シンプルリクエストや、カスタムヘッダー付きの場合に自動送信されます。サーバーはOPTIONSにも正しいCORSヘッダーを返さなければ本リクエストが失敗します。
CORSはブラウザによる制限であり、サーバー側がリクエストをブロックしているわけではありません。curlやPostmanからの直接アクセスや、サーバー間通信ではCORS制限が適用されないため、ブラウザでだけ失敗するのは正常な挙動です。
CORS仕様上、Access-Control-Allow-Originには1つのオリジンしか書けません。複数ドメインを許可する場合は、リクエストヘッダーの Origin 値を見てサーバーで動的に判定し、許可リストに含まれるオリジンだけをそのままレスポンスヘッダーに設定する実装が一般的です。本ツールが生成するコードもその方式に対応しています。
86400秒(24時間)が一般的な目安です。これより長くしてもブラウザ側で上限が設定されており、Chromeでは2時間が上限です。CORSヘッダーを頻繁に変更する開発中は短め(300秒など)に、本番では長めに設定するのが運用上スムーズです。
フロント側で fetch(url, { credentials: 'include' }) を指定し、サーバー側で Access-Control-Allow-Credentials: true と具体的なオリジン(* 不可)を返す必要があります。さらにCookieに SameSite=None; Secure 属性が付いていないとクロスオリジンでは送られません。
いいえ、すべての設定生成はブラウザ上で完結し、外部送信は一切ありません。許可オリジン情報が外部サーバーに記録されることはありません。