Nginx でセキュリティヘッダーを構成する方法

NGINX でセキュリティヘッダーを構成することは、Web アプリケーションのセキュリティを強化するために不可欠です。セキュリティヘッダーは、クロスサイトスクリプティング (XSS)、クリックジャッキング、その他のコードインジェクション攻撃など、さまざまな攻撃から保護します。セキュリティヘッダーは、サイトのコンテンツの処理方法をブラウザーに指示し、セキュリティをさらに強化します。

このガイドでは、NGINX でセキュリティヘッダーを構成する手順について説明します。これにより、Web アプリケーションを保護し、全体的なセキュリティを向上させることができます。

NGINX での HTTP Strict Transport Security (HSTS) の実装

HSTS を理解する

HTTP Strict Transport Security (HSTS) は、Web サイトのセキュリティに不可欠なプロトコルです。ドメインへの接続は必ず HTTPS 経由で行うよう強制します。これにより、中間者攻撃などのリスクが軽減され、オンラインで送信されるデータの整合性と機密性が確保されます。ユーザーが HTTP 経由でサイトにアクセスしようとすると、HSTS は自動的に接続を HTTPS にアップグレードします。

NGINX での HSTS の設定

NGINX で HSTS を設定するには、NGINX 構成ファイルのサーバーブロックを更新する必要があります。このファイルは通常、/etc/nginx/nginx.conf または /etc/nginx/sites-available/ のサイト固有の構成内にあります。更新には、指定されたドメインに対して常に HTTPS を使用するようにブラウザに指示するヘッダーの追加が含まれます。

ドメインのサーバーブロックに次の行を追加します。

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

この行には 2 つのコンポーネントが含まれています。

max-age=31536000: 今後 12 か月間、サイトで HTTPS を使用することをブラウザに指示します。
includeSubDomains: 包括的なセキュリティを実現するために、サイトのすべてのサブドメインに HSTS ポリシーを適用します。

HSTS を使用した NGINX 構成のサンプル

HSTS ヘッダーを使用した NGINX 構成は次のようになります。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        proxy_pass http://my_portal;
    }
}

このヘッダーを追加した後、sudo systemctl reload nginx または sudo nginx -s reload を使用して NGINX をリロードし、変更を有効にします。

追加のNGINX設定例

シナリオによって、HSTS を使用した NGINX の構成は異なる場合があります。追加の例を次に示します。

マルチドメインサーバー

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

この構成は、同じサーバー上でホストされている複数のドメインに HSTS を適用します。リストされている各ドメインは、HTTPS 接続を強制します。

SSL ターミネーションを備えたサーバー

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

このセットアップは、SSL 終了を処理するサーバー用です。指定された SSL 証明書を使用してセキュアポート (443) で HSTS を構成し、セキュアな接続を強化します。

NGINX でのコンテンツセキュリティポリシー (CSP) の構成

NGINX での CSP の実装

Content-Security-Policy (CSP) を NGINX に統合することは、Web アプリケーションのセキュリティを強化するための戦略的な動きです。これには、NGINX 構成ファイルのサーバーブロック内に特定のヘッダーを追加することが含まれます。通常、このファイルは /etc/nginx/nginx.conf または /etc/nginx/sites-available/ ディレクトリにあり、CSP を効果的に適用するには慎重に編集する必要があります。

基本的な CSP 設定の場合は、サーバーブロックに次の行を追加します。

add_header Content-Security-Policy "default-src 'self';" always;

このディレクティブは、コンテンツの読み込みを Web サイトのドメイン (「自己」) に制限し、悪意のある外部コンテンツの実行のリスクを大幅に軽減します。

CSP を使用した NGINX 構成の例

基本的な CSP ディレクティブを使用した NGINX 構成は次のようになります。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Content-Security-Policy "default-src 'self';" always;

    location / {
        proxy_pass http://my_portal;
    }
}

このディレクティブを追加した後、sudo systemctl reload nginx または sudo nginx -s reload を使用して NGINX をリロードします。

特定のニーズに合わせた CSP のカスタマイズ

CSP は、Web サイトの特定のセキュリティニーズに対応するようにカスタマイズできます。さまざまなシナリオ向けの拡張構成を次に示します。

あらゆるソースからの画像を許可する

add_header Content-Security-Policy "default-src 'self'; img-src *;" always;

この構成では、他の種類のコンテンツに対する厳密な制御を維持しながら、任意のソースから画像を読み込むことができます。

特定のスクリプトとスタイルの設定

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscript.com; style-src 'self' 'unsafe-inline';";

この設定により、ドメインおよび信頼できる外部ソースからのスクリプトがインラインスタイルとともに許可され、機能性とセキュリティのバランスが保たれます。

CSP ディレクティブとオプションの調査

CSP のディレクティブ

CSP ディレクティブは、特定のコンテンツタイプに対するポリシーを定義するルールです。一般的なディレクティブには次のものがあります。

default-src: ほとんどのコンテンツタイプに適用されるデフォルトのポリシー。
script-src: JavaScript リソースのソースを管理します。
style-src: CSS リソースの許可されたソースを指定します。
img-src: 画像リソースのソースを制御します。
connect-src: XMLHttpRequest、WebSocket、EventSource などのネットワーク接続のポリシーを設定します。

CSP のソース式

ソース式は、各ディレクティブの許容ソースを定義します。

'none': すべてのソースをブロックします。
'self': 同じオリジンからのリソースを許可します。
'unsafe-inline': スタイルや JavaScript URL などのインラインリソースを許可します。
'unsafe-eval': JavaScript を許可する eval() 関数および同様のメソッド。
https:: 任意の HTTPS URL からのリソースを有効にします。

NGINX での X-XSS 保護の設定

X-XSS 保護の概要

X-XSS-Protection、つまりクロスサイトスクリプティングヘッダーは、Web アプリケーションを XSS (クロスサイトスクリプティング) 攻撃から保護するために不可欠です。Chrome、Internet Explorer、Safari などの主要な Web ブラウザーでサポートされているこのヘッダーは、リフレクション XSS 攻撃が検出されたときにページの読み込みを防ぐことで Web セキュリティを強化します。

NGINX で X-XSS 保護を有効にする

X-XSS-Protection ヘッダーを NGINX サーバー構成に統合すると、ブラウザのネイティブ XSS 保護が強化されます。このセキュリティ機能を有効にするには、通常 /etc/nginx/nginx.conf または /etc/nginx/sites-available/ ディレクトリにある NGINX 構成ファイルにアクセスします。

NGINX 構成ファイルのサーバーブロックに、次のディレクティブを挿入します。

add_header X-XSS-Protection "1; mode=block";

この指令は 2 つの部分から構成されます。

1: ブラウザの XSS フィルターを有効にします。
mode=block: XSS 攻撃が検出された場合、ページのサニタイズを試みずに、ページをブロックするようにブラウザに指示します。

X-XSS保護を備えたNGINX構成の例

X-XSS-Protection を含む NGINX 構成の例は次のようになります。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://my_portal;
    }
}

このヘッダーを追加した後、sudo systemctl reload nginx または sudo nginx -s reload のいずれかを使用して NGINX をリロードします。

追加の NGINX 構成シナリオ

SSL対応サーバーの場合

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

この設定は SSL を備えたサーバー用であり、暗号化された接続で X-XSS 保護がアクティブであることを保証します。

複数のドメインの処理

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

この構成では、単一のサーバーでホストされている複数のドメイン全体に X-XSS 保護が適用されます。

NGINX での X-Frame-Options の設定

X-Frame-Optionsの役割

X-Frame-Options は、Web サイトをクリックジャッキング攻撃から保護するために設計された重要なセキュリティヘッダーです。このヘッダーは、これらの攻撃でよく使用されるフレームまたは iframe 内での Web ページの表示を防ぎます。すべての主要 Web ブラウザーでサポートされている X-Frame-Options は、幅広い保護を提供し、さまざまなプラットフォームでの Web プレゼンスのセキュリティを強化します。

NGINX での X-Frame-Options の実装

NGINX サーバー構成に X-Frame-Options ヘッダーを組み込むことは、サイトのセキュリティを強化する上で非常に重要です。このタスクには、通常 /etc/nginx/nginx.conf または /etc/nginx/sites-available/ ディレクトリにある NGINX 構成ファイルの編集が含まれます。

このセキュリティ機能を有効にするには、NGINX 構成ファイルのサーバーブロックに次のディレクティブを追加します。

add_header X-Frame-Options "DENY";

このディレクティブを「DENY」に設定すると、フレームまたは iframe でページをレンダリングするすべての試行をブロックするようにブラウザに指示し、クリックジャッキングに対する強力な防御を提供します。

X-Frame-Options を使用した NGINX 設定の例

X-Frame-Options ヘッダーを使用した NGINX 設定の例は次のとおりです。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Frame-Options "DENY";

    location / {
        proxy_pass http://my_portal;
    }
}

このヘッダーを追加したら、変更を有効にするために NGINX をリロードすることが重要です。これは、sudo systemctl reload nginx または sudo nginx -s reload を使用して実行できます。

X-Frame-Options の NGINX 設定の拡張

SSL対応サーバーの場合

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

この構成は SSL を備えたサーバー用であり、安全な接続で X-Frame-Options が確実に適用されるようにします。

複数のドメインの処理

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

この設定により、同じサーバー上の複数のドメインに X-Frame-Options ヘッダーが適用され、各ドメインのセキュリティが強化されます。

NGINX での X-Content-Type-Options の実装

X-Content-Type-Options の役割

X-Content-Type-Options は、ブラウザによる MIME タイプのスニッフィングを防止する、Web セキュリティにおける重要なセキュリティヘッダーです。このヘッダーは、ブラウザが HTTP ヘッダーで宣言されたコンテンツタイプを尊重することを強化し、画像ファイルを実行可能な HTML として扱うなど、ブラウザがファイルタイプを誤って解釈した場合に発生する可能性のあるセキュリティの脆弱性に対処します。この脆弱性は、クロスサイトスクリプティング (XSS) 攻撃につながる可能性があります。

NGINX で X-Content-Type-Options を設定する

X-Content-Type-Options ヘッダーを使用して Web サーバーのセキュリティを強化するには、NGINX 構成ファイルを直接変更する必要があります。このファイルは通常、/etc/nginx/nginx.conf または /etc/nginx/sites-available/ のサイト固有の構成内にあります。

このヘッダーを組み込むには、次の行を server NGINX 設定のブロック:

add_header X-Content-Type-Options "nosniff";

「nosniff」設定は、ブラウザがサーバーの指定されたコンテンツタイプに厳密に従うように指示し、コンテンツの別の解釈を防止します。

X-Content-Type-Options を使用した NGINX 設定の例

X-Content-Type-Options を使用した NGINX 構成は、次のように構成されます。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://my_portal;
    }
}

設定を更新した後は、sudo systemctl reload nginx または sudo nginx -s reload を使用して、変更を有効にするために NGINX をリロードしてください。

拡張された NGINX 構成例

SSL/TLS の設定

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header X-Content-Type-Options "nosniff";

    # Additional SSL configurations and locations
}

この設定は SSL/TLS を備えたサーバー用であり、セキュリティを強化するために安全な接続に X-Content-Type-Options を適用します。

マルチドメインサーバー構成

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Content-Type-Options "nosniff";

    # Additional configurations for multiple domains
}

この構成では、同じサーバー上でホストされている複数のドメインに X-Content-Type-Options ヘッダーが適用され、すべてのドメインで一貫したセキュリティ設定が確保されます。

NGINX での Referrer-Policy の設定

リファラーポリシーの機能

Referrer-Policy は、Web 上のユーザーのプライバシーとセキュリティを強化するために不可欠な HTTP ヘッダーです。ユーザーが自分のサイトから他のサイトに移動するときに Referer ヘッダーに含まれる参照情報の量を制御し、Web リクエストで機密情報が漏洩するのを防ぎます。

NGINX で Referrer-Policy を設定する

NGINX サーバーに Referrer-Policy ヘッダーを実装するには、通常 /etc/nginx/nginx.conf または /etc/nginx/sites-available/ ディレクトリにある NGINX 構成ファイルを変更します。サーバーブロックに次のディレクティブを追加します。

add_header Referrer-Policy "no-referrer";

このディレクティブを「no-referrer」に設定すると、サイトナビゲーション中にリファラー情報が送信されず、プライバシーが最大限に保護されます。

Referrer-Policy を使用した NGINX 設定の例

Referrer-Policy ヘッダーを使用した NGINX 構成は次のようになります。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Referrer-Policy "no-referrer";

    location / {
        proxy_pass http://my_portal;
    }
}

このヘッダーを追加した後、sudo systemctl reload nginx や sudo nginx -s reload などのコマンドを使用して NGINX をリロードします。

リファラーポリシーのオプションと定義

no-referrer: リファラー情報は送信されません。
no-referrer-when-downgrade (デフォルト): 同じオリジンの宛先または安全なページからの安全な (HTTPS) 宛先 URL のリファラー情報を送信します。
origin: origin (スキーム、ホスト、ポート) のみを送信します。
origin-when-cross-origin: 同一オリジンのリクエストの場合は完全な URL を送信しますが、それ以外の場合はオリジンのみを送信します。
same-origin: 同一オリジンリクエストの場合は完全なリファラーを送信しますが、クロスオリジンリクエストの場合はヘッダーを送信しません。
strict-origin: HTTPS リクエストのオリジンを送信しますが、HTTP リクエストのヘッダーは送信しません。
strict-origin-when-cross-origin: 同一オリジンのリクエストには完全なリファラーを送信し、HTTPS ページからは HTTPS の宛先にオリジンを送信し、HTTP の宛先にはヘッダーを送信しません。
unsafe-url: 発信元やセキュリティに関係なく完全な URL を送信します (非推奨)。

拡張された NGINX 構成例

SSL/TLS 構成

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Referrer-Policy "no-referrer";

    # Additional SSL configurations
}

この構成は、SSL/TLS 対応の安全な環境で Referrer-Policy ヘッダーを適用し、暗号化された接続のプライバシーを強化します。

マルチドメインサーバー構成

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Referrer-Policy "no-referrer";

    # Additional configurations for each domain
}

この設定により、Referrer-Policy ヘッダーが同じサーバー上でホストされている複数のドメインに適用され、一貫したプライバシー設定が維持されます。

NGINX でのパーミッションポリシーの実装

権限ポリシーの理解

Permissions-Policy ヘッダーにより、Web 管理者は Web サイト上のブラウザ機能と API を正確に制御できるようになります。このヘッダーを構成すると、サイトのセキュリティとプライバシーが大幅に強化され、サイトの特定のニーズに基づいて、位置情報、カメラ、マイクなどの機能制限が可能になります。

NGINX での権限ポリシーの設定

NGINX サーバーに Permissions-Policy ヘッダーを組み込むには、通常 /etc/nginx/nginx.conf または /etc/nginx/sites-available/ ディレクトリ内にある NGINX 構成ファイルを変更します。

サーバーブロックに次のディレクティブを追加します。

add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

このディレクティブは、さまざまなブラウザ機能と API をリストし、それらすべてを () に設定して、事実上無効にします。この構成は、ユーザーのプライバシーやセキュリティを侵害する可能性のある機能を制限するための包括的なアプローチを提供します。

Permissions-Policy を使用した NGINX 設定のサンプル

Permissions-Policy ヘッダーを使用した NGINX 構成の例を次に示します。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

このディレクティブは、さまざまなブラウザ機能と API を包括的にリストし、それらを () に設定すると、事実上無効になります。

Permissions-Policy を使用した NGINX 設定のサンプル

Permissions-Policy を含む NGINX 構成は次のようになります。

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

これらの変更を行った後、sudo systemctl reload nginx または sudo nginx -s reload を使用して NGINX をリロードします。

権限ポリシーオプションの説明

Permissions-Policy ヘッダーを使用すると、さまざまな機能の使用をカスタマイズできます。

地理位置情報: 地理位置情報データへのアクセスを制御します。
ミディ: MIDI デバイスへのアクセスを管理します。
通知: 通知の表示を制御します。
押す: プッシュ通知機能に影響します。
同期-xhr: 同期 XMLHTTPRequest に関連します。
加速度計: デバイスの加速度計へのアクセスを指示します。
ジャイロスコープ: ジャイロスコープのアクセスを制御します。
磁力計: デバイスの磁力計へのアクセスを管理します。
支払い: 支払いリクエスト機能に適用されます。
USB: USB デバイスへのアクセスを制御します。
仮想: 仮想現実機能に関係します。
カメラ: カメラへのアクセスを管理します。
マイクロフォン: マイクのアクセスを指示します。
スピーカー: スピーカーデバイスへのアクセスを制御します。
振動する: 振動 API に影響します。
周囲光センサー: 周囲光センサーに関連します。
自動再生: メディアの自動再生を制御します。
暗号化されたメディア: 暗号化されたメディアへのアクセスを管理します。
クリップボードの実行: クリップボードの読み取り/書き込みアクセスを制御します。
ドキュメントドメイン: document.domain 機能に関連します。
全画面表示: フルスクリーンアクセスを指示します。
画像キャプチャ: 画像キャプチャ機能を制御します。
遅延読み込み: 画像の遅延読み込みに影響します。
レガシー画像フォーマット: 従来の画像形式に関連します。
特大画像: 特大サイズの画像の読み込みを制御します。
最適化されていない非可逆画像: 最適化されていない非可逆画像を管理します。
最適化されていないロスレス画像: 最適化されていないロスレス画像に関係します。
サイズなしメディア: 明示的なサイズなしでメディアを制御します。
垂直スクロール: 垂直スクロールに影響します。
ウェブ共有: Web 共有機能に関連します。
XR空間トラッキング: XR 空間トラッキングを制御します。

NGINX の権限ポリシーの高度な設定

特定のドメインとワイルドカードを使用した権限ポリシーの構成

() を使用して機能を無効にする基本的な設定に加えて、NGINX の Permissions-Policy は、特定のドメインまたはワイルドカードを使用して特定の機能を許可するようにカスタマイズできます。この高度な構成により、Web サイトがアクセスできる内容と場所をより細かく制御できます。

例: 特定のドメインからの機能の許可

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(https://trusteddomain.com), microphone=(https://alloweddomain.com)";

    location / {
        proxy_pass http://my_portal;
    }
}

この構成により、地理位置情報データへのアクセスは https://trusteddomain.com からのみ、マイクへのアクセスは https://alloweddomain.com からのみ許可され、これらの機密機能を信頼できるソースに制限することでセキュリティが強化されます。

例: 広範な権限にワイルドカードを使用する

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "camera=*; fullscreen=*";

    location / {
        proxy_pass http://my_portal;
    }
}

この設定のワイルドカード * により、どのドメインからでもカメラへのアクセスと全画面モードが許可されます。このアプローチでは、より広範な権限が提供され、さまざまなソースからの広範な機能へのアクセスを必要とする Web サイトに適しています。

例: 制限と権限の組み合わせ

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "accelerometer=(); gyroscope=(self https://example2.com); payment=*";

    location / {
        proxy_pass http://my_portal;
    }
}

この構成では、加速度計へのアクセスは無効になり、ジャイロスコープへのアクセスは同じドメインと https://example2.com から許可され、支払いリクエストはすべてのドメインから許可されます。

NGINX の Curl コマンドを使用してセキュリティヘッダーを検証する

Curl を使用してセキュリティヘッダーをチェックする

curl コマンドは、NGINX サーバーのセキュリティヘッダーの構成を確認するための便利なツールです。これを使用すると、Web サイトのヘッダーを検査し、セキュリティヘッダーが正しく設定されていることを確認できます。この検証手順は、Web サーバーのセキュリティ対策がアクティブであり、意図したとおりに機能していることを確認するために重要です。

ヘッダー検証のためのCurlコマンドの実行

ウェブサイトのヘッダーを確認するには、ターミナルで次のコマンドを実行します。

curl -I http://example.com

example.com を自分のドメイン名に置き換えます。このコマンドはサーバーからヘッダーを要求し、アクティブなセキュリティ構成に関する情報を提供します。

期待される出力と解釈

curl コマンドを実行すると、次のような出力が表示されます。

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Mar 2023 00:00:00 GMT
Content-Type: text/html
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self';
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();"

この出力は、Strict-Transport-Security、Content-Security-Policy、X-XSS-Protection などのさまざまなセキュリティヘッダーがサーバー上に存在し、正しく構成されていることを確認します。出力にリストされている各ヘッダーは、Web サーバーをさまざまな Web の脆弱性から保護する上で特定の役割を果たします。

結論

NGINX でセキュリティヘッダーを構成すると、Web アプリケーションのセキュリティが大幅に強化されます。セキュリティヘッダーを定期的に確認して更新し、進化するセキュリティの脅威に適応してください。これらのヘッダーを実装すると、さまざまな攻撃から保護し、ユーザーのより安全なブラウジングエクスペリエンスを確保できます。Web アセットを堅牢に保護するために、常に注意を払い、NGINX 構成を最新の状態に保ってください。

Author
Recent Posts

私に従ってください

Joshua James

Joshua James は、経験豊富な Linux システム管理者であり、linuxcapable.com の所有者です。彼は、ユーザーが Linux システムを理解するのに役立つ多くのチュートリアルとガイドを執筆しています。Joshua の専門知識は、Ubuntu、Fedora、Debian、RHEL、openSUSE、Arch Linux など、さまざまな Linux ディストリビューションを網羅しています。彼は、Linux や Unix 系システムを初めて使用するユーザーが自分の知識から学べるよう支援することに情熱を注いでいます。

私に従ってください

Joshua James による最新の投稿 (すべてを見る)

Debian 12 または 11 に Apache で ModSecurity 2 をインストールする方法 - 火曜日, 9月 17, 2024
Rocky Linux 9 または 8 に Remi RPM をインストールする方法 - 月曜日, 9月 16, 2024
Ubuntu 24.04、22.04、20.04 に Akregator をインストールする方法 - 火曜日, 9月 3, 2024

NGINX での HTTP Strict Transport Security (HSTS) の実装

HSTS を理解する

NGINX での HSTS の設定

HSTS を使用した NGINX 構成のサンプル

追加のNGINX設定例

マルチドメインサーバー

SSL ターミネーションを備えたサーバー

NGINX でのコンテンツ セキュリティ ポリシー (CSP) の構成

NGINX での CSP の実装

CSP を使用した NGINX 構成の例

特定のニーズに合わせた CSP のカスタマイズ

あらゆるソースからの画像を許可する

特定のスクリプトとスタイルの設定

CSP ディレクティブとオプションの調査

CSP のディレクティブ

CSP のソース式

NGINX での X-XSS 保護の設定

X-XSS 保護の概要

NGINX で X-XSS 保護を有効にする

X-XSS保護を備えたNGINX構成の例

追加の NGINX 構成シナリオ

SSL対応サーバーの場合

複数のドメインの処理

NGINX での X-Frame-Options の設定

X-Frame-Optionsの役割

NGINX での X-Frame-Options の実装

X-Frame-Options を使用した NGINX 設定の例

X-Frame-Options の NGINX 設定の拡張

SSL対応サーバーの場合

複数のドメインの処理

NGINX での X-Content-Type-Options の実装

X-Content-Type-Options の役割

NGINX で X-Content-Type-Options を設定する

X-Content-Type-Options を使用した NGINX 設定の例

拡張された NGINX 構成例

SSL/TLS の設定

マルチドメインサーバー構成

NGINX での Referrer-Policy の設定

リファラーポリシーの機能

NGINX で Referrer-Policy を設定する

Referrer-Policy を使用した NGINX 設定の例

リファラーポリシーのオプションと定義

拡張された NGINX 構成例

SSL/TLS 構成

マルチドメインサーバー構成

NGINX でのパーミッションポリシーの実装

権限ポリシーの理解

NGINX での権限ポリシーの設定

Permissions-Policy を使用した NGINX 設定のサンプル

Permissions-Policy を使用した NGINX 設定のサンプル

権限ポリシーオプションの説明

NGINX の権限ポリシーの高度な設定

特定のドメインとワイルドカードを使用した権限ポリシーの構成

例: 特定のドメインからの機能の許可

例: 広範な権限にワイルドカードを使用する

例: 制限と権限の組み合わせ

NGINX の Curl コマンドを使用してセキュリティ ヘッダーを検証する

Curl を使用してセキュリティ ヘッダーをチェックする

ヘッダー検証のためのCurlコマンドの実行

期待される出力と解釈

結論

コメントを残す コメントをキャンセル

NGINX でのコンテンツセキュリティポリシー (CSP) の構成

NGINX の Curl コマンドを使用してセキュリティヘッダーを検証する

Curl を使用してセキュリティヘッダーをチェックする

コメントを残すコメントをキャンセル