WordPress に HTTP セキュリティヘッダーを追加する方法

公開: 2023-05-18

WordPress は世界で最も人気のあるコンテンツ管理システム (CMS) であり、インターネット上のすべての Web サイトの 43%以上で稼働しています。ただし、広く使用されているため、ハッカーの一般的な標的となっています。

ブルート フォース攻撃、ファイル アップロードの脆弱性、クロスサイト スクリプティング攻撃はすべて、現在進行中の脅威の一因となっています。

幸いなことに、Web サイトをより安全にし、攻撃を受けにくくする方法は複数あります。 そこで HTTP ヘッダーが登場します。

HTTP セキュリティ ヘッダーを実装すると、ブラウザとサーバーが Web サイト上で実行できるアクションを制限し、セキュリティ層を追加できます。 これらのヘッダーにより、攻撃者がクライアント側の脆弱性を悪用することが非常に困難になります。

この記事では、 HTTP セキュリティ ヘッダーとは何か、およびそれを Web サイトに効果的に実装する方法について説明します。

HTTP セキュリティ ヘッダーとは何ですか?

HTTP セキュリティ ヘッダーは、Web アプリケーションが Web ブラウザーにセキュリティ防御を実装するために使用するディレクティブのグループです。 これらのヘッダーは、HTTP 通信のセキュリティ パラメーターを識別するために、Web ブラウザー (クライアント) とサーバーの間で交換されます。 この情報交換により、ブラウザーはサイトとのやり取り全体でどのように動作するかを指示し、エラーの表示やキャッシュの管理などのプロセスを制御します。

もちろん、この追加のセキュリティと効率はブラウザに大きく依存しています。 古い W​​eb ブラウザには、同レベルのセキュリティや互換性がなく、HTTP セキュリティ ヘッダーを正しく、完全に、あるいはまったく処理できない可能性があります。 これは、訪問者の安全を確保するためにあらゆる努力をしたにもかかわらず、ブラウザが古いために依然として脆弱なままであることを意味する可能性があります。 Web サイト開発者として、私たちはできる限りのことを行う必要がありますが、訪問者のコンピュータ上で最新のソフトウェアを使用していることを確認するのは訪問者の責任であることを受け入れる以外にありません。 最新の Web ブラウザを使用している限り、HTTP セキュリティ ヘッダーの使用はブラウザ ソフトウェアと連携して安全を保ちます。

ただし、私たちの主な懸念は、HTTP セキュリティ ヘッダーによって、クロスサイト スクリプティングやブルート フォース攻撃などの一般的な攻撃から Web サイトが防止されることです。これらのヘッダーを実装する最も効果的な方法は、ヘッダーを WordPress ホスティング アカウント (サーバー レベル) に設定し、Cloudflare などの DNS レベルの Web サイト アプリケーション ファイアウォールを使用することです。

ただし、HTTP セキュリティ ヘッダーの追加はサイトのセキュリティの向上に役立ちますが、それは Web サイトのセキュリティの 1 つの側面にすぎず、他のセキュリティ対策と組み合わせて使用​​する必要があることに注意してください。 これには、アプリケーションとプラグインを常に最新の状態に保つこと、機密データを暗号化すること、サイト データと構成ファイルをバックアップすることが含まれます。

セキュリティ ヘッダーを追加するさまざまな方法について説明する前に、各ヘッダーを詳しく見て、それがなぜ重要なのかを理解しましょう。セキュリティ ヘッダーについてすでによく知っている場合は、以下のセクションに進んでください。

WordPress HTTP セキュリティヘッダーの種類

保護を強化するために WordPress Web サイトで使用できる HTTP セキュリティ ヘッダーがいくつかあります。 最も重要なものをいくつか見てみましょう。

1. X-XSS 保護セキュリティ ヘッダー

このセキュリティ ヘッダーは、クロスサイト スクリプティング (XSS) を構成するために使用されます。XSS は、認証されていない第三者がブラウザーで別の Web サイトに代わってコードを実行できるようにするセキュリティの脆弱性です。

攻撃が検出された場合にサイトのレンダリングを停止することで、Web サイトに対する多くの XSS 攻撃を防ぎます。 X-XSS は、有害な可能性のある要素を置き換えてページを駆除するのではなく、サイトを完全に読み込まないというより安全なオプションを採用しています。

ヘッダーには、次のいくつかの値のいずれかを指定できます。

  • X-XSS-Protection: 0 XSS フィルタリングを無効にします(非推奨)
  • X-XSS-Protection: 1 XSS フィルタリングを有効にします。これは通常、ほとんどのブラウザのデフォルトです。 XSS 攻撃が検出された場合、ブラウザはページの安全でない部分を削除します (サニタイズ)。
  • X-XSS 保護: 1; mode=block XSS フィルタリングを有効にしますが、ブラウザはページをサニタイズするのではなく、ページのレンダリングを防止します(推奨)
  • X-XSS 保護: 1; report=<reporting-uri> XSS フィルタリングを有効にします。 クロスサイト スクリプティング攻撃が検出された場合、ブラウザーはページをサニタイズし、違反を報告します。

2. X-Frame オプションのセキュリティヘッダー

X-Frame-Options セキュリティ ヘッダーは、さまざまなブルート フォース攻撃や DDOS 攻撃を防ぐために使用できますが、最も効果的な用途は、WordPress Web サイトでの iframe のクロスジャッキングやクリックジャッキングに対するものです。このヘッダーを使用すると、Web サイト上のページをブラウザーの iframe 要素を使用して埋め込むことができるかどうかを決定できます。

X-Frame オプションは、iframe がサイトに埋め込まれるのを阻止することで、Web サイトをクリック盗難から保護します。 これには、DENYとSAMEORIGIN という2 つの異なるディレクティブがあり、どちらかを選択できます。Chrome、Safari、Firefox、Opera などのすべての一般的な Web ブラウザで動作します。

 X フレーム オプション: 拒否
X フレーム オプション: SAMEORIGIN

DENY を指定すると、X-Frame-Options ヘッダーは、他のサイトからロードされたときにブラウザがフレーム内にページをロードしようとすると失敗します。 これを実行しようとすると、元のサイトから iframe にロードされたときにも失敗します。 一方、 SAMEORIGINを指定した場合、フレーム内にそのページを含むサイトがそのページを提供するサイトと同じである限り、そのページをフレーム内で使用することができます。

このヘッダーは、機密情報を含む Web ページや、支払いゲートウェイやフォームなどの情報が埋め込まれたページにとって特に重要です。

3. HTTP Strict Transport Security (HSTS) ヘッダー

HTTP Strict-Transport-Security は、Web サーバーからユーザーの Web ブラウザに送信されるセキュリティ応答ヘッダーで、サイトには HTTP のみを使用してアクセスし、暗号化されていない HTTP を介してはアクセスしないことを通知します。

このヘッダーは、ユーザーがアドレス バーに「http://」と入力した場合や HTTP リンクをたどった場合でも、ブラウザーによる HTTPS の使用を強制するメカニズムを提供します。また、期限切れまたは無効な SSL/TLS 証明書やその他のブラウザ警告をユーザーが無視することを防ぐこともできます。 HSTS 値は、Web サイトにアクセスするブラウザごとに設定されます。 マシンごとに設定されるものではありません。

HSTS ヘッダーには、任意のサブドメインを含めるオプションが用意されています。「includeSubDomains」ディレクティブを使用して、ルート ドメインと同じレベルのセキュリティを採用できます。 これは、ブラウザが HTTPS トラフィックのみを許可するため、ドメイン (またはサブドメイン) を使用したローカル開発には HTTP 経由でアクセスできなくなることを意味します。

たとえば、example.com に必要な「includeSubdomains 」ディレクティブを含む HSTS ヘッダーがある場合、example.com にアクセスすると、安全でない接続を介して example.com のサブドメインにアクセスできなくなります。 したがって、 「includeSubdomains」の使用を選択した場合は、他のドメインに影響を与える可能性があるので注意してください。

ブラウザーがサイトから HSTS ヘッダーを受信すると、指定された期間の間 HSTS ポリシーを記憶し、サイトに対する今後のすべてのリクエストを自動的に HTTPS にアップグレードします。 これにより、ブラウザとサーバー間のすべての通信が確実に暗号化されるため、中間者攻撃、盗聴、その他の形式の改ざんを回避できます。

このヘッダーの構文は次のとおりです。

 # includeSubDomains ディレクティブなし
<IfModule mod_headers.c>
ヘッダーセット Strict-Transport-Security: “max-age=63072000;”
</Ifモジュール>
# includeSubDomains ディレクティブあり
<IfModule mod_headers.c>
ヘッダー セット Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" 
</Ifモジュール>

max-age=<expire-time>ディレクティブは、HTTPS を使用した場合のみサイトにアクセスできることをブラウザーが記憶する時間 (秒単位) を指定します。 たとえば、上の例では、 max-age は2 年に設定されています。 Servbolt CDN または Servbolt の高速化されたドメインを選択した場合、HSTS の長さは自動的に 1 年間になります。

4. リファラーポリシーヘッダー

この HTTP ヘッダーは、リファラー ヘッダー経由で送信されるリファラー情報をリクエストにどの程度含めるかを制御します。 サイト訪問者がリンクをクリックしたときに送信される情報の量を制限します。 これにより、個人情報を含むページの URL など、他の Web サイトへの機密情報の漏洩を防ぐことができます。

複数の値を持つことができます。簡単な概要を次に示します。

  • no-referrer: Referer ヘッダーはいかなる状況でも送信されません。
  • No-referrer-when-downgrade: HTTPS サイトから HTTP サイトに移動するときに、Referer ヘッダーは送信されません。
  • Origin: Referer ヘッダーには、参照ページのオリジン (スキーム、ホスト、ポート) のみが含まれます。
  • Origin-when-cross-origin: Referer ヘッダーには、同じオリジン内のページ間を移動する場合は参照元ページの完全な URL が含まれ、異なるオリジンに移動する場合はオリジンのみが含まれます。
  • 厳密なオリジン: Referer ヘッダーには参照ページのオリジンのみが含まれ、クロスオリジン リクエストには送信されません。
  • Strict-origin-when-cross-origin: Referer ヘッダーには参照ページのオリジンが含まれ、同じサイトのオリジンを除いてクロスオリジン リクエストには送信されません。 データ漏洩のリスクを軽減しながらヘッダーの有用性を維持できるため、この設定を使用することをお勧めします。
  • Unsafe-url: Referer ヘッダーは、セキュリティに関係なく、リクエストを実行するときにオリジン、パス、クエリ文字列を送信します。

リファラー ポリシー ヘッダーの詳細については、リファラー ポリシーのベスト プラクティスに関する Google web.dev の記事を参照してください。

5. X-Content-Type-Options ヘッダー

X-Content-Type-Options ヘッダーは、MIME タイプについてブラウザに示すために、HTTP 応答でサーバーによって送信されます。 このヘッダーの目的は、ブラウザーがファイルをヘッダーで指定された MIME タイプとは異なる MIME タイプとして解釈しないようにすることです。

このヘッダーには、 「nosniff」という単一の値を含めることができます。 構文は次のとおりです。

 X-Content-Type-Options: nosniff

これは、MIME 混乱攻撃に対して非常に効果的です。このセキュリティ ヘッダーを使用すると、ブラウザがセキュリティ上の脆弱性につながる可能性のある予期しない方法でファイルを解釈するのを防ぐことができます。 たとえば、攻撃者が拡張子 .jpg を持つファイルをアップロードしたが、実際にはスクリプトであるためコンテンツが含まれていない場合、 X-Content-Type-Optionsヘッダーを「nosniff」に設定すると、ブラウザはスクリプトを実行できなくなります。したがって、潜在的な侵害からユーザーを保護します。

6.コンテンツ セキュリティ ポリシー(CSP) ヘッダー

Content-Security-Policy は、コンテンツの生成元を指定するために使用されるセキュリティ ヘッダーであり、Web サイトまたは Web アプリケーションでの読み込みと実行を許可するコンテンツのメカニズムを提供します。 一連のポリシーを指定することで、このヘッダーは Web ページで許可されるコンテンツの種類を制限し、さまざまな種類のセキュリティの脅威を軽減できます。 これは、データ盗難、サイト改ざん、マルウェア配布などの犯罪に使用されるクロスサイト スクリプティング (XSS) およびデータ インジェクション攻撃に対する追加のセキュリティ層です。

Content-Security-Policy ヘッダーは、ロードできるリソースの種類を制御するだけでなく、ヘッダーで指定されたポリシーの違反を処理する方法をブラウザーに指示する方法も提供します。 たとえば、リソースがポリシーに違反する場合、ブラウザが警告を発行するか、リソースのロードをブロックする必要があることをポリシーで指定できます。

ポリシーが機能するには、Content-Security-Policy ヘッダーを返すようにサーバーを構成する必要があります。 CSP HTTP ヘッダーを使用して、次のようにポリシーを指定できます。

 コンテンツ セキュリティ ポリシー: ポリシー

このポリシーは、コンテンツ セキュリティ ポリシーを説明するポリシー ディレクティブを含む文字列です。 たとえば、次の行を .htaccess ファイルに追加して CSP を実装できます。

 <IfModule mod_headers.c>
ヘッダー セット Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis。 com names.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
</Ifモジュール>

WordPress Web サイトで CSP を強制している場合、 WordPress が正しく動作するには「unsafe-inline」と「unsafe-eval」が必要であることに注意してください。 上記の構成は、ほとんどの WordPress Web サイトにとって適切な開始点です。 ただし、各セクションの意味を明確に理解せずに上記の構成を使用すると、リスクが伴います。 各ディレクティブの内訳は次のとおりです。

  • default-src – このディレクティブは、他のディレクティブによってオーバーライドされない限り、すべてのタイプのリソースのデフォルト ポリシーを設定します。この場合、リソースを同じオリジン ('self') からロードできるほか、HTTPS ソースや 'unsafe-eval' または 'unsafe-inline' を使用するスクリプトからもロードできます。
  • object-src – このディレクティブは、Flash や Java アプレットなど、ページに埋め込むことができるオブジェクトのタイプを制限します。ここでは、同じオリジン ('self') からのみオブジェクトをロードできるようにします。
  • font-src – このディレクティブは、フォントをロードできるソースを制限します。ここでは、HTTPS ソース、データ URI スキーム、同じオリジン ('self')、または Google Fonts および Google User Content の HTTP ソースからフォントを読み込むことができます。
  • connect-src – このディレクティブは、AJAX リクエストや WebSocket などのネットワーク リクエストに使用できるソースを制限します。ここでは、HTTPS または WebSocket を介して、同じオリジン (「自己」) からのみ接続を確立できます。
  • img-src – このディレクティブは、画像をロードできるソースを制限します。ここでは、HTTPS ソース、データ URI スキーム、同じオリジン ('self') または Gravatar の HTTP ソースから画像をロードできるようになります。
  • worker-src – このディレクティブは、Web ワーカーをロードできるソースを制限します。ここでは、BLOB URI スキーム、HTTPS ソース、および「unsafe-eval」または「unsafe-inline」を使用するスクリプトからのみワーカーを読み込むことができます。
  • media-src – このディレクティブは、オーディオやビデオなど、メディア リソースをロードできるソースを制限します。ここでは、HTTPS ソース、BLOB URI スキーム、および同じオリジン ('self') からのみメディアを読み込むことができます。
  • style-src – このディレクティブは、スタイルシートをロードできるソースを制限します。ここでは、HTTPS ソースや「unsafe-eval」または「unsafe-inline」を使用するスクリプトからスタイルを読み込むことができるほか、同じオリジン (「self」) や Google Fonts の HTTP ソースからもスタイルを読み込むことができます。

WordPress インスタンスで CSP ヘッダーを使用する場合、特定のプラグインやサービスがサードパーティの JavaScript に依存している可能性があるため、CSP ヘッダーを不適切に適用すると WordPress 管理者ダッシュボードが破損することに注意することが重要です。

これを修正するには、各セキュリティ ルールをヘッダー ファイルに手動で追加する必要があります。 別の方法ですが、安全性は低くなりますが、管理ダッシュボードで CSP ヘッダーを無効にすることもできます。 たとえば、 servebolt.comで行っていることは次のとおりです。

 ヘッダー セット X-Frame-Options SAMEORIGIN
ヘッダー セット Referrer-Policy strict-origin-when-cross-origin
ヘッダー セット X-XSS-Protection "1; mode=block"
<If "%{REQUEST_URI} !~ /wp-admin/">
# 管理画面でない場合はヘッダーのみ追加
ヘッダーは常に Content-Security-Policy "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.intercomcdn.com cdn.firstpromoter.comservebolt.containers を設定します.piwik.pro *.intercom.io cdn.getreplybox.com platform.twitter.com v0.wordpress.com cdn.jsdelivr.netservebolt.piwik.pro ; media-src 'self' *.intercomcdn.com data: ; img -src 'self' 'unsafe-inline' *.intercom.io *.intercomcdn.com *.intercomassets.com データ: raskesider.raskesider.no *.servebolt.com secure.gravatar.comservebolt.piwik.pro ; connect- src 'self' ws: nexus-websocket-a.intercom.io *.piwik.proservebolt.piwik.pro *.intercom.io ; font-src 'self' *.intercomcdn.com data: ; Frame-src 'self ' app.getreplybox.com platform.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com *.intercom.io; フレーム先祖 'self' *.servebolt。 com;manifest-src 'self' ;"
</If>

サイトに CSP を適用する場合、HTTPS を使用していない場合、開発環境が中断される可能性があることに注意してください。 サイトのポリシーを生成する方法がわからない場合は、 ValidBot – CSP WizardまたはReport URI: CSP Generator などのグラフィック ツールを使用する必要があります。

7.アクセス許可ポリシーヘッダー

アクセス許可ポリシーは、開発者がWeb サイトに実装できる機能と実装できない機能を明示的に宣言するメカニズムを提供します。Web サイトに必要な一連の権限を管理します。 このヘッダーは、JavaScript API の悪用、ユーザーの追跡、感染コードの実行など、特定のセキュリティとプライバシーのリスクを防ぐために Web サイトの機能を制限するために使用されます。

アクセス許可ポリシーを使用すると、サーバーは特定のドキュメントで機能を使用できるかどうかを設定できます。 これは、特定の事前定義値を取る送信元のリストであるホワイトリストを使用します。 Permission-Policy ヘッダーの値は、Web サイトに必要なさまざまな権限を説明するディレクティブ名とその値のカンマ区切りのリストで構成されます。

Permissions-Policy ヘッダーの一般的な構文は次のとおりです。

 アクセス許可ポリシー: <ディレクティブ>=<許可リスト>

たとえば、地理位置情報へのすべてのアクセスをブロックする必要がある場合は、次のようにします。

 アクセス許可ポリシー: geolocation=()

ここで、記号 () は空のホワイトリストを意味します。 オリジンのサブセットへのアクセスを許可するには、次のようにします。

 <IfModule mod_headers.c>
ヘッダーは常に Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com')、midi=()、sync-xhr=()、accelerometer=( )、ジャイロスコープ=()、磁力計=()、カメラ=()、マイク=()、フルスクリーン=(セルフ)"
</Ifモジュール>

別の例を見てみましょう。 次のヘッダー値は、Web サイトがメイン ドキュメントと同じオリジンから提供されるスクリプトのみを実行するように制限します。

 権限ポリシー: script-src 'self'

Permissions-Policy ヘッダーは、従来の Content-Security-Policy ヘッダーを置き換えたり補完したりするために使用できます。このヘッダーは、同様の機能を提供しますが、構文が異なり、アクセス許可の範囲が狭くなります。このヘッダーは現在、Google Chrome およびその他の Chromium ベースのブラウザーでのみサポートされている実験的なテクノロジーです。これは、アクセス許可を制御するためのより強力で柔軟なメカニズムを提供しており、将来的にその採用が拡大すると予想されます。 自分で試してみたい場合は、アクセス許可ポリシー ヘッダー ジェネレーターを使用してアクセス許可ポリシーを簡単に生成できます。

.htaccess ファイルを使用した HTTP セキュリティ ヘッダーの追加

HTTP セキュリティ ヘッダーを追加する方法としては、 .htaccessファイルを直接編集することをお勧めします。これは、Apache Web サーバーで最も一般的に使用されるサーバー構成ファイルです。 このファイルを編集すると、WordPress の HTTP セキュリティ ヘッダーがサーバー レベルで設定されるようになります。

この方法を使用するには、 Web サイトの.htaccessファイルにアクセスする必要があります。 FTP クライアントを使用して Apache サーバーにアクセスできます。変更を加える前に、現在の.htaccessファイルのバックアップを作成することを強くお勧めします。

まず、FTP クライアントまたはホスティング コントロール パネルのファイル マネージャー ツールを使用してサイトにログインします。 Web サイトのルート フォルダーで.htaccessファイルを見つけ、[編集] オプションを右クリックします。 これにより、テキスト エディタでファイルが開きます。 HTTPS セキュリティ ヘッダーをサイトに追加するには、 .htaccessファイルの最後に関連するコードを追加します。

次のサンプル コードを開始点として使用できます。最も一般的に使用される HTTP セキュリティ ヘッダーを推奨設定で設定します。

 <IfModule mod_headers.c>
ヘッダー セット Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
ヘッダー セット X-XSS-Protection "1; mode=block"
ヘッダー セット X-Content-Type-Options "nosniff"
ヘッダー セット X-Frame-Options DENY
ヘッダーセットのリファラーポリシー「no-referrer-when-downgrade」
ヘッダー セット Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis。 com names.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
ヘッダーは常に Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com')、midi=()、sync-xhr=()、accelerometer=( )、ジャイロスコープ=()、磁力計=()、カメラ=()、マイク=()、フルスクリーン=(セルフ)"
</Ifモジュール>

上記の設定を .htaccess ファイルに追加すると、関連するヘッダーがすべての Web リクエストに適用されます。

ヘッダーが使用されているかどうかを確認するには、Chrome DevTools で [ネットワーク] タブを開き、リクエストの応答ヘッダーを調べます。

[ネットワーク] タブ Chrome DevTools

コードを追加した後、変更を保存し、Web サイトに再度アクセスして、期待どおりに動作していることを確認します。 また、間違ったコード ヘッダーやタイプミスによって500 Internal Server Errorなどのエラーが発生する可能性があるため、.htaccess ファイルを編集するときは注意する必要があります。

コンテンツ配信ネットワーク (CDN) を使用して WordPress に HTTP セキュリティ ヘッダーを追加する

コンテンツ配信ネットワーク (CDN) は、Web パフォーマンスを向上させるために、ユーザーに最も近いネットワークの場所からキャッシュされたインターネット コンテンツを提供する、地理的に分散されたサーバーのグループです。 Cloudflareなどの一般的な CDN を使用すると、Web サイトに HTTP ヘッダーを追加することもできます。

Cloudflareを例として、CDNを使用してHTTPヘッダーを追加する方法を見てみましょう。 Cloudflareは、CDNサービスとともに基本的な無料のWebサイトファイアウォールを提供しますが、より高度なセキュリティ機能はペイウォールの背後にロックされています。

WordPress ウェブサイトに Cloudflare を設定するのは非常に簡単です。 CloudflareのWebサイトで手動でサインアップし、画面の手順に従って有効にすることができます。 Web サイトで Cloudflare がアクティブ化されたら、Cloudflare アカウントのダッシュボードの SSL/TLS ページに移動します。

次に、[エッジ証明書] タブに切り替えて HTTP Strict Transport Security (HSTS) セクションを見つけ、[HSTS を有効にする] オプションをクリックする必要があります。 [HSTS を有効にする] ボタンをオンに切り替えると、サイトでこの機能を有効にするための手順がウィンドウに表示されます。 [次へ] ボタンをクリックしてプロセスを続行すると、HTTP セキュリティ ヘッダーを追加するオプションが表示されます。

ここから、サイトで HSTS を有効にし、HTTPS を使用しているサブドメインに HSTS を適用することも選択できます。 この方法を使用すると、HTTP セキュリティヘッダーを使用してサイトに基本的な保護が提供されますが、欠点は、Cloudflare では現在 X-Frame-Options を追加できないことです。

servebolt.com および Cloudflare 内のその他のドメインでは、HSTS がデフォルトで有効になっていることに注意してください。

WordPress プラグインを使用して HTTP セキュリティ ヘッダーを追加する

HTTP ヘッダーを追加および構成する 3 番目の方法は、プラグインを使用することです。 これは WordPress Web サイトに HTTP セキュリティ ヘッダーを追加する最も簡単な方法の 1 つですが、通常はヘッダーを手動で構成するより効果が若干劣ります。

多くのセキュリティ プラグインにはセキュリティ ヘッダーを追加するオプションが含まれていることを、すでにどこかで読んだかもしれません。 ただし、セキュリティ プラグインは使用しないことをお勧めします。 WordPress セキュリティ プラグインに関する記事を読んで、これらを使用する理由と懸念点を理解してください。

このセクションでは、さまざまなヘッダーを有効または無効にし、それらのさまざまなパラメーターを設定できます。 有効にできる正確なヘッダーは、選択したプラグインによって異なりますが、X-XSS-Protection、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security などの一般的なヘッダーは、ほとんどのプラグイン。

Web サイトの HTTP セキュリティ ヘッダーを確認する方法

WordPress Web サイトに HTTP セキュリティ ヘッダーを追加した後、それらが正しく構成され、期待どおりに動作することを確認する必要があります。 インターネット上で利用できる数多くの無料ツールの 1 つを使用してテストを実行できます。 Security HeadersまたはSSL Labs を使用することをお勧めします。どちらも、構成をテストし、すべてのセキュリティ ヘッダーが正しく機能していることを確認する簡単な方法を提供します。

これらのツールは、Web サイトのセキュリティ ヘッダーを評価し、詳細なレポートを提供します。 また、Web サイトがどの HTTP セキュリティ ヘッダーを送信しているのか、どの HTTP セキュリティ ヘッダーが送信されていないのかもわかります。 その後、サイトに A+ から F までのグレードが与えられ、そのグレードがどのように決定されたかについての説明が表示されます。

たとえば、 Vogueの Web サイトをテストしたところ、多くの重要な HTTP ヘッダーが欠落していることが判明したため、C グレードしか獲得できませんでした。

ヴォーグSSLテスト

そして、私たち自身のウェブサイトをテストするとご想像のとおり、A+ グレードを獲得しました。

サーブボルトSSLテスト

結論

HTTP ヘッダーの実装が Web サイトのセキュリティを確保するための重要なステップであることに疑問の余地はありません。 Web サイトに HTTP ヘッダーを正常に追加したら、次の追加の手順も考慮する必要があります。

  1. 脆弱性をテストする: クロスサイト スクリプティング (CSS) やクロスサイト リクエスト フォージェリ (CSRF) などの一般的なセキュリティ脆弱性についてサイトをテストすることが重要です。この目的のために、 OWASP ZAPやBurp Suiteなどのツールを使用できます。
  2. 変更を監視する: ヘッダーに予期しない変更がないか定期的に監視する必要があります。これは通常、脆弱性を悪用する試みがあったことを示します。
  3. ヘッダーを更新する: 新しい脅威が出現した場合、最新のセキュリティ慣行を常に把握し、それに応じてヘッダーを更新することが重要です。

経験的により高速なマネージド ホスティングに興味がありますか?

WordPress ホスティングへの当社のアプローチをお試しください – 開始は無料で、次のようなメリットがあります。

  • スケーラビリティ:実際のユーザー ワークロード テストでは、Servebolt は平均応答時間 65 ミリ秒を達成しました。これは、2 番目に優れたものよりも 4.9 倍速い応答時間です。
  • 最速のグローバル読み込み時間:平均ページ読み込み時間は 1.26 秒で、グローバル WebPageTest 結果リストのトップに位置します。
  • 最速のコンピューティング速度: Servebolt サーバーは、これまで前例のないデータベース速度を提供し、1 秒あたり平均の 2.44 倍のクエリを処理し、2 番目に速いサーバーよりも 2.6 倍速く PHP を実行します。
  • 完璧なセキュリティと稼働時間:すべてのモニターで 100% の稼働時間と SSL 実装の A+ 評価により、サイトがオンラインで安全であることが保証されます。

つまり、ホスティングを私たちに任せることで、サイトのセキュリティ、速度、パフォーマンスを簡単に改善できるようになります。 Servebolt にサインアップしてテストしてください。