アプリケーションをさらにセキュアにするために使用される、セキュリティ関連のヘッダがあります。以下に、最も重要なヘッダを示します。また、ページの下部のサイトにアクセスして、このトピックに関する詳細な情報を確認することができます。これらのヘッダは、express 用の Helmet モジュール（koa Helmet）を使って簡単に設定することができます。
- HTTP Strict Transport Security (HSTS)
- Public Key Pinning for HTTP (HPKP)
- X-Frame-Options
- X-XSS-Protection
- X-Content-Type-Options
- Referrer-Policy
- Expect-CT
- Content-Security-Policy
- Additional Resource
HTTP Strict Transport Security (HSTS) は、プロトコルのダウングレード攻撃やクッキーハイジャッキングからウェブサイトを保護するための、ウェブセキュリティポリシーの仕組みです。これにより、Web サーバは、Web ブラウザ（または他の準拠するユーザエージェント）が 安全な HTTPS 接続 でのみ通信し、 安全でない HTTP プロトコルを経由して 決して 通信しないことを宣言することができます。HSTS ポリシーは、既存の HTTPS 接続上で Strict-Transport-Security ヘッダを使用して実装されています。
Strict-Transport-Security ヘッダには、どれくらいの期間 HTTPS のみを使用してサイトにアクセスするかをブラウザに通知するための秒単位の max-age 値と、サイトのすべてのサブドメインに Strict Transport Security ルールを適用するための includeSubDomains 値を指定します。
ヘッダ例 - 1 週間有効化された、サブドメインを含む HSTS ポリシー
Strict-Transport-Security: max-age=2592000; includeSubDomains
🔗 OWASP Secure Headers Project で読む
HTTP Public Key Pinning (HPKP) は、HTTPS のウェブサイトを、誤って発行された、もしくは不正な SSL/TLS 証明書を使用した攻撃者によるなりすましに対抗できるようにするセキュリティメカニズムです。
（訳注：HPKP 自体は非推奨となっており、後述の Expect-CT ヘッダに置き換えられています）
HTTPS ウェブサーバーは公開鍵ハッシュのリストを提供し、後続の接続では、証明書チェインにおいてクライアントはサーバーがこれらの公開鍵のうちの 1 つ以上を使用することを期待します。この機能を注意して使用することで、アプリケーションのユーザが過度のリスクを負うことなく、中間者（MITM）攻撃やその他の誤認証の問題のリスクを大幅に減らすことができます。
実装する前に、設定ミスからのリカバリのための高度な柔軟性やその他の利点のために、まず Expect-CT ヘッダを見ておくべきです。
Public-Key-Pins ヘッダは、4つの値を受け付けることができます。証明書の公開鍵を追加するための pin-sha256 値（SHA256 アルゴリズムを使用してハッシュ化されているため、異なる公開鍵に対して複数回追加することができる）、ルールを適用する期間をブラウザに伝えるための max-age 値、すべてのサブドメインに適用するための includeSubDomains 値、そしてピンの検証に失敗した際に、失敗した旨を報告する URL を指定する report-uri 値があります。
ヘッダ例 - 1 週間有効化され、サブドメインを含み、example URL に失敗を報告し、2 つの公開鍵を許可した HPKP ポリシー
Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=2592000; includeSubDomains
🔗 OWASP Secure Headers Project で読む
X-Frame-Options ヘッダは、フレームを使用して他の（外部の）ページをアプリケーションを埋め込むことができるかどうかのポリシーを宣言することで、クリックジャッキング攻撃からアプリケーションを保護します。
X-Frame-Options は 3 つのパラメータを許可します。リソースの埋め込みを一般的に許可しないための deny パラメータ、同じホスト/オリジンのリソースの埋め込みを許可する sameorigin パラメータ、そして特定のホストを許可するための allow-from パラメータです（訳注：allow-from は廃止されました）
ヘッダ例 - アプリケーションの埋め込みを拒否する
X-Frame-Options: deny
🔗 OWASP Secure Headers Project を読む
このヘッダはブラウザのクロスサイトスクリプティングフィルタを有効化します。
これは 4 つのパラメータを受け付けます。フィルタを無効化する 0、フィルタを有効化して、攻撃を検知した際にページの自動サニタイズを行う 1、フィルタを有効化して、攻撃を検知した際にページのレンダリングを停止する mode=block（このパラメータは、1 の後にセミコロンを足して追加する必要があります）、そして攻撃を検知した際に攻撃レポートを作成して送信する report=<domainToReport> です（同様に 1 の後に追加する必要があります）。
ヘッダ例 - XSS プロテクションを有効化し、攻撃を example URL に送信する
X-XSS-Protection: 1; report=http://example.com/xss-report
🔗 OWASP Secure Headers Project で読む
このヘッダを設定すると、ブラウザがファイルを HTTP ヘッダで宣言されたファイルタイプと別のものとして解釈することを防ぎます。
ヘッダ例 - コンテンツスニッフィングを無効化する
X-Content-Type-Options: nosniff
🔗 OWASP Secure Headers Project で読む
Referrer-Policy HTTP ヘッダは、Referer ヘッダで送信される、リファラー情報をリクエストにどれだけ含めるかを制御します。
これは 8 つのパラメータを許可しています。Referer ヘッダを完全に省略する no-referrer パラメータ、（水準が）ダウングレードされた際（HTTPS → HTTP）に Referer ヘッダを省略する no-referrer-when-downgrade パラメータ、ホストオリジン のみ をリファラーとして送信する origin パラメータ、同一オリジンの際はフルオリジン URL を送信し、その他の場合はホストオリジンのみを送信する origin-when-cross-origin パラメータ、同じオリジンにのみリファラー情報を送信しクロスオリジンのリクエストの場合は省略する same-origin パラメータ、同じセキュリティレベル（HTTPS → HTTPS）の場合にのみ Referer ヘッダーを保持しそれに劣る水準の場合は省略する strict-origin パラメータ、同一オリジンの場合はフルリファラー URL を送信し、クロスオリジンで 同じ セキュリティレベルの送信先の場合はオリジン のみ を送信し、安全性の劣るクロスドメインの送信先にはリファラーを送信しない strict-origin-when-cross-origin パラメータ、同一オリジン、クロスオリジンに関わらずフルリファラーを送信する unsafe-url パラメータです。
ヘッダー例 - 完全に Referer ヘッダを取り除く
Referrer-Policy: no-referrer
🔗 OWASP Secure Headers Project で読む
Expect-CT ヘッダは、認証透過性の要件に準拠しているかどうか確認するために、ヘッダを発行するホストへの接続をブラウザが評価すべきということを示すことを目的として、サーバによって使用されます。
このヘッダは 3 つのパラメータを受け付けます。Expect-CT の失敗を報告する URI を指定する report-uri、（報告するだけでなく）認証透過性ポリシーに従い、認証透過性ポリシーに違反するコネクションを拒否するようにブラウザに指示する enforce パラメータ、ブラウザが既知の Expect-CT ホストとみなすべき時間を秒数で指定する max-age パラメータです。
ヘッダ例 - 1 週間、認証透過性ポリシーを強制、example URL に報告する
Expect-CT: max-age=2592000, enforce, report-uri="https://example.com/report-cert-transparency"
🔗 OWASP Secure Headers Project で読む
HTTP Content-Security-Policy レスポンスヘッダは、特定のページに対して、ユーザーエージェントが読み込みをすることができるリソースを制御することを可能にします。いくつかの例外を除いて、ほとんどの場合ポリシーはサーバオリジンとスクリプトのエンドポイントを指定します。これは、クロスサイトスクリプティング攻撃（XSS）対策に役立ちます。
ヘッダ例 - CSP を有効にして、同一オリジンからのスクリプトのみを実行する
Content-Security-Policy: script-src 'self'
以下のリンクで、Content-Security-Policy で有効になっている多くのポリシーを見ることができます。
🔗 OWASP Secure Headers Project で読む
🔗 OWASP Secure Headers Project
🔗 Node.js Security Checklist (RisingStack)