セキュリティ HTTP レスポンスヘッダー

ドキュメントのこのパートでは、セキュリティ HTTP レスポンスヘッダーの一般的なトピックについて説明します。サーブレットおよび WebFlux ベースのアプリケーションのセキュリティ HTTP レスポンスヘッダーに関する特定の情報については、関連するセクションを参照してください。

HTTP レスポンスヘッダー [OWASP] (英語) はさまざまな方法で使用して、Web アプリケーションのセキュリティを強化できます。このセクションでは、Spring Security が明示的にサポートするさまざまな HTTP レスポンスヘッダーについて説明します。必要に応じて、カスタムヘッダーを提供するように Spring Security を構成することもできます。

デフォルトのセキュリティヘッダー

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方のデフォルトをカスタマイズする方法については、関連するセクションを参照してください。

Spring Security は、セキュリティ関連の HTTP レスポンスヘッダーのデフォルトセットを提供して、安全なデフォルトを提供します。

Spring Security のデフォルトでは、次のヘッダーが含まれます。

デフォルトのセキュリティ HTTP レスポンスヘッダー 
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 0

Strict-Transport-Security は HTTPS リクエストにのみ追加されます

デフォルトがニーズを満たさない場合は、これらのデフォルトからヘッダーを簡単に削除、変更、追加できます。これらの各ヘッダーの詳細については、対応するセクションを参照してください。

キャッシュ制御

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方のデフォルトをカスタマイズする方法については、関連するセクションを参照してください。

Spring Security のデフォルトでは、ユーザーのコンテンツを保護するためにキャッシュを無効にします。

ユーザーが機密情報を表示するために認証してからログアウトする場合、悪意のあるユーザーが戻るボタンをクリックして機密情報を表示できないようにする必要があります。デフォルトで送信されるキャッシュ制御ヘッダーは次のとおりです。

デフォルトのキャッシュ制御 HTTP レスポンスヘッダー 
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

デフォルトで安全にするために、Spring Security はデフォルトでこれらのヘッダーを追加します。ただし、アプリケーションが独自のキャッシュ制御ヘッダーを提供している場合、Spring Security は邪魔になりません。これにより、アプリケーションは静的リソース（CSS や JavaScript など）を確実にキャッシュできるようになります。

コンテンツ型オプション

サーブレットと webflux ベースの両方のアプリケーションのデフォルトをカスタマイズする方法については、関連するセクションを参照してください。

従来、Internet Explorer を含むブラウザーは、コンテンツスニッフィング [Mozilla] を使用してリクエストのコンテンツ型を推測しようとしました。これにより、ブラウザーは、コンテンツ型を指定していないリソースのコンテンツ型を推測することで、ユーザーエクスペリエンスを向上させることができました。例: ブラウザーがコンテンツ型が指定されていない JavaScript ファイルを検出した場合、コンテンツ型を推測して実行することができます。

コンテンツのアップロードを許可する場合は、他にも多くのことを行う必要があります（たとえば、ドキュメントを個別のドメインにのみ表示する、Content-Type ヘッダーが設定されていることを確認する、ドキュメントをサニタイズするなど）。ただし、これらの対策は Spring Security が提供する範囲外です。また、コンテンツスニッフィングを無効にする場合は、正しく機能するためにコンテンツ型を指定する必要があることを指摘することも重要です。

コンテンツスニッフィングの問題は、悪意のあるユーザーがポリグロット（つまり、複数のコンテンツ型として有効なファイル）を使用して XSS 攻撃を実行できることです。例: 一部のサイトでは、ユーザーが有効な追記ドキュメントを Web サイトに送信して表示できる場合があります。悪意のあるユーザーが、有効な JavaScript ファイルでもある PostScript ドキュメント (英語) を作成し、それを使用して XSS 攻撃を実行する可能性があります。

デフォルトでは、Spring Security は、HTTP レスポンスに次のヘッダーを追加することにより、コンテンツスニッフィングを無効にします。

nosniff HTTP レスポンスヘッダー 
X-Content-Type-Options: nosniff

HTTP Strict Transport Security (HSTS)

サーブレットと webflux ベースの両方のアプリケーションのデフォルトをカスタマイズする方法については、関連するセクションを参照してください。

銀行の Web サイトに入力するとき、mybank.example.com と入力しますか、それとも https://mybank.example.com と入力しますか ? https プロトコルを省略すると、中間者攻撃 [Wikipedia] に対して脆弱になる可能性があります。Web サイトが https://mybank.example.com へのリダイレクトを実行したとしても、悪意のあるユーザーが最初の HTTP リクエストをインターセプトし、レスポンスを操作する可能性があります (たとえば、https://mibank.example.com にリダイレクトして資格情報を盗む)。

多くのユーザーは https プロトコルを省略するため、HTTP Strict Transport Security (HSTS) [IETF] (英語) が作成されました。mybank.example.com が HSTS ホスト [IETF] (英語) として追加されると、ブラウザーは mybank.example.com へのリクエストが https://mybank.example.com として解釈されるべきであることを事前に知ることができます。これにより、中間者攻撃が発生する可能性が大幅に減少します。

RFC6797 [IETF] (英語) に従って、HSTS ヘッダーは HTTPS レスポンスにのみ挿入されます。ブラウザーがヘッダーを確認するには、ブラウザーは最初に、接続に使用される SSL 証明書（SSL 証明書だけでなく）に署名した CA を信頼する必要があります。

サイトを HSTS ホストとしてマークする方法のひとつは、ホストをブラウザーにプリロードすることです。もう 1 つのメソッドは、Strict-Transport-Security ヘッダーをレスポンスに追加することです。例: Spring Security のデフォルトの動作は、次のヘッダーを追加することです。これは、ドメインを 1 年間 HSTS ホストとして扱うようにブラウザーに指示します（うるう年以外の年には 31536000 秒があります）。

Strict Transport Security HTTP レスポンスヘッダー 
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload

オプションの includeSubDomains ディレクティブは、サブドメイン（secure.mybank.example.com など）も HSTS ドメインとして扱う必要があることをブラウザーに指示します。

オプションの preload ディレクティブは、ドメインを HSTS ドメインとしてブラウザーにプリロードする必要があることをブラウザーに指示します。HSTS プリロードの詳細については、hstspreload.org (英語) を参照してください。

HTTP 公開鍵ピンニング (HPKP)

パッシブを維持するために、Spring Security は引き続きサーブレット環境で HPKP をサポートします。ただし、前述の理由により、HPKP は Spring Security チームによって推奨されなくなりました。

HTTP 公開鍵ピンニング (HPKP) [Mozilla] は、偽造された証明書による中間者（MITM）攻撃を防ぐために、特定の Web サーバーで使用する公開鍵を Web クライアントに指定します。HPKP を正しく使用すると、侵害された証明書に対する保護の層を追加できます。ただし、HPKP は複雑であるため、多くの専門家は HPKP と Chrome はサポートを削除しました (英語) の使用を推奨していません。

HPKP が推奨されなくなった理由の詳細については、HTTP 公開鍵ピンニングは無効ですか？ (英語) および HPKP をあきらめています (英語) を参照してください。

X-Frame-Options

サーブレットと webflux ベースのアプリケーションの両方のデフォルトをカスタマイズする方法については、関連するセクションを参照してください。

Web サイトをフレームに追加できるようにすることは、セキュリティの課題になる可能性があります。例: 巧妙な CSS スタイルを使用することで、ユーザーはだまされて意図しないものをクリックする可能性があります。例: 銀行にログインしているユーザーが、他のユーザーにアクセスを許可するボタンをクリックする場合があります。この種の攻撃はクリックジャッキング [Wikipedia] として知られています。

クリックジャッキングに対処する別の現代的なアプローチは、コンテンツセキュリティポリシー (CSP) を使用することです。

クリックジャッキング攻撃を軽減する方法はいくつかあります。例: クリックジャッキング攻撃からレガシーブラウザーを保護するために、フレームブレイクコード [Wikipedia] を使用できます。完璧ではありませんが、フレームを壊すコードは、レガシーブラウザーで実行できる最善の方法です。

クリックジャッキングに対処するためのより現代的なアプローチは、X-Frame-Options [Mozilla] (英語) ヘッダーを使用することです。デフォルトでは、Spring Security は次のヘッダーを使用して iframe 内のページのレンダリングを無効にします。

X-Frame-Options: DENY

X-XSS-Protection

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方のデフォルトをカスタマイズする方法については、関連するセクションを参照してください。

一部のブラウザーには、反射型 XSS 攻撃 [OWASP] (英語) を除外するためのサポートが組み込まれています。フィルターは主要なブラウザーで廃止されており、現在の OWASP の推奨事項 (英語) は、ヘッダーを明示的に 0 に設定することです。

デフォルトでは、Spring Security は次のヘッダーを使用してコンテンツをブロックします。

X-XSS-Protection: 0

コンテンツセキュリティポリシー (CSP)

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方を構成する方法については、関連するセクションを参照してください。

コンテンツセキュリティポリシー (CSP) [W3C] (英語) は、クロスサイトスクリプティング（XSS）などのコンテンツインジェクションの脆弱性を軽減するために Web アプリケーションが使用できるメカニズムです。CSP は、Web アプリケーションの作成者が宣言し、最終的に Web アプリケーションがリソースのロードを期待するソースについてクライアント（ユーザーエージェント）に通知する機能を提供する宣言型ポリシーです。

コンテンツセキュリティポリシーは、すべてのコンテンツインジェクションの脆弱性を解決することを目的としたものではありません。代わりに、CSP を使用して、コンテンツインジェクション攻撃によって引き起こされる害を減らすことができます。防御の第一線として、Web アプリケーションの作成者は、入力を検証し、出力をエンコードする必要があります。

Web アプリケーションは、レスポンスに次の HTTP ヘッダーのいずれかを含めることで CSP を使用できます。

  • Content-Security-Policy

  • Content-Security-Policy-Report-Only

これらの各ヘッダーは、セキュリティポリシーをクライアントに配信するメカニズムとして使用されます。セキュリティポリシーには、特定のリソース表現の制限を宣言するセキュリティポリシーディレクティブのセットが含まれています。

例: Web アプリケーションは、レスポンスに次のヘッダーを含めることにより、特定の信頼できるソースからスクリプトをロードすることを期待していることを宣言できます。

コンテンツセキュリティポリシーの例 
Content-Security-Policy: script-src https://trustedscripts.example.com

script-src ディレクティブで宣言されているもの以外の別のソースからスクリプトをロードしようとすると、ユーザーエージェントによってブロックされます。さらに、report-uri [W3C] (英語) ディレクティブがセキュリティポリシーで宣言されている場合、違反はユーザーエージェントによって宣言された URL に報告されます。

例: Web アプリケーションが宣言されたセキュリティポリシーに違反している場合、次のレスポンスヘッダーは、ポリシーの report-uri ディレクティブで指定された URL に違反レポートを送信するようにユーザーエージェントに指示します。

report-uri を使用したコンテンツセキュリティポリシー 
Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/

違反レポート [W3C] (英語) は、Web アプリケーション自体の API、または report-uri.io/ (英語) などの公的にホストされている CSP 違反報告サービスのいずれかによってキャプチャーできる標準の JSON 構造です。

Content-Security-Policy-Report-Only ヘッダーは、Web アプリケーションの作成者と管理者がセキュリティポリシーを適用するのではなく監視する機能を提供します。このヘッダーは通常、サイトのセキュリティポリシーを実験または開発するときに使用されます。ポリシーが有効であると見なされる場合は、代わりに Content-Security-Policy ヘッダーフィールドを使用してポリシーを適用できます。

次のレスポンスヘッダーが与えられた場合、ポリシーは、スクリプトを 2 つの可能なソースのいずれかからロードできることを宣言します。

コンテンツセキュリティポリシーレポートのみ 
Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.example.com; report-uri /csp-report-endpoint/

サイトがこのポリシーに違反している場合、evil.example.com からスクリプトを読み込もうとすると、ユーザーエージェントは report-uri ディレクティブで指定された宣言済み URL に違反レポートを送信しますが、違反しているリソースは引き続き読み込まれます。

コンテンツセキュリティポリシーを Web アプリケーションに適用することは、多くの場合、重要な作業です。次のリソースは、サイトの効果的なセキュリティポリシーを開発する上でさらに役立つ可能性があります。

コンテンツセキュリティポリシーの概要 (英語)

CSP ガイド - Mozilla Developer Network

W3C 候補勧告 (英語)

リファラーポリシー

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方を構成する方法については、関連するセクションを参照してください。

リファラーポリシー [W3C] (英語) は、ユーザーが最後に表示したページを含むリファラーフィールドを管理するために Web アプリケーションが使用できるメカニズムです。

Spring Security のアプローチは、さまざまなポリシー [W3C] (英語) を提供するリファラーポリシー [W3C] (英語) ヘッダーを使用することです。

リファラーポリシーの例 
Referrer-Policy: same-origin

Referrer-Policy レスポンスヘッダーは、ユーザーが以前いたソースを宛先に知らせるようにブラウザーに指示します。

機能ポリシー

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方を構成する方法については、関連するセクションを参照してください。

機能ポリシー (英語) は、Web 開発者がブラウザーの特定の API および Web 機能の動作を選択的に有効化、無効化、変更できるようにするメカニズムです。

機能ポリシーの例 
Feature-Policy: geolocation 'self'

機能ポリシーを使用すると、開発者はブラウザーの一連の「ポリシー」にオプトインして、サイト全体で使用される特定の機能に適用できます。これらのポリシーは、サイトがアクセスできる API を制限したり、特定の機能に対するブラウザーのデフォルトの動作を変更したりします。

権限ポリシー

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方を構成する方法については、関連するセクションを参照してください。

権限ポリシー (英語) は、Web 開発者がブラウザーの特定の API および Web 機能の動作を選択的に有効化、無効化、変更できるようにするメカニズムです。

権限ポリシーの例 
Permissions-Policy: geolocation=(self)

アクセス許可ポリシーを使用すると、開発者はブラウザーの一連の「ポリシー」にオプトインして、サイト全体で使用される特定の機能を適用できます。これらのポリシーは、サイトがアクセスできる API を制限したり、特定の機能に対するブラウザーのデフォルトの動作を変更したりします。

サイトデータのクリア

サーブレットベースのアプリケーションと webflux ベースのアプリケーションの両方を構成する方法については、関連するセクションを参照してください。

サイトデータのクリア [W3C] (英語) は、HTTP レスポンスに次のヘッダーが含まれている場合に、ブラウザー側のデータ（Cookie、ローカルストレージなど）を削除できるメカニズムです。

Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"

これは、ログアウト時に実行するクリーンアップアクションです。

カスタムヘッダー

サーブレットベースのアプリケーションを構成する方法については、関連するセクションを参照してください。

Spring Security には、より一般的なセキュリティヘッダーをアプリケーションに追加するのに便利なメカニズムがあります。ただし、カスタムヘッダーの追加を可能にするフックも提供します。