こんにちは！新人のIT担当者や、これからWeb開発やセキュリティの勉強を始めるという方、日々の業務お疲れ様です。
「セキュリティ」と聞くと、なんだか複雑な暗号や難解な数式が出てきて身構えてしまいますよね。でも、安心してください。私たちがWebサイトを守るための技術も、突き詰めていけば「身の回りの防犯」と同じ原理なんですよ。
今日は、Webアプリを作る上で絶対に欠かせない「セキュリティヘッダー」の中から、X-Content-Type-Options と X-Frame-Options という2つの強力な「おまじない（設定）」について、分かりやすく紐解いていきたいと思います。一歩ずつ、丁寧にいってみましょう！
—
1. 家の鍵と一緒？ セキュリティヘッダーって何だろう
皆さんは、お出かけするときに玄関の鍵を閉めますよね。さらに、窓の鍵を閉めたり、郵便受けにチラシが溜まらないように工夫したりするはずです。
Webの世界でも全く同じことが言えます。私たちが作ったWebサイト（お家）をインターネットという広大な世界に公開するとき、ブラウザ（お客さんが使う玄関）に対して「ここはこういうルールで安全に出入りしてね！」と指示を出す必要があります。
この指示をサーバーからブラウザへこっそり伝える伝言メモのような役割をするのが、「セキュリティヘッダー」です。
今回は、数ある防犯対策の中でも「勝手に変な中身に勘違いさせない（MIMEタイプスニッフィング対策）」と「勝手に透明な板で隠し撮りされない（クリックジャッキング対策）」の2つに絞って、泥棒の手口と合わせて見ていきましょう！
—
2. 泥棒の手口と「X-Content-Type-Options」の深い関係
おせっかいすぎるブラウザの落とし穴
まずは X-Content-Type-Options からです。
想像してみてください。あなたが友人に「これ、ただのきれいな風景写真のデータだよ」と言って、1枚の画像ファイルを渡したとします。ところが、受け取った友人が「うーん、これ裏側になにか別のプログラムが隠されている気がするな……よし、勝手にプログラムとして動かしてみよう！」と、勝手に解釈して実行してしまったらどうでしょう？ ちょっと怖くないですか？
実は、昔のWebブラウザは「おせっかいで親切すぎる」ところがありました。サーバーが「これはただの画像ファイル（テキストファイル）です」と言っているにもかかわらず、ブラウザが勝手に「いやいや、中身をよく見たらこれ動かせるプログラムっぽいから、実行しちゃえ！」と勝手な判断（これを MIMEタイプスニッフィング と呼びます）をしてしまうことがあったのです。
攻撃者はこの「ブラウザのおせっかい」を悪用します。例えば、掲示板の画像アップロード機能に、本当は悪意あるプログラムであるファイル（evil.png だと言い張る中身がスクリプトのファイル）をこっそり紛れ込ませます。そして、閲覧者がその画像を開いた瞬間、ブラウザが勝手に「おっ、これプログラムじゃん！」と勘違いして実行し、閲覧者のパソコンを乗っ取ってしまう……なんていう恐ろしいことが起きていたのです。
「余計な気を利かせないで！」と釘を刺す設定
このおせっかいをピタッと止めてくれるのが、X-Content-Type-Options ヘッダーです。
サーバーからブラウザに対して、「サーバーが言ったファイルの種類をそのまま信じろ！ 勝手に中身を推測して実行するな！」 と厳しく言い聞かせるための設定になります。
実際のWebサーバー（例えばNginxやApache、あるいはPHPなどのアプリケーション）では、以下のように設定します。
# サーバーからブラウザへ送るレスポンスヘッダーの例
X-Content-Type-Options: nosniffたったこれだけです！ nosniff（推測するな、嗅ぎ取るな）という言葉を指定するだけで、「サーバーの言うことを絶対に従う」という強いルールをブラウザに強制できます。新人の皆さんがWebサーバーを構築する際は、まず最初に設定すべき必須の防犯ロックの一つですよ。
—
3. 透明な重ね合わせの罠？ 「X-Frame-Options」でクリックジャッキングを防ぐ
「クリックジャッキング」ってどんな手口？
次に、X-Frame-Options について見ていきましょう。こちらは クリックジャッキング（Clickjacking） という、心理的・視覚的な罠を使った攻撃を防ぐためのものです。
ジャッキング（ハイジャックなどと同じ言葉ですね）とは、「乗っ取り」を意味します。
想像してみてください。悪意ある攻撃者が、自分の作った適当な無料ゲームのサイトに、本物の銀行やSNSのログイン画面を「透明なガラスの板（iframe）」のように重ねて表示させたとします。
ユーザーの目には、ゲームの「今すぐプレゼントをもらう！」という魅力的なボタンが見えています。ユーザーがそのボタンをルンルン気分でクリックした瞬間……！
実はその下には、目に見えないように透明化された、本物の銀行の「送金を実行するボタン」がぴったり重なっていたのです。
ユーザーはゲームのボタンを押したつもりが、実際には銀行口座から勝手にお金を振り込むボタンを押されてしまっていた――これがクリックジャッキングの恐ろしい手口です。
「うちのサイトを勝手に額縁に入れるな！」と拒絶する設定
Webサイトの世界では、他のサイトのページを自分のページの中に枠（フレーム：iframeなど）として埋め込む技術があります。便利な機能ですが、これが悪用されると先ほどのようになります。
そこで登場するのが X-Frame-Options です。これは、「うちのWebページを、よその悪意あるサイトの枠組み（iframe）の中に勝手に映し出すことを禁止します！」 という宣言になります。
設定には主に2つのパターンがあります。
# パターン1: どこからも絶対にフレーム埋め込みを許可しない（一番安全でオススメ）
X-Frame-Options: DENY
# パターン2: 自社ドメインの中だけであれば、フレーム埋め込みを許可する
X-Frame-Options: SAMEORIGIN例えば、自社のサービスを外部のパートナーサイト等で絶対にiframe表示させる必要がないのであれば、問答無用で DENY を設定するのが最も堅実な防犯対策になります。
—
4. 実務でどう書く？ ApacheやNginx、PHPでの実装例
理論が分かったところで、現場でどのようにこのヘッダーを実装するのか、具体的なコード例を見てみましょう。インフラエンジニアやバックエンドエンジニアと連携する際にも役立つ知識です。
パターンA: Apacheサーバーの設定 (.htaccess や設定ファイル)
もしお使いの環境がApacheであれば、プロジェクトのルートディレクトリにある .htaccess ファイルに次のように書き加えることができます。
<IfModule mod_headers.c>
# ブラウザに勝手なファイル解釈をさせない
Header set X-Content-Type-Options "nosniff"
# 自社サイト以外のiframe埋め込みを完全に禁止する
Header set X-Frame-Options "DENY"
</IfModule>*(※ mod_headers モジュールが有効になっている必要があります)*
パターンB: Nginxサーバーの設定 (nginx.conf)
高負荷なWebサイトでよく使われるNginxの場合は、サーバーブロック（server や location）の中に次のように記述します。
server {
# その他の設定...
# セキュリティヘッダーの付与
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
}*(※ always をつけることで、エラーレスポンス時であっても確実にヘッダーが付与されるようになり、セキュリティの堅牢性がさらに増します)*
パターンC: PHPプログラム側で動的に出力する場合
フレームワークを使わず、プレーンなPHPでヘッダーを出力したい場合は、HTMLを出力するよりも前に header() 関数を実行します。
<?php
// 必ずHTMLの出力（echoやスペースなど）よりも手前で実行してください
header("X-Content-Type-Options: nosniff");
header("X-Frame-Options: DENY");
// この後に通常のHTMLや処理が続く
?>
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>安全なWebページ</title>
</head>
<body>
<h1>こんにちは、セキュリティヘッダーの設定完了です！</h1>
</body>
</html>—
5. おわりに：最初の一歩を踏み出したあなたへ
いかがでしたでしょうか？
X-Content-Type-Options も X-Frame-Options も、コードの行数で言えばほんの数行、設定するパラメータも非常にシンプルなものです。
しかし、この数行の記述を忘れてしまうだけで、ブラウザの親切心やWebの便利な仕組みがそのままセキュリティの「ほころび」となり、ユーザーを危険に晒してしまうことになります。
セキュリティ対策とは、何も難解なプログラミングばかりではありません。こうした「ブラウザとサーバーの間のルールを正しく整えること」も、立派で最高に価値のあるエンジニアの仕事です。
「難しそう」と怖がらずに、ぜひご自身の開発環境やテストサーバーで、これらのヘッダーが正しく返されているか（ブラウザの開発者ツール等の「ネットワークタブ」で確認できますよ！）をチェックしてみてくださいね。
一歩ずつ、確実に安全なWebの世界を作っていきましょう！応援しています！
コメント