なぜ1つのhttp://画像だけで、その画像だけでなくページ全体のセキュリティが損なわれるのですか?

そのリクエストが暗号化・認証されていないため、同じネットワーク上の攻撃者(公衆Wi-Fiや侵害されたルーターなど)が通信中にそれを傍受・改ざんできるからです。それが何であるか(特にスクリプトの場合)によっては、他のすべてが正しくHTTPS経由で読み込まれていたとしても、ページの残りの部分まで危険にさらされる可能性があります。

ブラウザは混合コンテンツを自動的にブロックしますか、それとも警告するだけですか?

リソースの種類によります。スクリプト、スタイルシート、iframeなどの「アクティブ」な混合コンテンツは、最新のブラウザによって完全にブロックされます。画像、動画、音声などの「パッシブ」な混合コンテンツは通常読み込まれますが、アドレスバーに壊れた鍵マークの警告が表示され、これはまさに訪問者を躊躇させる類の信頼シグナルです。

Scanverraはどうやって混合コンテンツを見つけるのですか——HTMLをhttp://リンクでスキャンしているだけですか?

いいえ、それよりも強力です。Scanverraは実際のブラウザでページを読み込み、そのページが行う実際のネットワークリクエストを取得したうえで、httpsで配信されているページ上でhttp://から始まるリクエストにフラグを立てます。これにより、マークアップにハードコードされたものだけでなく、JavaScriptによって動的に読み込まれたリソースも検出できます。

upgrade-insecure-requestsを追加すれば、個々のURLについて心配しなくてよいのですか?

セーフティネットとしては役立ちます——送信前にhttp://リクエストを自動的にhttps://へ書き換えるようブラウザに指示します——が、これはそのリソースが同じホスト上で実際にHTTPS経由で利用可能な場合にのみ機能します。良い保険にはなりますが、ハードコードされたURLを修正することの代わりにはなりません。

混合コンテンツの警告を修正する方法

混合コンテンツとは、HTTPSで配信されているページが、たった1つのリソース——スクリプト、画像、スタイルシート、iframeなど——であってもプレーンなHTTPで読み込んでしまうことを指します。この暗号化されていないリクエストひとつが、ページの残りの部分が保証していたはずのセキュリティを損ない、ブラウザはそのリソースをブロックしたり、鍵アイコンを壊れた状態にしたり、あるいはその両方で応答します。

混合コンテンツが発生する理由

HTTPS移行前から残っているハードコードされたhttp://URL。 サイトがまだプレーンHTTPで運用されていた頃に書かれた古いマークアップ、CMSのコンテンツ、あるいは保存されたアセットURLのデータベースが、更新されないまま残っているケースです。
依然としてHTTPで配信され続けるサードパーティの埋め込みやウィジェット。 広告ネットワーク、コメントウィジェット、あるいは配信元自体をHTTPSに移行していない古いアナリティクススニペットなどです。
プロトコル移行時に見落とされたCDNやアセットホストのURL。 メインドメインはHTTPSに移行済みでも、画像やフォントを配信するサブドメインやサードパーティのアセットホストが同時に更新されていなかったケースです。
HTTPリンクが貼り付けられたユーザー生成コンテンツ。 ユーザーが投稿したコンテンツ(フォーラムの投稿、商品レビュー、CMSのフィールドなど)に含まれるhttp://の画像や埋め込みURLが、そのままレンダリングされてしまうケースです。

すべての箇所を特定する方法

Scanverraは、実際のブラウザでページを読み込み、その実際のネットワーク通信を取得することで混合コンテンツを検出します。Browser Testとセキュリティスキャンの両方が、ページ自体はHTTPSで配信されているにもかかわらずhttp://で始まるリクエストにフラグを立てます。これはHTMLソースの静的な走査ではなく、実際に取得されたネットワークリクエストに基づいているため、マークアップに直接ハードコードされたリソースだけでなく、ページの描画後にJavaScriptによって動的に読み込まれるリソースも検出できます。

修正方法

1. ハードコードされたhttp:// URLをhttps://に置き換える

変更前: ハードコードされたhttp://の画像URLtypescript

1<img src="http://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

変更後: httpsで配信、またはホストが両方に対応していればプロトコル相対で記述typescript

1<img src="https://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

2. 保険としてupgrade-insecure-requestsを追加する

このCSPディレクティブは、残ってしまったhttp://リクエストを送信前に自動的にhttps://へ書き換えるようブラウザに指示し、見落としたURLを補ってくれます。ただしこれは、そのホスト上でリソースが実際にHTTPS経由で取得可能な場合にのみ機能します。

取り残されたhttp://リクエストを自動的にhttps://へアップグレードするtypescript

1Content-Security-Policy: upgrade-insecure-requests

3. サードパーティの埋め込みを個別に監査する

自分では直接コントロールできない混合コンテンツの原因として最も多いのはサードパーティのスクリプトやウィジェットです。それぞれのドキュメントでHTTPS対応の埋め込みURLがあるか確認し、提供されていないものは削除してください。

4. ユーザー投稿コンテンツ内のプロトコルをサニタイズまたは書き換える

ユーザーがURLを含むコンテンツを投稿できる場合は、貼り付けられたプロトコルをそのまま描画するのではなく、描画時にhttp://をhttps://に書き換える(あるいは投稿自体を拒否する)ようにしてください。

Scanverraがこれをどう検出するか

ScanverraのBrowser Testとセキュリティスキャンの両方が、実際のブラウザでページの実際のネットワークリクエストを取得し、HTTPSで配信されているページ上でhttp://から始まるリクエストにフラグを立てます。これはソースのテキスト検索ではなく、実際のトラフィックに対する本物のランタイムチェックです。