この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "HTTP Strict Transport Security" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2025年12月)

HTTP
主要項目
持続的接続 圧縮（英語版） HTTPS HTTP/2 HTTP/3
リクエストメソッド
OPTIONS GET HEAD POST（英語版） PUT DELETE TRACE CONNECT PATCH（英語版）
ヘッダーフィールド（英語版）
Cookie ETag Location（英語版） リファラ DNT（英語版） X-Forwarded-For
ステータスコード
301 Moved Permanently（英語版） 302 Found 303 See Other（英語版） 403 Forbidden 404 Not Found 503 Service Unavailable
認証方式
Basic認証 Digest認証
セキュリティホール
HTTPヘッダ・インジェクション HTTPリクエストスマグリング（英語版） HTTPレスポンス分割（英語版） HTTPパラメータ汚染（英語版）
表 話 編 歴

HTTP Strict Transport Security (略称 HSTS)とは、WebサーバがWebブラウザに対して、現在接続しているドメイン（サブドメインを含む場合もある）に対するアクセスにおいて、次回以降HTTPの代わりにHTTPSを使うように伝達するセキュリティ機構である。HSTSはIETFの標準化過程にあるプロトコルであり、RFC 6797で規定されている。

WebサーバがWebブラウザに対して、セキュアなHTTPSのみでサービスを提供したい場合、ユーザーの利便性といった観点から、HTTPで接続した際にHTTPSのURIにリダイレクトする場合がある。その際に、Webサーバからのレスポンスにリダイレクトする指示を入れることになるが、HTTPは改竄検知機能を持たないため、攻撃者がこれを悪意のあるサイトにリダイレクトする指示に書き換えたり、HTTPSの内容をHTTPで中継(SSL Stripping)したとしても、Webブラウザはそれを知ることができず、クッキーハイジャックのような中間者攻撃を許してしまう。

HSTSではユーザーがWebブラウザにスキームがhttpであるURIを入力するなどしてHTTPで接続しようとした時に、予めWebサーバがHSTSを有効にするよう指示してきたドメインの場合、Webブラウザが強制的にHTTPSでの接続に置き換えてアクセスすることで、この問題を解決する。

HSTSポリシーは、サーバからユーザーエージェントへ、Strict-Transport-Securityという名前のHTTPレスポンスヘッダフィールドを介して伝達される。HSTSポリシーは、ユーザーエージェントがセキュアな方法でのみサーバにアクセスすべき期間を指定する RFC 6797。HSTSを使用するウェブサイトは、しばしば平文のHTTPを受け入れず、HTTP経由の接続を拒否するか、ユーザーを体系的にHTTPSへリダイレクトする（ただし、これは仕様で要求されているわけではない）。この結果、TLSを実行できないユーザーエージェントは、そのサイトに接続できなくなる。

この保護は、ユーザーが少なくとも一度そのサイトを訪れた後にのみ適用され、「Trust on first use」という原則に依存している。この保護の仕組みは、ユーザーがサイトへのHTTP（HTTPSではない）URLを入力または選択した際、ウェブブラウザなどのクライアントが、HTTPリクエストを行うことなく自動的にHTTPSにアップグレードすることで、HTTPによる中間者攻撃の発生を防ぐというものである。

HSTSは、サイトへの接続は常にTLS/SSLを使用すべきであることをブラウザに通知することで、この問題に対処する RFC 6797。ユーザーの初回訪問である場合、HSTSヘッダは攻撃者によって除去される可能性がある。Google Chrome、Firefox、およびInternet Explorer/Microsoft Edgeは、HSTSをサポートする既知のサイトを含むリストである「HSTSプリロードリスト」を実装することで、この制限に対処している^[1][2][3][4]。このリストはブラウザと共に配布され、リストにあるサイトへの最初の要求からHTTPSを使用する。これにより、初回訪問時の攻撃を防ぐことができる。

サーバは、HTTPS接続を介してヘッダを提供することでHSTSポリシーを実装する（HTTP経由のHSTSヘッダは無視される）^[5]。例えば、サーバは、今後1年間（max-ageは秒単位で指定され、31,536,000は閏年でない1年に相当する）そのドメインへの将来のリクエストがHTTPSのみを使用するようにヘッダを送信することができる： Strict-Transport-Security: max-age=31536000。

ウェブアプリケーションがユーザーエージェントにHSTSポリシーを発行すると、準拠したユーザーエージェントは次のように動作する RFC 6797。

1. ウェブアプリケーションを参照する安全でないリンクを、自動的に安全なリンクに変換する（例：http://example.com/some/page/は、サーバにアクセスする前にhttps://example.com/some/page/に変更される）。
2. 接続のセキュリティが確保できない場合（例：サーバのTLS証明書が信頼できない場合）、ユーザーエージェントは接続を終了させなければならず RFC 6797、ユーザーがウェブアプリケーションにアクセスすることを許可すべきではない RFC 6797。

HSTSポリシーは、ウェブアプリケーションのユーザーを、いくつかの受動的（盗聴）および能動的なネットワーク攻撃から保護するのに役立つ RFC 6797。中間者攻撃者がユーザーとウェブアプリケーションサーバ間のリクエストとレスポンスを傍受する能力は、ユーザーのブラウザがそのウェブアプリケーションに対してHSTSポリシーを有効にしている間は大幅に減少する。

• HSTSはHTTPS接続が安全であることを前提としているため、TLSの安全性が脅かされる場合には意味を成さない場合がある。^[6]

• 最初の接続ではWebブラウザはHTTPS接続を強制するべきかどうかを知り得ないため、攻撃に対して脆弱である。^[7]この問題に対する解決策として、上述のHSTSプリロードが存在する。

• ジュネード・アリは、HSTSは偽ドメインの使用に対しては効果がないと指摘している。DNSベースの攻撃を使用することで、中間者攻撃者がHSTSプリロードリストにない人工的なドメインからトラフィックを提供することが可能になる^[8]。これはDNSスプーフィング攻撃^[9]や、単にwww.example.orgをwww.example.comと誤認させるようなドメイン名によって可能になる。

• HSTSプリロードリストがあっても、HSTSは、BEASTやCRIME攻撃のような、TLS自体に対する高度な攻撃を防ぐことはできない。TLS自体への攻撃は、HSTSポリシーの範疇外である。また、サーバへの攻撃からも保護できない。

• HSTSは期限付きであるため、偽のNTPパケットを使用するなどして、被害者のコンピュータの時刻をずらす攻撃に対して脆弱である^[10]。

HSTS仕様は、2012年10月2日にIESGによって標準化提案のRFCとして公開が承認された後、2012年11月19日にRFC 6797として公開された^[11]。著者らは当初、2010年6月17日にインターネットドラフトとして提出した。インターネットドラフトへの転換に伴い、仕様名は「Strict Transport Security」（STS）から「HTTP Strict Transport Security」に変更された。これは、仕様がHTTPにのみ適用されるためである^[12]。しかし、HSTS仕様で定義されているHTTPレスポンスヘッダフィールドは「Strict-Transport-Security」という名前のままである。

当時「STS」と呼ばれていた仕様の最後のいわゆる「コミュニティ版」は、コミュニティからのフィードバックに基づいた改訂を加え、2009年12月18日に公開された^[13]。

PayPalのJeff Hodges、Collin Jackson、Adam Barthによる最初のドラフト仕様は、2009年9月18日に公開された^[14]。

HSTS仕様は、JacksonとBarthが論文「ForceHTTPS: Protecting High-Security Web Sites from Network Attacks」で記述した独創的な研究に基づいている^[15]。

さらに、HSTSは、Jeff HodgesとAndy Steingrueblが2010年の論文「The Need for Coherent Web Security Policy Framework(s)」で提唱した、ウェブセキュリティを改善するための全体的なビジョンの一側面を実現したものである^[16]。

• ChromiumおよびGoogle Chrome バージョン4.0.211.0以降^[17][18]
• Firefox バージョン4以降^[5]。Firefox 17で、MozillaはHSTSをサポートするウェブサイトのリストを統合した^[3]。
• Opera バージョン12以降^[19]
• Safari OS X Mavericks（バージョン10.9、2013年後半）以降^[20]
• Internet Explorer 11（Windows 8.1およびWindows 7、KB3058515インストール済み）（2015年6月にWindows Updateとしてリリース）^[21]
• Microsoft EdgeおよびInternet Explorer 11（Windows 10）^[22][23]
• BlackBerry 10 BrowserおよびWebView（BlackBerry OS 10.3.3以降）

1. ^ “Chromium HSTS Preloaded list”. cs.chromium.org. 2020年2月18日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
2. ^ Langley, Adam (2010年7月8日). “Strict Transport Security”. The Chromium Projects. 2019年9月1日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
3. ^ ^{a b} Keeler, David (2012年11月1日). “Preloading HSTS”. Mozilla Security Blog. 2020年2月24日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
4. ^ “HTTP Strict Transport Security comes to Internet Explorer” (2015年2月16日). 2015年11月15日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
5. ^ ^{a b} “Strict-Transport-Security” (英語). MDN Web Docs. Mozilla. 2020年3月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
6. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (2012年11月). “Section 14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport”. RFC 6797. IETF. 2013年6月29日閲覧。
7. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (2012年11月). “Section 14.6. Bootstrap MITM Vulnerability”. RFC 6797. IETF. 2013年6月29日閲覧。
8. ^ “Performing & Preventing SSL Stripping: A Plain-English Primer”. Cloudflare Blog (2017年10月20日). 2019年12月14日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
9. ^ Maksutov, A. A.; Cherepanov, I. A.; Alekseev, M. S. (2017). Detection and prevention of DNS spoofing attacks. 2017 Siberian Symposium on Data Science and Engineering (SSDSE). pp. 84–87. doi:10.1109/SSDSE.2017.8071970. ISBN 978-1-5386-1593-5. S2CID 44866769.
10. ^ Selvi, Jose (17 October 2014). Bypassing HTTP Strict Transport Security (PDF). Black Hat Briefings. アムステルダム. 2014年10月22日時点のオリジナルよりアーカイブ (PDF). 2025年7月29日閲覧.
11. ^ “[websec Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)]” (2012年10月2日). 2017年1月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
12. ^ Hodges, Jeff. “Re: [HASMAT "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)]”. 2017年2月2日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
13. ^ “Strict Transport Security -06” (2009年12月18日). 2017年2月21日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
14. ^ “Strict Transport Security -05” (2009年9月18日). 2020年2月24日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
15. ^ “ForceHTTPS: Protecting High-Security Web Site from Network Attacks” (2008年4月). 2020年2月28日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
16. ^ Hodges, Jeff (2010年10月29日). “The Need for Coherent Web Security Policy Framework(s)”. 2017年8月14日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
17. ^ The Chromium Developers (2010年11月17日). “Strict Transport Security - The Chromium Projects”. 2020年3月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
18. ^ Hodges, Jeff (2009年9月18日). “fyi: Strict Transport Security specification”. 2020年2月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
19. ^ Opera Software ASA (2012年4月23日). “Web specifications support in Opera Presto 2.10”. 2018年6月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
20. ^ Langley, Adam [@agl__] (20 December 2013). “確認済み。~/Library/Cookies/HSTS.plist を参照。ある時点でのChromiumプリロードを含み、HSTSヘッダを処理する。”. 2019年5月9日時点のオリジナルよりアーカイブ. X（旧Twitter）より2025年7月29日閲覧.
21. ^ “HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7”. windows.com. 2019年11月27日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
22. ^ “Internet Explorer Web Platform Status and Roadmap”. 2015年6月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
23. ^ “Project Spartan and the Windows 10 January Preview Build - IEBlog” (2015年1月22日). 2019年11月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。

• コンピュータセキュリティ

• RFC 6797 - HTTP Strict Transport Security
• HTTP Strict Transport Security - Security | MDN

• IETF WebSec ワーキンググループ
• Security Now 262: Strict Transport Security
• .dev – デフォルトでHSTSプリロードリストに含まれるGoogleが運営するTLD
• Open Web Application Security Project (OWASP): HSTS description
• オンラインブラウザ HSTS および Public Key Pinning テスト
• HSTS Preload Submission for Google Chrome, Mozilla Firefox, Safari, IE 11, and Edge
• Chromium HSTS Preloaded list
• Strict-Transport-Security on MDN Web Docs