本稿は、2026 年 2 月 23 日に公開された “Adding HTTP security headers using Amazon CloudFront” を翻訳したものです。
この投稿は、複雑な実装を行うことなくアプリケーションのセキュリティ水準を強化したいと考えている Web デベロッパー、DevOps エンジニア、およびセキュリティプロフェッショナルを対象として書かれています。HTTP セキュリティヘッダーは、クロスサイトスクリプティング(XSS)、クリックジャッキング、中間者攻撃といった一般的な Web 脆弱性からユーザーを保護することができる、重要でありながらも見落とされがちな防御レイヤーです。これらのヘッダーは、閲覧者とコンテンツプロバイダーの双方のセキュリティとプライバシーを向上させることを目的とした、特定のレスポンスヘッダー群を追加することで実装されます。この投稿では、Web サイトおよび Web アプリケーションのオーナーが、Amazon CloudFront を使用してこれらのヘッダーの実装を効率化する方法について説明します。
これらのヘッダーをサーバーではなく CloudFront で追加することには、複数のメリットがあります。
- オリジンサーバーのコードを変更できない場合
- オリジンサーバー上のアプリケーションは、リクエストされたコンテンツの提供に専念でき、ヘッダーの追加処理にリソースを割くことが不要
- ヘッダー追加の処理を CloudFront に委ねることで、CloudFront とオリジンサーバー間の帯域幅を節約でき、サーバーの負荷も軽減
- オリジンサーバーで直接変更する場合と比べて、CloudFront でセキュリティヘッダーを柔軟に変更可能
セキュリティヘッダーとは何ですか?
セキュリティヘッダーとは、サーバーからの HTTP レスポンスに含まれるヘッダーの集合であり、ブラウザがサイトのコンテンツを処理する際の動作を理解するのに役立ちます。例えば、X-XSS-Protection は、XSS 攻撃を検知した際にページの読み込みを停止するよう Internet Explorer および Chrome ブラウザが従うヘッダーです。以下は、CloudFront を使用してレスポンスに追加する各ヘッダーの一覧です。
これらのヘッダーの詳細については、Mozilla の Web セキュリティガイドをご参照ください。
HTTP セキュリティヘッダーは、Web アプリケーションを一般的な脆弱性から保護するのに役立ちます。以下のシナリオでは、CloudFront を使用してこれらのヘッダーを実装し、Web サイトのセキュリティを強化する方法を紹介します。
- あるオンライン小売業者が、チェックアウトプロセスのセキュリティを強化したいと考えているとします。この業者は、悪意のある第三者が他の Web サイトの iframe にチェックアウトページを埋め込もうとするクリックジャッキング攻撃を懸念しているかもしれません。この業者は、CloudFront を使用して
X-Frame-Options や Content-Security-Policy などの HTTP セキュリティヘッダーを実装することで、自社のページが不正なサイトに表示されるのを防ぐことができます。このアプローチにより、オリジンサーバーへの変更を必要とせずに顧客保護を強化できるため、サードパーティの EC プラットフォームを利用している企業にとって特に有効です。
- 次に、規制遵守とデータ保護のために患者ポータルのセキュリティを強化したいと考えている医療機関を想定してみましょう。この機関は、CloudFront を使用して、HTTPS 接続を強制するための
Strict-Transport-Security(HSTS)や、不正なデータアクセスを防ぐための Content-Security-Policy などのセキュリティヘッダーを実装することができます。CloudFront を活用することで、各バックエンドアプリケーションを変更することなく、複数のサブドメインにわたってこれらのセキュリティ対策を適用できます。このアプローチは、患者データの保護を強化しながら、セキュリティ監査の結果を改善するのに役立つ可能性があります。
この記事では、CloudFront レスポンスヘッダーポリシー、CloudFront Functions、および Lambda@Edge を使用して、CloudFront でセキュリティヘッダーを実装する 3 つの方法を紹介します。
まず、CloudFront レスポンスヘッダーポリシーについて見ていきましょう。
CloudFront レスポンスヘッダーポリシー
CloudFront レスポンスヘッダーポリシーは、CloudFront が実行するヘッダーの変更を定義する際に、より細かい制御を可能にします。CloudFront レスポンスヘッダーポリシーを使用することで、カスタムコーディングや追加コストをかけずに、レスポンスがクライアントに送信される直前にヘッダーを直接追加することができます。
CloudFront レスポンスヘッダーポリシーは、マネージドポリシーまたはカスタムポリシーを使用して設定することができます。マネージドポリシーには、一般的なユースケース向けに Amazon Web Services (AWS) が管理する定義済みの HTTP レスポンスヘッダーのセットが含まれており、カスタムポリシーではヘッダーの値を細かく調整することができます。カスタムレスポンスヘッダーポリシーを作成する前に、マネージドレスポンスヘッダーポリシーのいずれかがご自身のユースケースに適合するかどうかを確認することをお勧めします。適合するものがあれば、それをキャッシュビヘイビアにアタッチすることができます。これにより、独自のレスポンスヘッダーポリシーを作成・管理する必要がなくなります。このセクションでは、CloudFront レスポンスヘッダーポリシーを使用して HTTP セキュリティヘッダーを追加する方法を説明します。
CloudFront レスポンスヘッダーポリシーのメニューにアクセスするには、CloudFront コンソールに移動し、左側のナビゲーションメニューから「ポリシー」を選択します。図 1 に示すように、「レスポンスヘッダー」を選択します。
図 1:CloudFront レスポンスヘッダーポリシー
この画面では、マネージドポリシーのセクションに既に SecurityHeadersPolicy が事前定義されています。図 2 に示すように、ポリシー名を選択することでポリシーの詳細を確認することができます。
図 2:マネージド SecurityHeaders ポリシーを表示している CloudFront レスポンスヘッダーポリシー
このマネージドポリシーには、一般的なセキュリティヘッダーと値の定義済みセットが含まれています。定義済みのレスポンスヘッダーと値がご自身のユースケースに適合する場合は、このポリシーを CloudFront キャッシュビヘイビアにアタッチすることで、CloudFront が提供するレスポンスにこれらのヘッダーを追加することができます。マネージドレスポンスヘッダーポリシーを使用することで、独自のポリシーを作成・管理する必要がなくなります。
セキュリティヘッダーの設定を変更したり、他の目的でレスポンスヘッダーをさらに変更する必要がある場合は、他のマネージドポリシーが要件を満たしているかどうかを確認してください。どのマネージドポリシーもユースケースに適合しない場合は、図 1 に示すように右下の「レスポンスヘッダーポリシーを作成」ボタンをクリックしてカスタムレスポンスヘッダーポリシーを作成し、ポリシーの名前と説明を入力してください。図 3 に示すように、必要に応じて適切なセキュリティヘッダーを選択してください。
図 3:レスポンスヘッダーポリシーの作成
レスポンスヘッダーポリシーの設定が完了したら、このポリシーを使用する CloudFront ディストリビューションに移動し、図 4 に示すように該当するビヘイビアの「編集」を選択します。
図 4:レスポンスヘッダーポリシーを有効にするビヘイビアの選択
次の画面で、図 5 に示すように「レスポンスヘッダーポリシー」セクションが見つかるまで画面下部にスクロールします。前の手順で作成したマネージドセキュリティヘッダーポリシーまたはカスタムポリシーを選択し、画面下部の「Save changes」を選択します。
図 5:レスポンスヘッダーポリシーセクションへの SecurityHeaderPolicy の追加
新しい変更がデプロイされると、Web サイトを閲覧した際にレスポンスヘッダーにセキュリティヘッダーが表示されるようになります。
https://www.example.com/
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/html; charset=UTF-8
Date: Fri, 23 Aug 2024 03:12:49 GMT
ETag: W/"773-6027e43eccd62"
Last-Modified: Wed, 09 Aug 2023 14:26:28 GMT
Referrer-Policy: strict-origin-when-cross-origin
Server: Apache/2.4.58 (Amazon Linux)
Strict-Transport-Security:max-age=31536000
Transfer-Encoding: chunked
Via: 1.1 ec09137e1a146c0a7d4ba39d013ba29c.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: ATL58-P3
X-Cache: Miss from cloudfront
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
content-encoding: gzip
vary: accept-encoding
これで、CloudFront レスポンスヘッダーポリシーを使用して、Web サイトにセキュリティヘッダーを問題なく設定することができました。
エッジ関数を使用したセキュリティヘッダーの追加
特定のリクエストヘッダーや Cookie が存在する場合、またはクエリ文字列に特定の値が含まれる場合など、特定の条件下でのみセキュリティヘッダーの値を動的に追加または変更する必要がある場合は、CloudFront Functions または Lambda@Edge を使用したエッジでのカスタム関数を利用することができます。CloudFront Functions と Lambda@Edge の違いおよび推奨されるユースケースについては、このデベロッパーガイドをご覧ください。
CloudFront Functions は、CloudFront エッジロケーションで軽量な JavaScript 関数をデプロイして実行するための機能です。CloudFront Functions を使用してセキュリティヘッダーを追加するには、図 6 に示すように CloudFront コンソールで「関数の作成」を選択して関数を作成する必要があります。
図 6:新しい CloudFront Functions の作成
図 7 に示すように、関数の名前と説明を入力し、ランタイムを選択します。
図 7:関数の名前と説明を入力し、ランタイムを選択する
セキュリティヘッダーを追加するサンプルコードは、aws-samples の GitHub リポジトリで見つけることができます。本番環境にデプロイする前に、関数をテストしてください。
関数のデプロイには数秒かかります。デプロイが完了したら、関数の関連付け手順に従ってください。これで、CloudFront Functions を使用してセキュリティヘッダーを設定することができました。
Lambda@Edge の使用
状況によっては、CloudFront FunctionsよりもLambda@Edgeの方が適している場合があります。例えば、ビューワーレスポンストリガーにおける別の要件の実装で、Lambda@Edge でのみ利用可能な機能が必要になる場合があります。これには、ネットワーク呼び出し、サードパーティライブラリ、リクエストボディへのアクセスなどが含まれ、CloudFront Functions の使用が制限される可能性があります。
Lambda@Edge 関数を CloudFront に追加するには、このガイドの手順に従ってください。また、Lambda@Edge 関数は Node.js または Python を使用して記述することができます。
以下の Node.js で記述されたサンプルコードは、Lambda@Edge を使用してレスポンスに Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、X-XSS-Protection、および Referrer-Policy などのセキュリティヘッダーを追加する方法を示しています。
export const handler = async (event) => {
// Get contents of response
const response = event.Records[0].cf.response;
const headers = response.headers;
// Set new headers
headers['strict-transport-security'] = [{key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubdomains; preload'}];
headers['content-security-policy'] = [{key: 'Content-Security-Policy', value: "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"}];
headers['x-content-type-options'] = [{key: 'X-Content-Type-Options', value: 'nosniff'}];
headers['x-frame-options'] = [{key: 'X-Frame-Options', value: 'DENY'}];
headers['x-xss-protection'] = [{key: 'X-XSS-Protection', value: '1; mode=block'}];
headers['referrer-policy'] = [{key: 'Referrer-Policy', value: 'same-origin'}];
return response;
};
セキュリティヘッダーによるセキュリティ強化の効果を検証する
セキュリティヘッダーを追加する前後に Mozilla Observatory を使用することができます。図 8、9、10、11 に示すように、セキュリティヘッダーを追加した後はスキャンの評価が向上します。
セキュリティヘッダー追加前
図 8:セキュリティヘッダー追加前の Mozilla Observatory の評価
図 9:セキュリティヘッダー追加前の Mozilla Observatory のテストスコア
また、図 10 と図 11 はセキュリティヘッダー追加後の結果を示しています。
図 10:セキュリティヘッダー追加後の Mozilla Observatory の評価
図 11:セキュリティヘッダー追加後の Mozilla Observatory のテストスコア
クリーンアップ
この記事の手順に従うことで、レスポンスヘッダーポリシー、CloudFront Functions、Lambda@Edge 関数、および CloudFront ディストリビューションを作成した可能性があります。これらのリソースが不要になった場合は、必ず削除するようにしてください。
まとめ
この記事では、HTTP セキュリティヘッダーとは何か、そして CloudFront レスポンスヘッダーポリシー、CloudFront Functions、および Lambda@Edge を使用してこれらのヘッダーを追加する方法について説明しました。この記事で説明したプロセスに従い、ユースケースに適した方法を選択することで、Web サイトのプライバシーとセキュリティを強化することができます。まず Content-Security-Policy、X-Frame-Options、Strict-Transport-Security などの基本的なヘッダーから始め、アプリケーションの具体的なニーズに応じて段階的に保護を強化していきましょう。開発環境で十分にテストを行い、デプロイ後は互換性の問題が発生していないか監視することを忘れないようにしてください。
セキュリティは継続的なプロセスです。定期的にヘッダーを監査し、新しいセキュリティに関する推奨事項を常に把握しながら、アプリケーションの進化に合わせてポリシーを適宜見直していきましょう。
この記事に記載されているリンクから、上記の機能に関する詳細情報を確認することができます。CloudFront を初めて使用する場合は、こちらのリンクから CloudFront の詳細を確認し、使い始めることができます。
著者について

Karthic Chinnannasamy
Karthic Chinnannasamy は AWS のシニアエッジスペシャリストソリューションアーキテクトであり、重要な Web インフラストラクチャとセキュリティソリューションの設計においてお客様をサポートしています。境界防御と Web 高速化の専門知識を活かし、大手小売業者がセキュアで堅牢かつコスト効率の高い Web アーキテクチャを構築できるよう支援しています。

Jason Bradley
Jason Bradley は、ナッシュビルを拠点とする AWS のシニアソリューションアーキテクトで、高等教育を専門としています。お客様が AWS 上でアプリケーションを効果的に設計・構築できるよう支援しています。Jason は IT および高等教育分野で 20 年以上の経験を持ち、読書や映画鑑賞、そして息子との時間を大切にしています。
翻訳は Solutions Architect の長谷川 純也が担当しました。