セキュリティヘッダーを、壊さずに入れる順番

結論

Content-Security-Policy は Report-Only から始めます。強制モードで導入すると、想定していなかった読み込みが即座にブロックされ、原因の切り分けが難しい障害になります。

HSTS は、すべてのサブドメインがHTTPSで提供されていることを確認してから適用します。一度配信すると、ブラウザ側にしばらく記憶されるためです。

導入順序

影響範囲が小さく、確認が容易なものから入れます。

1. X-Content-Type-Options: nosniff

   影響が小さく、先に入れて問題になることはほとんどありません。

2. Referrer-Policy

   外部への参照元送信を制限します。計測への影響を先に確認します。

3. Permissions-Policy

   使っていない機能を明示的に無効化します。

4. CSP (Report-Only)

   違反レポートを収集し、実際の読み込み元を洗い出します。

5. CSP (強制)

   レポートが安定してから強制に切り替えます。

6. HSTS

   全サブドメインのHTTPS化を確認してから適用します。

確認は経路単位で行う

ヘッダーはサイト単位ではなく経路単位で確認します。CDNやエッジの設定変更で、特定の経路だけヘッダーが欠落することがあります。

AiventX Web Lab では、ヘッダー検証をフェーズ2の対象としています。静的ホスティングだけでは任意のレスポンスヘッダーを再現できないため、エッジ側の実装と組み合わせます。

このサイトの現状

フェーズ1の段階では、静的ホスティング上で構成しており、CSPを含むヘッダー群はまだ適用していません。適用状況は /security/ に記載しています。実態より進んだ状態を書かないようにしています。

状況セキュリティヘッダーの設定状況は、実際の配信設定が決まった段階で /security/ に反映します。