鍵穴を覗き込む攻撃者を見逃すな：Mixed Contentが招く「XSSの特等席」
現場でインシデント対応をしていると、往々にして「HTTPS化してるから大丈夫」という慢心に出くわす。だが、少しばかりの知識がある攻撃者にとって、HTTPSのサイト内に混在するHTTPリソース（Mixed Content）は、まさに「鍵のかかった頑丈なドアに、わざわざ裏口の窓を全開にしておく」ようなものだ。
今日は、この「Mixed Content」がなぜXSSの踏み台になるのか、そして現代のエンジニアが最低限備えておくべき防壁について、泥臭い実務の視点から解説する。
—
1. なぜMixed Contentは「XSSの温床」になるのか
まず前提として、ブラウザはHTTPS通信で保護されたページ内にHTTPリソース（スクリプトや画像、CSS）が読み込まれることを非常に嫌う。なぜなら、そのHTTP通信は暗号化されておらず、通信経路上の攻撃者が容易にデータを改ざんできるからだ。
攻撃者の視点で考えてみよう。もし君のサイトのHTMLの中に という記述が残っていたらどうなるか？
1. 中間者攻撃（MitM）: 攻撃者は通信経路でそのJSファイルを傍受し、悪意あるコード（クッキー盗聴や画面改ざん）を混入させる。
2. スクリプト実行: ブラウザは「HTTPSページ内だから」といって油断せず、その改ざんされたJSをDOM上で実行してしまう。
3. XSS成立: これが「Mixed Contentを起点としたXSS」だ。
たとえメインのサイトが完璧にセキュアでも、CDNや古い社内ライブラリの読み込み元がHTTPのままであれば、そこが攻撃の突破口になる。
—
2. 現代の鉄壁：Upgrade-Insecure-Requests
「HTTPでの読み込みを片っ端からHTTPSに書き換える」などという手作業は、エンジニアの仕事ではない。ブラウザの力とCSP（Content Security Policy）を信じろ。
Upgrade-Insecure-Requests は、ブラウザに対し「このサイト内のHTTPリソースへのリクエストを、自動的にHTTPSへ昇格させてくれ」と命じる強力なディレクティブだ。
Nginxでの実装例
Webサーバー（Nginx）の設定でヘッダーを送るのが最も手っ取り早く、確実だ。
nginx.conf または 各サイトのconfファイル
server {
# … 他の設定 …
# すべてのレスポンスにCSPヘッダーを付与
# upgrade-insecure-requests: HTTPを自動でHTTPSに昇格
# default-src ‘self’: 外部からのスクリプト読み込みを原則禁止（信頼できるドメインのみ許可）
add_header Content-Security-Policy “upgrade-insecure-requests; default-src ‘self’; script-src ‘self’ https://trusted.cdn.com;”;
}
この設定を入れるだけで、仮にコード上に http://... と書いてあっても、ブラウザは裏で勝手に https://... に書き換えて通信してくれる。もしHTTPSでの提供がないリソースなら、ブラウザは「安全じゃないから」と読み込み自体をブロックする。これで一発だ。
—
3. アプリケーション層からの防御（CSPの動的制御）
もし君がPHPやPythonで動的なWebアプリケーションを書いているなら、アプリケーション側でヘッダーを制御する方法も覚えておくといい。
PHPでの実装例
セキュアなページへようこそ
“;
?>
Python (Flask) での実装例
from flask import Flask, make_response
app = Flask(__name__)
@app.after_request
def add_security_headers(response):
# すべてのレスポンスに強制的にCSPを付与する
response.headers[‘Content-Security-Policy’] = “upgrade-insecure-requests; default-src ‘self’;”
return response
@app.route(‘/’)
def index():
return “Secure Content”
—
4. 現場のシニアエンジニアからの「最後の忠告」
実務でMixed Contentを撲滅する際、必ず以下の手順を踏んでほしい。
1. Report-Onlyモードの活用: いきなりCSPを本番適用して「サイトの画像が全部消えた！」と泣きつかれるのは、新人のよくある失敗だ。まずは Content-Security-Policy-Report-Only を使い、ブラウザが何をブロックしようとしているかログを監視しろ。
2. サードパーティの棚卸し: 広告タグや解析ツール、古いjQueryのCDNなど、外部リソースを見直せ。HTTPSに対応していないサードパーティは、今の時代「リスクそのもの」だ。
3. 常に「ゼロトラスト」の精神で: ブラウザのアップグレード機能に依存しつつも、コード自体は常に絶対パスでHTTPSを指定する習慣をつけること。
セキュリティは「魔法の杖」を振って終わりではない。日々のコードレビューと、こうした泥臭い設定の積み重ねが、君のサービスを最後まで守り抜く唯一の手段だ。
さあ、今すぐサーバーのログを確認して、HTTPへの未練を断ち切ってこようぜ。健闘を祈る。
コメント