HSTS ヘッダーを Web アプリケーションに追加するプロジェクトに取り組んでいます。
そのための準備として、default-src https ディレクティブのみを使用してレポート モードで CSP ヘッダーを追加しました。その目的は、違反を評価し、HSTS ヘッダーを追加するとユースケースが壊れるかどうかを判断することです。
質問:
サーバーでのみhttpsを使用している場合、それはかなり明白だと思いました。https設定してますか？すべてのhttp 要求を強制的に https にリダイレクトするようにリダイレクトを設定していますか? これらは、サーバー構成を確認することで簡単に回答できるはずの質問であり、CSP が回答する必要はないと思います。両方の答えが「はい」でない場合、なぜ HSTS を検討しているのですか?
CSP のサポートは普遍的ではありません (確かに HSTS もそうではありません)。これらの場合、一般的なブラウザをおそらくテストするため、通常は古い、あまり一般的でないブラウザが壊れます。続行するかどうかは議論の余地があります。
注意すべきことの 1 つは、includeSubDomains フラグを使用している場合です。これは、意図したよりも多くのサーバーに影響を与える場合に問題を引き起こす可能性がありますが、おそらく影響を受けると思われるサーバーにのみ CSP をセットアップするため、CSP は役に立ちません。詳細はこちら: https://serverfault.com/questions/665234/problems-using-hsts-header-at-top-level-domain-with-includesubdomains .
また、HSTS が実装されると、ブラウザーで証明書エラーをバイパスできなくなることにも注意してください。これを行う必要があるわけではありませんが、誰もが知っているわけではない、このフラグのもう 1 つの意図的な効果です。
ヘッダーを削除してポリシーの有効期限が切れるのを待つ以外に、HSTS の問題を解決する唯一の方法 (たとえば、結局 http が必要であることがわかった場合) は、最大年齢をゼロに戻して、人々がサイトにアクセスすることを期待することです。 https を使用して、この新しい HSTS ポリシーを取得し、以前のポリシーを上書きします。Chrome を使用すると、ポリシーを手動で表示して削除することができますが、訪問者の数が多く、完全な再インストール以外に他のブラウザーでこれを行う方法がわからない場合、これは実用的ではありません。
最善の方法は、HSTS とは何か、および上記の注意事項を十分に認識し、短い有効期限から始めて、問題が発生しない限りゆっくりと有効期限を延ばすことです。
プリロード リストもありますが、これを少なくとも 6 か月間問題なく実行できるようになるまでは、このリストには近づかないようにします。