TURNING POINT 
Webセキュリティのお話で頻出するレスポンスヘッダについてまとめてみました。
Contents
ないと問題があるHTTPヘッダ
X-Content-Type-Options
ブラウザがContent-Typeを無視してコンテンツの中身から実行形式を判断することを禁止する。基本的にはどんな場合でもつける。
X-Content-Type-Options: nosniff
Content-TypeとX-Content-Type-Optionsについて
X-Frame-Options
iframeなどでの表示を禁止することでクリックジャッキングを防ぐ。基本的にはどんな場合でもつける。
X-Frame-Options: DENY (もしくはSAMEORIGIN)
iframeを禁止する方法
Strict-Transport-Security
HTTPSを使っている場合、リダイレクト処理だとHTTPのリクエストの度にデータが平文で流れる為、HTTPSをブラウザ側で強制できるHSTSは使った方がいい。
Strict-Transport-Security: max-age=15768000; includeSubDomains
HSTSとリダイレクトの違い
Cache-Control
別人問題などを引き起こしかねないので、基本的にはキャッシュしない設定にする。キャッシュを活用するタイミングで個別のキャッシュを考えればよい。
Cache-Control: private, no-store, no-cache, must-revalidate
Pragma: no-cache
キャッシュされたくない場合のHTTPヘッダのベストプラクティス
あると問題があるHTTPヘッダ
Server
Webサーバのバージョン情報が攻撃の足掛かりになる可能性がある為、基本的にはバージョン情報はレスポンスしない。
Server: Apache/2.4.48 (Debian)Server: Apache
HTTPレスポンスヘッダの不必要な情報開示(Server_X-Powered-By)について
X-Powered-By
PHP等の言語のバージョン情報は、攻撃への糸口になる可能性が十分に考えられるので、レスポンスしない。
X-Powered-By: PHP/8.0.11ヘッダが存在しないことあった方がいいが、なくても問題ないHTTPヘッダ
Content-Security-Policy
XSSに対して有効な防御策である為あった方がいいのは確かだが、CSPを考慮して開発を行うのは簡単とは言えない為、なくても問題はない（システム的にXSSが入り込まない開発をすればそれでいい）。
Content-Security-Policy: default-src 'self'
CSP(Content Security Policy)を実際に動かして理解する
X-XSS-Protection
意見が分かれそうだが、一応IPAのサイトで有効にすることを推奨しているのであった方がいい。だけど、個人的にはもうなくてもいいと思う。
X-XSS-Protection: 1; mode=block