ForHosting KIT · 開発者向けツール

CORS ヘッダー設定チェック

この CORS ヘッダー設定チェッカーは、ブラウザーのオリジン間アクセスを制御するレスポンスヘッダーを調べます。ヘッダーのまとまりを貼り付けると、Access-Control-Allow-Origin の存在を確認し、ワイルドカードオリジンと認証情報の危険な組み合わせを検出し、特定のオリジンを許可する場合に Vary: Origin がないことを指摘します。結果は決定的で、各検出事項に説明が付きます。対象サーバーへリクエストを送らずに、リリース審査、インシデント調査、自動構成検査、日常的な API の強化にご利用いただけます。

● Beta無料・ブラウザ内で実行

無料で実行 API仕様を見る

ご利用方法ウェブAPIメールTelegramアプリ近日

対象を絞った構成審査として結果をお読みください

最初に、ブラウザーまたはコマンドラインクライアントが受信したレスポンスヘッダーを、そのままコピーしてください。1 行につき「名前: 値」の組を 1 つ記載します。ヘッダー名は大文字と小文字を区別せずに比較し、コンマで区切られた Vary の値は個別のトークンとして処理します。このチェッカーでは Access-Control-Allow-Origin が必須です。このヘッダーがなければ評価対象となる CORS レスポンスポリシーが存在しないため、欠落時には不確定な報告ではなく入力エラーを返します。正常な報告には、正規化した許可オリジン、認証情報を許可しているか、レスポンスが Origin によって変化するか、および順序付きの検出事項が含まれます。valid は、エラー重大度の問題が見つからなかったことを示します。ただし警告が残る場合があるため、利用側では issue_count と issues もご確認ください。対象範囲は意図的に限定しています。よくある 2 種類の誤りについて安定した事実を示しますが、アプリケーションの認可モデル全体の安全性を保証するものではありません。監査証跡に使う場合は、元のレスポンスとリクエストオリジンも結果と一緒に保存してください。

ワイルドカードと認証情報付きリクエストをご理解ください

Access-Control-Allow-Origin: * は、認証情報を使わない真に公開されたリソースでは便利です。どの要求元オリジンからもレスポンスを読み取れるためです。一方、Access-Control-Allow-Credentials: true と組み合わせてはいけません。ブラウザーは認証情報付き CORS アクセスでこの組み合わせを拒否します。また、この設定はサーバーが意図する信頼境界を正しく表現できていない兆候にもなります。チェッカーは wildcard_origin_with_credentials をエラー重大度で記録します。解決策として、受信したすべての Origin を無条件に反映してはいけません。信頼するオリジンを決め、リクエストの Origin を明示的な許可リストと照合し、一致した場合だけ 1 つの承認済みオリジンを返してください。Cookie などの周辺認証情報が不要なら、認証情報のサポートを無効にし、公開用のワイルドカードポリシーを維持できます。なお、CORS が制御するのはブラウザースクリプトによるレスポンスの読み取りです。認証、認可、リクエスト偽造対策、ファイアウォールの代わりにはなりません。Cookie 属性、認可処理、メソッド、公開ヘッダー、プリフライト動作は別途確認してください。

Vary: Origin で共有キャッシュを正しく保ってください

サーバーがリクエストの Origin に応じて特定の Access-Control-Allow-Origin 値を選ぶ場合、レスポンスの表現は実質的にそのリクエストヘッダーへ依存します。Vary: Origin は、異なるオリジン向けのレスポンスを同じものとして扱ってはならないと、ブラウザー、リバースプロキシ、コンテンツ配信キャッシュへ伝えます。この指定がないと、あるテナントの許可オリジンを含むレスポンスが別のリクエストに再利用され、断続的な障害や、キャッシュ済みコンテンツに関するポリシー前提の破綻を招く可能性があります。そのため、許可オリジンが特定値で、Vary に Origin もワイルドカードトークンもない場合、チェッカーは missing_vary_origin を出力します。コンマ区切りの Vary 行と、繰り返された Vary ヘッダーの両方を認識します。貼り付けられたレスポンスだけでは、オリジン値が全リクエストで一定なのか、別の場所でキャッシュが無効なのか判断できないため、重大度は警告です。本番環境を変更する前に、サーバーの実際の選択ロジックとキャッシュ指示をご確認ください。許可リストで検証した後にオリジンを動的に反映するなら、Vary へ Origin を追加する方法が一般に最も明確で安全です。

活用例

API リリースを審査する

ステージング環境のレスポンスヘッダーを貼り付け、公開前に認証情報やキャッシュ変化の危険な設定を検出できます。

ブラウザーの CORS 障害を調査する

オリジンやキャッシュ経路によって画面の動作が変わる場合に、取得したヘッダーを明確な検出事項へ変換できます。

構成検査を自動化する

CI から決定的なヘッダーブロックを API へ送り、エラー重大度の検出事項があればポリシー検査を失敗させられます。

よくある質問

検査の料金はいくらですか？

ブラウザー版はローカルで動作し、API リクエスト 1 件の料金は $0.002 です。

Access-Control-Allow-Origin の欠落がエラーになるのはなぜですか？

このヘッダーは CORS レスポンスポリシーの基礎です。存在しなければ、この限定的なチェッカーが評価できる許可オリジン値もありません。

Access-Control-Allow-Origin: * は常に危険ですか？

いいえ。認証情報を許可しない公開リソースには適する場合があります。エラーには、ワイルドカードと true に設定された認証情報の両方が必要です。

Vary: Origin の欠落が警告にとどまるのはなぜですか？

レスポンスだけでは、リクエストごとにオリジンが変わるか、中継者がキャッシュできるか分かりません。警告はその周辺条件の確認を促します。

この検査でエンドポイントの安全性を証明できますか？

いいえ。一般的な CORS ヘッダーの誤りを 2 種類確認するものです。認証、認可、Cookie、プリフライト、許可メソッド、リクエスト偽造対策は別途審査が必要です。

ヘッダー名では大文字と小文字を区別しますか？

いいえ。HTTP ヘッダー名と関連するディレクティブトークンは、大文字と小文字を区別せずに比較します。

開発者向け — APIアクセス

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

エンドポイント

POSThttps://api.kit.forhosting.com/security/cors-header-check

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

お使いのスタックから呼び出す

curl -X POST https://api.kit.forhosting.com/security/cors-header-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"headers":"Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"}'

const res = await fetch("https://api.kit.forhosting.com/security/cors-header-check", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "headers": "Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/security/cors-header-check",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "headers": "Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/cors-header-check", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"headers":"Access-Control-Allow-Origin: https://app.example.com\\nAccess-Control-Allow-Credentials: true\\nVary: Accept-Encoding, Origin"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"headers":"Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/cors-header-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

リクエスト例

{
  "headers": "Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"
}

レスポンス例

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "security.cors_header_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

料金

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

エラー

HTTP	コード	意味
`401`	`unauthorized`	APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
`402`	`insufficient_balance`	残高が不足しています。チャージ後に再度お試しください。
`404`	`unknown_type`	指定されたタスクタイプは存在しません。タイプ名を確認してください。
`429`	`rate_limited`	リクエストが多すぎます。しばらく待ってから再度お試しください。

KITの完全なドキュメントを見る →