Webセキュリティ HTTPヘッダチートシート

Webセキュリティのお話で頻出するレスポンスヘッダについてまとめてみました。

ないと問題がある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レスポンスヘッダの不必要な情報開示(Server_X-Powered-By)について

あった方がいいが、なくても問題ない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
CSP(Content Security Policy)を実際に動かして理解する

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)