セキュリティヘッダとは
Web サーバーは HTML のほか、 HTTP ヘッダでブラウザへの指示を返します。 そのうちセキュリティ関連のものを、まとめてセキュリティヘッダと呼ぶことがあります。 WAF や CDN の管理画面で設定することも多いですが、 攻撃面レビューでは外部から HTTPS で取れる応答を事実として記録します。
「すべて入っていれば安全」ではなく、 入っていないこと自体が運用上の手がかり（設定漏れ・移行途中・ホストごとの差）として報告書に載せる、という位置づけです。
よく報告書に載るヘッダ（例）
| ヘッダ | ざっくりした意味 |
|---|---|
Strict-Transport-Security（HSTS） |
以降のアクセスを HTTPS に固定し、平文 HTTP への降下を抑止 |
Content-Security-Policy（CSP） |
読み込めるスクリプト・画像の出所を制限（XSS 対策の補助） |
X-Frame-Options / frame-ancestors |
他サイトへの埋め込み（クリックジャッキング）を抑止 |
X-Content-Type-Options |
MIME タイプの sniffing を抑止 |
Referrer-Policy |
リンク先に渡す参照元 URL の量を制御 |
実際のご依頼では代表 URL・生存ホストごとに有無と値の概要を整理します。 詳細な CSP 設計や WAF ルール作成は標準スコープ外です。
HSTS 未設定の例（サンプル F-13）
架空の報告書サンプルでは、
auth.example.co.jp の HTTPS 応答に
Strict-Transport-Security が無いとして
重要度中の所見（F-13）を挙げています。
同ホストは管理系 UI の痕跡もあり（F-10）、 「TLS は有効だが HSTS が無い管理系 URL」という組み合わせは、 公開されている管理画面の文脈とあわせて読むと整理しやすい典型です。
鍵マークは出ているが、平文 HTTP に誘導される隙をヘッダで塞いでいない可能性がある、 という点を事実として共有します（中間者攻撃の全般論ではなく、設定の有無の記録が目的）。
well-known との関係（参考）
セキュリティヘッダとは別枠ですが、
/.well-known/security.txt（RFC 9116）が応答するかも
公開情報調査の項目の一つです。
サンプル F-24 では HTTP 200 で応答する例を情報所見として載せ、
Contact / Expires の記載を促しています。
「脆弱」というより、連絡先・有効期限の明示が外部から読めるか、 という運用の事実整理です。
社内 WAF・CDN 設定との境界
ヘッダは CDN・リバースプロキシ・オリジンサーバのどこで付与されているか、 社内だけでは分かりにくいことがあります。 攻撃面レビューはインターネット上の利用者と同じ経路で取った応答を記録します。 管理画面へのログインやルール変更の代行は含みません。
含まないこと（よくある誤解）
- CSP / HSTS の設計・適用代行、CDN 設定変更
- XSS 等の脆弱性 exploit による実証（ペンテストは別契約）
- 社内のみで見える管理用ヘッダ・非公開 URL
- 無許可資産へのスキャン
調査データは閉域環境内で扱います
調査結果の記録は当社事業所内の閉域環境でのみ保管・処理します。 公開 HTTPS への接続確認は発生しますが、 御社データを当社クラウドや第三者 SaaS に載せる運用は行いません。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。