CORS ヘッダービルダー
ブラウザのクロスオリジンリクエストを満たすためにサーバーが送信する必要のあるレスポンスヘッダーを構築する。Allow-Origin、Allow-Methods、Allow-Headers、Expose-Headers、Allow-Credentials、Max-Age、および Vary: Origin ヒントを含む。よくある落とし穴にフラグを立てる：* を credentials と組み合わせる（ブラウザがブロックする）、Origin: null を受け入れる（攻撃者がスプーフィングできる）、または不合理に長い時間プリフライトをキャッシュするようブラウザに要求する。
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Headers: Content-Type, Authorization Access-Control-Allow-Credentials: true Access-Control-Max-Age: 600 Vary: Origin
これらをプリフライト OPTIONS *と* 実際のリクエストへのレスポンスに適用する。Origin をエコーする場合、エッジキャッシュには Vary: Origin が必要。
使い方
- あなたのシナリオに合うプリセットから始める。
- オリジンを設定する（完全公開には *、credentialed API にはサーバーサイドでリクエストの Origin をエコー）。
- エンドポイントが実際に受け入れるメソッドとヘッダーのみを選択 — 狭いほど安全。
- ヘッダーをサーバー、エッジワーカー、またはフレームワークミドルウェアにコピー。
よくある質問
- * と credentials を一緒に使える？
- いいえ。fetch 仕様は Access-Control-Allow-Origin: * と Access-Control-Allow-Credentials: true をペアにしたレスポンスを拒否する。credentials を落とすか、許可リストに対して検証した後で実際のリクエスト Origin をサーバーサイドでエコーする。
- なぜ Vary: Origin が推奨される？
- Origin を Allow-Origin にエコーすると、ダウンストリームのキャッシュは保存されたレスポンスをリクエストの Origin ヘッダーで変動させる必要がある；そうでなければ、あるサイトの CORS レスポンスを別のサイトのリクエストに提供してしまう可能性がある。Vary: Origin はキャッシュにそのヘッダーをキーにするよう伝える。
関連ツール
HTTP ヘッダリファレンス
標準 HTTP リクエスト・レスポンス・CORS・キャッシュ・セキュリティ・Cookie ヘッダ 約50個の検索可能リファレンス。
Referrer-Policy ヘッダービルダー
Referrer-Policy 値を選んで、送信リクエストが `Referer` ヘッダーに正確に何を送るかを見る — 同一オリジン、クロスオリジン HTTPS、HTTPS→HTTP ダウングレード。
Cache-Control ヘッダービルダー
ビジュアルチェックリストから HTTP Cache-Control ヘッダーを構築 — 鮮度、再検証、不変性、よく使うプリセット。
robots.txt テスター
robots.txt と（user-agent、パス）ペアのリストを貼り付け、どの行がそれぞれを許可またはブロックするかを正確に確認 — 最長一致優先、ワイルドカード、* グループフォールバック付き。
HTTP Basic 認証エンコーダ / デコーダ
`username:password` を Base64 `Authorization: Basic` ヘッダーにエンコード — または既存のヘッダーを貼り付けて誰がそこにいるかを見る。
URL クエリビルダー
ベースアドレスと編集可能なキー値クエリパラメータを組み合わせて URL を構築 — 各ペアを切り替え可能、適切に percent エンコード。