記事
更新日 2026年6月14日7 分で読めます

Cloudflare Pages と React サイトのセキュリティヘッダー

静的 React デプロイで一般的なブラウザ側リスクを下げるために、セキュリティヘッダー、canonical メタデータ、レスポンス検証をどう使うか。

要点

  • セキュリティヘッダーはコードコメントではなく、デプロイ設定として扱うべきです。
  • Cloudflare Pages は、リリース前にテストできる静的ヘッダールールをサポートします。
  • 明確な cross-origin 用途がない限り、公開静的レスポンスに対する wildcard CORS は広すぎることが多いです。

ベースラインとなるヘッダーセット

強化された React サイトでは、ブラウザの挙動を明示的に設定すべきです。正確なポリシーはアプリに依存しますが、通常は content type 保護、clickjacking 対策、referrer 制御、permissions policy、慎重に設計した content security policy を含みます。

静的ホストでは、ヘッダーがなくてもアプリが表示されるため、この作業が忘れられがちです。セキュリティは HTTP レスポンス層で検証する必要があります。

Cloudflare Pages での考慮点

  • 可能な限りヘッダールールをリポジトリ近くに置き、コードと一緒にレビューできるようにします。
  • ドキュメント化されていない dashboard のみの変更は、将来の監査が難しくなるため避けます。
  • www と apex の両方を配信している場合は、両方を確認します。
  • redirect によって最終レスポンスから重要なヘッダーが落ちていないか確認します。

CORS は意図を持って設定する

Access-Control-Allow-Origin: * は理由なくコピーされることがあります。通常の Web ページでは広い CORS は訪問者にほとんど利益を与えず、将来同じポリシー下に endpoint が追加された場合に偶発的なデータ露出を容易にする可能性があります。

自動化すべきこと

  • 静的ヘッダー設定で wildcard CORS を拒否するテスト。
  • sitemap と robots ファイルを公開する build ステップ。
  • 重要ページが render され、metadata が存在することを確認する preview チェック。
  • デプロイ後に production ドメインで live response を確認するチェック。

参考資料