HTTP Strict Transport Security（HSTS）はサーバー間の通信で意味がありますか？
HTTPSインターフェースでHSTSを有効にしていないことがときどき見つかりますが、これらのインターフェースはサーバー間のみであるため、HSTSを有効にするとセキュリティに違いが出ますか？
なぜHSTSなのか？
HSTSの弱点は、HTTP経由で要求を行うことによって最初にサーバーに接続し、HTTPSバージョン（または404）にリダイレクトされることが予想されるクライアントから保護するように設計されています。攻撃者はその要求をMitMして、リダイレクトを送信する代わりに、（変更された可能性がある）サイトをHTTP経由で送信できます。
HTTPを介した接続は、多くの理由で開くことができます。
- SSLストリップのような攻撃。
- URLバーにHTTPアドレスを入力する人
- HTTPへのハードコードされたリンク。
これらはサーバーに影響を与えますか？ 3つ目は可能性がありますが、サーバーに接続するすべてのソフトウェアを完全に制御できるかどうかによって異なります。
フルコントロールがある場合
これまでに使用されたすべてのURLがHTTPSに対するものであることを確認してください。それらが構成ファイルから読み取られる場合は、それらがHTTPではないことを明示的に確認してください。これにより、HSTSが不要になります。その間は、安全な暗号スイートのみを受け入れ、おそらく 証明書または公開鍵のピン留め の実装を検討する必要があります。
フルコントロールがない場合
他の人があなたのサーバーに接続するソフトウェアを書いているとしましょう。これらの人々が彼らが何をしているか知っているかどうかあなたは知りません。誤ってどこかにHTTPリクエストを送信する可能性があります。
彼らが使用するライブラリが実際にHSTSヘッダーを解釈および適用する場合（HSTSの強制を担当するのはクライアント）、HSTSをオンにするとこれらの人々はより安全になります。しかし、それはまだエッジのケースのようなものです-HTTPリクエストで404の回答をリダイレクトせずにリダイレクトする場合、誰がなぜそれを作成するソフトウェアを書くのか想像することは困難です。また、ほとんどのライブラリはHSTSヘッダーを無視しているのではないかと思います。しかし、誰が知っていますか！
HSTSは、ブラウザーを使用してインターフェイスを使用するユーザーがいない場合でも、おそらく違いはありません。
クライアント（この場合はもう一方のサーバー）を制御している場合は、HTTPS URLのみを要求し、HTTP要求は要求できません。また、クライアントがHSTSをサポートしているかどうかも疑問です。多くのブラウザに実装されていますが、多くのHTTPライブラリには実装されていません。
それが違いを生むことができる1つの方法は、サーバーがHTTPSからHTTPにリダイレクトするかどうかです。 HSTSを有効にすると、サポートするクライアントはリダイレクトに従いません。
HTTPSだけが必要なように思えるので、HTTPサービスを無効にすることもできます。
サーバーおよびクライアントアプリケーションがカスタム開発および制御されたシナリオでは、HSTSが緩和する 脅威モデル はありません。
伝送の両側で適切な証明書を構成し、HSTSに依存せずにプロトコルのダウングレードを防止する必要があります。
HSTSは、ユーザーが保護レベルを評価するための情報または技術的スキルを持つリモートサーバーにアクセスするシナリオで、SSLを完全に無効にするか、プロトコルを下位（安全でない）バージョンにダウングレードすることによるSSLのバイパスに対する保護として導入されました。
最後に、クライアントアプリケーションがHSTSをサポートしていない場合、それをオンにしても効果はありません。