たった1行でサイトを守る？「HTTPヘッダー」で始めるWebセキュリティ
はじめに
SQLインジェクションやクロスサイトスクリプティング（XSS）など、Webを取り巻く脅威は多く、どこから手をつけていいか頭を悩ませることも少なくありません。
そうした中、解説サイトなどでよく目にするのが「設定ファイルに指定のコードを追加する」という、いわゆるセキュリティヘッダーの設定です。
私自身、開発の現場でセキュリティ対策を組み込む際、まずは見よう見まねで X-Frame-Options: DENY といったヘッダーを追加していった経験があります。指示通りに1行追加するだけで対策が完了するため非常に手軽ですが、同時にこうも思いました。
「なぜ、『呪文』のような短い文字列を追加するだけで、Webサイトの安全性を高めることができるんだろう？」
そこで今回は、この手軽で強力な「セキュリティヘッダー」がなぜWebサイトを守ることができるのか、その根本的な仕組みについて、興味をもった次第です。
「設定はしたことがあるけれど、実は裏側の仕組みまでは意識していなかった」という方も多いのではないでしょうか。
この記事は、シリーズを重ねてセキュリティヘッダーについて一緒に勉強していく内容を目指していきます。
そもそもHTTPヘッダー、ひいてはHTTPとはなんなんだろう
HTTPヘッダーセキュリティを語る前に、そもそもHTTPとは何なのか？という大前提を整理しておこうと思います。HTTPを一言で表すと、ブラウザとサーバーの間でやりとりされる「お願い」と「返事」の仕組みです。
```
ブラウザ ──「このページちょうだい」（お願い）──▶ サーバー
ブラウザ ◀──「はい、HTMLです」（返事）──── サーバー
```
私たちが普段アドレスバーに URLを入力して、Enterを押すと裏側ではこのやりとりが行われています。
専門用語ではお願いを「リクエスト」、返事を「レスポンス」と呼びますが、まずは「お願いと返事」というイメージで十分です。
そして今回の主役であるHTTPヘッダーは、このお願いと返事のそれぞれに添えられている**付箋のようなもの**だと考えてください。
「ちなみに私はこういう者です」
「こういう形式で返してください」
「これはHTMLです」
といった補足情報がヘッダーに書かれています。
※もう少し専門的に知りたい方はぜひMDNを参考にしてみてください！
HTTPについてはこちら・・
HTTPヘッダーについてはこちら・・
実際にHTTPの中身を覗いてみる
ここまでは概念の話でした。
百聞は一見にしかずということで、実際にHTTPヘッダーを覗いてみましょう。
実は、HTTPの中身を見るのに特別なツールは必要ありません。
皆さんが普段使っているブラウザに、すでに専用の機能が備わっています。
開発者ツールを開いてみる
ブラウザで何か適当なサイトを開いた状態で、キーボードの `F12` キーを押してみてください。
画面の一部に、何やら難しそうな画面が現れます。これが開発者ツールです。
その中にある 「Network」タブ を選んで、画面を更新（F5）してみると――
ブラウザがサーバーとやりとりしているHTTPの中身が、リアルタイムで見えてきます。
とあるサイトを覗いてみると……
読み解いてみる
まずは「お願い」のほう、Request Headers から見てみましょう。
ヘッダー
意訳
:method: GET
ください（取得）
:path: /
トップページを
:authority
このドメインから
User-Agent
私はこういうブラウザです
Accept-Language: ja,en-US;...
日本語が第一希望、次に英語
ブラウザは、自分が何者なのか・何が欲しいのかを、ヘッダーという付箋でちゃんと自己紹介しながらお願いしているんですね。
次に「返事」のほう、Response Headers を見てみます。
ヘッダー
意訳
Content-Type: text/html; charset=UTF-8
お返事はUTF-8のHTMLです
Cache-Control: private, no-cache, ...
キャッシュの扱いは●●してね
Date: Fri, 29 May 2026 10:22:37 GMT
送った時刻
Content-Encoding: br
Brotli圧縮してます
ここまでは「情報の付箋」というイメージ通りですね。
ところが、その中にこんなヘッダーが混ざっています。
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
Permissions-Policy: unload=()
Referrer-Policy: strict-origin-when-cross-origin
これらのヘッダーを読み解いてみましょう
ヘッダー
サーバーが言っていること
X-Content-Type-Options: nosniff
Content-Typeを勝手に推測するな
X-Frame-Options: SAMEORIGIN
同じドメインのページからしか iframe で埋め込むな
X-Xss-Protection: 1; mode=block
XSSを検出したらページをブロックしろ
Permissions-Policy: unload=()
unload系のブラウザ機能を使うな
Referrer-Policy: strict-origin-when-cross-origin
他サイトに飛ぶときはリファラを慎重に送れ
今までの内容と少し毛色が違いそうです。
今までは返した内容の「情報」だったのに、「指示」のような内容になっていますね。
そう、これがいわゆる、セキュリティヘッダーです。
よく目にする他のセキュリティヘッダーも、併せて紹介しておきます。
よく見るセキュリティヘッダー
サーバーが言っていること
Strict-Transport-Security: max-age=31536000
今後1年間、HTTPSでしかアクセスするな
Content-Security-Policy: ...
読み込めるリソースはここで指定したものだけ
Access-Control-Allow-Origin: ...
ここからのアクセスは許可する
そう、セキュリティヘッダーはブラウザに指示しているんですね。
呪文の正体は「指示書」だった
ここで、冒頭の問いに戻りたいと思います。
> なぜ、このような『呪文』のような短い文字列を追加するだけで、Webサイトの安全性を高めることができるのだろうか？
開発者ツールで実際にHTTPの中身を覗いてみたことで、その答えが見えてきました。
セキュリティヘッダーの正体は、 サーバーからブラウザへの「指示書」
サーバーが「こうしてくれ」「これはやめてくれ」と書いた付箋を返事に添えると、ブラウザはそれを読んで、素直に従ってくれる。
- 「HTTPSでしかアクセスするな」と書かれていれば、ブラウザは次からHTTPSでアクセスする
- 「iframe で埋め込むな」と書かれていれば、ブラウザは埋め込みを拒否する
- 「Content-Typeを推測するな」と書かれていれば、ブラウザは推測をやめる
たった1行の指示書で、ブラウザの挙動を変えられる。
だからこそ、たった1行追加するだけでWebサイトの安全性が高まるんですね。
セキュリティヘッダーが「呪文」に見えていたのは、それが指示書であるという大前提を知らなかったからでした。
まとめ
今回の内容を振り返ります。
- HTTPはブラウザとサーバーの「お願い」と「返事」のやりとり
- それぞれにヘッダーという付箋がついている
- ヘッダーは情報の補足だけでなく、指示書としても機能する
- ブラウザはサーバーが出した指示書に素直に従う
- だからこそ、ヘッダー1行でWebセキュリティを制御できる
さらに踏み込みたい方へ：コマンドラインのすすめ
開発者ツールでHTTPの中身を覗くのに慣れてきたら、次はコマンドラインから直接HTTPを叩いてみるのもおすすめ
です。
代表的なのが `curl`（カール）というコマンドです。
ターミナルで次のように打つだけで、ブラウザを介さずに生のHTTP通信が見られます。
curl -v https://www.example.comWindowsユーザーへのちょっとした注意
PowerShellで `curl` と打っても、実は本物のcurlは動きません。
PowerShellでは `curl` が `Invoke-WebRequest` という別コマンドのエイリアスになっており、出力が整形されてしまうので、生のHTTPが見えにくなります。
WSL（Windows Subsystem for Linux） を使うのがおすすめです
次回予告
さて、ここまで「指示書」によってブラウザに追加で命令する話を見てきました。
ここで一つ疑問がわきました。ブラウザは指示書がないとこういったセキュリティ対策はとってくれないのか？
でも調べていくと、どうもそうではないようです。
ブラウザは指示書がなくても、デフォルトで一定の守りを持っているとのこと。
次回はそのデフォルトの守り、「Same-Origin Policy」を見ていきたいと思います。
それを知ると、指示書（セキュリティヘッダー）の役割がもっとはっきり見えてきます。