最新の安定バージョンについては、Spring Security 6.3.1 を使用してください！

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

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

Web アプリケーションのセキュリティを強化するために使用できる多くの HTTP レスポンスヘッダー [OWASP] (英語) があります。このセクションは、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: 1; mode=block
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 攻撃を実行できることです。例: 一部のサイトでは、ユーザーが有効な PostScript ドキュメントを Web サイトに送信して表示できる場合があります。悪意のあるユーザーが、有効な JavaScript ファイルでもある PostScript ドキュメント (英語) を作成し、それを使用して XSS 攻撃を実行する可能性があります。

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

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

HTTP Strict Transport Security (HSTS)

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

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

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

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

サイトを HSTS ホストとしてマークする 1 つのメソッドは、ホストをブラウザーにプリロードすることです。もう 1 つのメソッドは、Strict-Transport-Security ヘッダーをレスポンスに追加することです。例: Spring Security のデフォルトの動作は、ブラウザーにドメインを 1 年間 HSTS ホストとして扱うよう指示する次のヘッダーを追加することです（1 年で約 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 を推奨しなくなりました。

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

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

X-Frame-Options

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

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

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

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

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

X-Frame-Options: DENY

X-XSS-Protection

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

一部のブラウザーには、反射された XSS 攻撃 [OWASP] (英語) を除外するためのサポートが組み込まれています。これは決して絶対確実ではありませんが、XSS 保護を支援します。

通常、フィルタリングはデフォルトで有効になっているため、ヘッダーを追加すると、通常は有効になり、XSS 攻撃が検出されたときにブラウザーに何をするかが指示されます。例: フィルターは、コンテンツを最も侵襲性の低い方法で変更して、すべてをレンダリングしようとする場合があります。時々、この型の交換は XSS 自体の脆弱性 (英語) になることがあります。代わりに、コンテンツを修正するのではなく、ブロックすることをお勧めします。デフォルトでは、Spring Security は次のヘッダーを使用してコンテンツをブロックします。

X-XSS-Protection: 1; mode=block

コンテンツセキュリティポリシー (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.com/ (英語) などのパブリックにホストされた 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.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"

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

クロスオリジンポリシー

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

Spring Security は、いくつかの重要なクロスオリジンポリシーヘッダーのサポートを提供します。それらのヘッダーは次のとおりです。

Cross-Origin-Opener-Policy （COOP）を使用すると、トップレベルのドキュメントで、ウィンドウとブラウジングコンテキストグループ内の他のドキュメント（ポップアップとオープナーなど）の間の関連付けを解除し、それらの間の直接 DOM アクセスを防ぐことができます。

Cross-Origin-Embedder-Policy （COEP）を有効にすると、ドキュメントの読み込み権限を明示的に付与していない同一生成元以外のリソースがドキュメントに読み込まれるのを防ぐことができます。

Cross-Origin-Resource-Policy （CORP）ヘッダーを使用すると、リソースを含めることができるようになっているオリジンのセットを制御できます。これは、スペクター (英語) のような攻撃に対する強力な防御であり、ブラウザーが攻撃者のプロセスに入る前に特定のレスポンスをブロックできるようにします。

カスタムヘッダー

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

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