背景
プロトコル相対URL(//example.com
形式)は、かつてHTTPとHTTPSの両環境に対応する手法として使われていた。
2010年代前半、ウェブサイトのHTTPS化が進み始めたが完全移行には至らず、両環境への対応が必要だった。プロトコル相対URLは混合コンテンツ問題の解決策として普及した。
しかし、ウェブの常時HTTPS化が進んだ現在、この記法はセキュリティリスクとなり、非推奨とされている。
プロトコル相対URL(//example.com
形式)は、かつてHTTPとHTTPSの両環境に対応する手法として使われていた。
2010年代前半、ウェブサイトのHTTPS化が進み始めたが完全移行には至らず、両環境への対応が必要だった。プロトコル相対URLは混合コンテンツ問題の解決策として普及した。
しかし、ウェブの常時HTTPS化が進んだ現在、この記法はセキュリティリスクとなり、非推奨とされている。
プロトコル相対URLとは、URLの先頭のプロトコル指定(http:
やhttps:
)を省略し、//
から始める記法である。
<script src="//example.com/script.js"></script>
<img src="//example.com/image.png" alt="画像" />
<link href="//example.com/style.css" rel="stylesheet" />
この記法の特徴は、閲覧中のページのプロトコルに自動適応することである。HTTPページではHTTP、HTTPSページではHTTPSでリソースを読み込む。
HTTPSページ内でHTTPリソースを読み込むと「混合コンテンツ」として警告が表示される。一方、HTTPページではHTTPSリソースを問題なく読み込める。この非対称性への対応策として、プロトコル相対URLが採用された。
Paul Irishの2010年の記事で紹介されたこの手法は、HTML5 Boilerplateプロジェクトに採用され広く普及した。CDNからライブラリを読み込む標準的な記述方法となった。
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script>
2014年、GoogleはHTTPSを検索ランキングの要素として採用した。これによりウェブサイトのHTTPS化が急速に進み、現在HTTPSはウェブの標準となっている。HTTP接続はブラウザで「安全ではない接続」として警告される(Chrome、Firefoxでは「保護されていない接続」「危険なサイト」として表示)。
この状況下では、プロトコル相対URLの主な利点である「環境に応じたプロトコル適応」の必要性が失われている。
プロトコル相対URLには次のようなリスクがある。
//
記法の不具合や挙動に問題現代ブラウザはセキュリティ対策として次のような機能を実装している。Chrome(2019年)、Firefox(2019年)、Edge(2020年)などの主要ブラウザは、プロトコル相対URLを含む混合コンテンツを自動的にHTTPSにアップグレードする機能を順次導入している。
これによりプロトコル相対URLを使う理由は消滅し、むしろリスクとなっている。CSPを併用することで、HTTPリソースの混入を防ぎ、プロトコル相対URLによるリスクを低減できる。
現在のベストプラクティスは、明示的にhttps://
を使用することである。
<!-- 推奨 -->
<script src="https://example.com/script.js"></script>
<!-- 非推奨 -->
<script src="//example.com/script.js"></script>
これにより次の利点がある。
古いコードでプロトコル相対URLが存在する場合の対応方法は次の通りである。
プロトコル相対URL(//example.com
形式)は、HTTPからHTTPSへの移行期に便利な手法として普及したが、現在はセキュリティリスクとなっている。
ウェブの常時HTTPS化が進んだ現代では、明示的に https://
を指定することがベストプラクティスである。レガシーコードのメンテナンス時には、プロトコル相対URLを発見したら積極的にHTTPSに書き換えるべきである。
この事例は、ウェブ開発において常に最新のセキュリティベストプラクティスを取り入れることの重要性を示している。