【入門編】セキュアなフロントエンド開発のためのセキュリティヘッダー一覧 – アプリケーションセキュリティ & 安全な開発防御ガイド

家のセキュリティは「玄関の鍵」だけじゃ足りない？Webサイトを守る「見えない盾」、HTTPセキュリティヘッダー入門

こんにちは。普段は企業の防御壁を構築したり、ときには攻撃者の思考をシミュレートしたりしているセキュリティエンジニアです。

皆さんは「Webサイトのセキュリティ」と聞くと、何を思い浮かべますか？おそらく多くの人が、ログイン画面のパスワードや、通信を暗号化するSSL/TLS（https://〜のあれです）を想像するはずです。

でも、泥棒は玄関の鍵が開いているかを確認するだけではありません。「窓ガラスを割る」「合鍵を作っておく」「住人のふりをして家に入り込む」といった、あの手この手で侵入を試みます。Webの世界における「インジェクション攻撃（特にXSS：クロスサイトスクリプティング）」も、まさにこれと同じです。

今回は、そんな悪意ある攻撃からWebサイトを多層的に守るための「HTTPセキュリティヘッダー」について、専門用語を極力噛み砕いて解説していきます。

—

HTTPヘッダーとは、Webブラウザとサーバーの間でやり取りされる「伝言メモ」のようなものです。例えば、あなたがWebサイトにアクセスすると、ブラウザは「このサイト、どんなルールで表示すればいい？」とサーバーに聞き、サーバーは「ここはこういうルールで表示してね」とヘッダーで返事をします。

この「ルール」の中に、「怪しいスクリプトは動かさないで」「他のサイトに埋め込まれないようにして」というセキュリティ命令を書き込んでおくのです。これがセキュリティヘッダーの正体です。

—

まずは、どんなWebサイトでも今日から導入すべき「3つの基本的な盾」を紹介します。

例えるなら：家の「入館許可リスト」

CSPは、サイト内で「どのスクリプトなら実行していいか」を細かく指定する最強の盾です。これを設定しておけば、万が一攻撃者がサイトに悪意あるコードを仕込んでも、ブラウザが「このコードは許可リストにないから実行しません！」と拒否してくれます。

すべてのコンテンツは自身のドメインからのみ許可し、外部からの実行は禁止する
Content-Security-Policy: default-src ‘self’; script-src ‘self’; object-src ‘none’;

例えるなら：家の「覗き穴（ドアスコープ）を塞ぐ」

攻撃者は、あなたのサイトを透明なフレームに入れて、別の悪意あるサイトの上に重ねて表示させることがあります。これを「クリックジャッキング」と呼びます。ユーザーが気づかないうちにボタンを押させられてしまう手口です。これを防ぐのがこのヘッダーです。

他のサイトのiframe内での表示を一切許可しない
X-Frame-Options: DENY

例えるなら：「家を出る時の行き先を他人に教えない」

Webサイトを移動する際、ブラウザは「どこから来たか（リファラー）」という情報を次のサイトに伝えます。このURLに機密情報（例：password-reset?token=12345）が含まれていると、外部に漏れてしまいます。これを制御します。

自分のドメイン以外には、ページ情報を一切教えない
Referrer-Policy: strict-origin-when-cross-origin

—

セキュリティを高めると、サイトの一部が動かなくなることがあります。「あれ、Googleマップが表示されない！」といった事態です。

防御は「最初は緩く、徐々に厳しく」が鉄則です。
まずはCSPを「報告モード（Content-Security-Policy-Report-Only）」で設定し、どの機能がブロックされるかをログで確認してから、徐々にルールを厳格化していくのが、現場で失敗しないコツです。

—

セキュリティの世界では、「100%の防御は不可能」と言われます。しかし、今回紹介したようなヘッダーを適切に設定するだけで、攻撃者にとってあなたのサイトは「攻略に時間のかかる面倒なターゲット」になります。

泥棒は、鍵の硬い家よりも、窓が開いている家を狙います。セキュリティヘッダーは、まさにその「窓」をしっかり閉めて回る行為です。

まずは開発環境で設定を一つずつ試してみてください。一歩ずつ、着実に。そうすれば、あなたの書くコードは今よりもずっと強固なものになっているはずです。

何か分からないことがあれば、いつでも相談してくださいね。一緒に守りを固めていきましょう！