HTTPセキュリティの新常識！CSP upgrade-insecure-requestsを活用しよう

2025-06-01

"upgrade-insecure-requests" は、Webサイトがブラウザに対して、そのページ内で読み込まれるすべてのHTTPリソース（画像、スタイルシート、スクリプト、フレームなど）を自動的にHTTPSにアップグレードしてリクエストするように指示するディレクティブ（指示）です。

平たく言うと、「このページで使われているHTTPのファイルは、もしHTTPSの同じ場所にあれば、そっちを使ってね！」とブラウザにお願いするようなものです。

なぜこれが必要なのでしょうか？

Webサイト全体をHTTPS化することは、セキュリティを高める上で非常に重要です。しかし、古いWebサイトや外部のサービス連携など、どうしてもHTTPのリソースが残ってしまう場合があります。

HTTPは通信内容が暗号化されないため、途中で盗聴や改ざんされるリスクがあります。HTTPSはHTTPに暗号化（TLS/SSL）を加えたもので、安全な通信を提供します。

"upgrade-insecure-requests" を設定することで、以下のようなメリットがあります。

移行の促進
WebサイトをHTTPSに移行する過程で、完全にすべてのリソースをHTTPSにする前に、段階的にセキュリティを向上させることができます。
ユーザー体験の向上
最新のブラウザでは、Mix Contentがあるページは警告が表示されたり、リソースの読み込みがブロックされたりする場合があります。"upgrade-insecure-requests" は、そのような問題を回避し、スムーズなユーザー体験を提供します。
セキュリティの向上
HTTPで読み込まれる可能性のあるリソースを自動的にHTTPSにアップグレードすることで、Mix Content（HTTPSのページにHTTPのリソースが混在すること）によるセキュリティリスクを軽減できます。

どのように使うのでしょうか？

HTTPレスポンスヘッダーに、以下のように記述します。

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

このヘッダーをサーバーが送信することで、対応しているブラウザはページ内のHTTPリクエストを自動的にHTTPSに書き換えて送信します。

古いブラウザの中には、"upgrade-insecure-requests" に対応していないものもあります。
このディレクティブは、あくまでブラウザにアップグレードを「お願い」するものです。もしHTTPS版のリソースが存在しない場合、リクエストは失敗します。

一般的なエラーとトラブルシューティング

- エラー
  ブラウザの開発者ツール（ConsoleタブやNetworkタブ）に、HTTPでリクエストしようとしたリソース（画像、CSS、JavaScriptなど）が読み込めなかったというエラー（例: net::ERR_CONNECTION_REFUSED, net::ERR_SSL_PROTOCOL_ERROR など）が表示される。
- 原因
  "upgrade-insecure-requests" が有効になっているため、ブラウザはHTTPのリクエストをHTTPSに自動的にアップグレードしますが、そのHTTPSのURLに実際のリソースが存在しない場合に発生します。
- トラブルシューティング
  - まず、読み込みに失敗しているリソースのHTTPSのURLが存在するかどうかを確認してください。ブラウザのアドレスバーに https://[問題のあったドメイン]/[リソースのパス] を直接入力してアクセスできるか試してみましょう。
  - もしHTTPS版が存在しない場合は、以下のいずれかの対応が必要です。
    - そのリソースをHTTPSで提供するようにサーバー側を修正する。
    - そのリソースへの参照を削除するか、HTTPSで提供されている別のリソースに置き換える。
    - 一時的な対応として、CSPから "upgrade-insecure-requests" を削除するか、問題のあるリソースに対してのみCSPのルールを緩和する（ただし、セキュリティリスクが増加するため推奨されません）。
Mixed Content Blocking (混合コンテンツのブロック)
- エラー
  ブラウザの開発者ツール（Consoleタブ）に、"Mixed Content: The page at '[あなたのHTTPSページのURL]' was loaded over HTTPS, but requested an insecure resource '[HTTPのリソースのURL]'. This request has been blocked; the content must be served over HTTPS." のようなメッセージが表示され、HTTPのリソースがブロックされる。
- 原因
  これは "upgrade-insecure-requests" が有効になっているブラウザが、HTTPSのページ内でHTTPのリソースを検知し、セキュリティ上の理由から読み込みをブロックするために発生します。意図的にHTTPのリソースを使おうとしている場合に発生します。
- トラブルシューティング
  - 本当にそのHTTPのリソースが必要かどうか再検討してください。可能であれば、HTTPS版のリソースを使用するように変更してください。
  - もし外部のHTTPリソースに依存している場合は、その提供元にHTTPSでの提供を依頼するか、別のHTTPSで提供されている代替のリソースを探すことを検討してください。
  - CSPの設定を見直し、意図的にHTTPリソースの読み込みを許可する必要がある場合は、特定のドメインに対してのみ例外を設定するなどの方法がありますが、セキュリティリスクを十分に理解した上で行う必要があります（例: Content-Security-Policy: default-src https: 'self' [許可するHTTPドメイン]; upgrade-insecure-requests;）。しかし、"upgrade-insecure-requests" の目的からすると、これは推奨される解決策ではありません。
古いブラウザでの動作
- エラー
  古いブラウザでは "upgrade-insecure-requests" を認識しないため、HTTPのリクエストがそのまま送信され、Mix Contentの警告やエラーが発生する可能性があります。
- 原因
  "upgrade-insecure-requests" は比較的新しいCSPディレクティブであるため、古いブラウザは対応していません。
- トラブルシューティング
  - 古いブラウザのサポート状況を考慮する必要がある場合は、サーバー側でコンテンツネゴシエーションを行い、クライアントの環境に応じて適切なプロトコルでリソースを提供するなどの対策が必要になる場合があります。
  - または、段階的なHTTPS移行戦略を取り、最終的にはHTTPSのみをサポートする方向へ進むことを検討してください。
  - ユーザーにブラウザのアップデートを推奨することも有効な手段です。
CSPの記述ミス
- エラー
  CSPヘッダーの記述に誤りがある場合、"upgrade-insecure-requests" が正しく認識されず、期待通りに動作しないことがあります。
- 原因
  スペルミス、セミコロンの忘れ、不要な空白などが原因でCSPディレクティブが正しく解析されないことがあります。
- トラブルシューティング
  - CSPヘッダーの記述を注意深く確認し、文法的な誤りがないかチェックしてください。
  - CSPのバリデーターツールなどを利用して、記述が正しいか確認することも有効です。

トラブルシューティングの一般的な手順

ブラウザの開発者ツールを確認する
ConsoleタブやNetworkタブには、エラーメッセージやリクエストの詳細が表示されるため、問題の原因を特定する上で非常に重要です。
CSPヘッダーの設定を確認する
サーバーの設定やミドルウェアの設定を確認し、CSPヘッダーが正しく送信されているかを確認します。
HTTPSの動作確認
問題が発生しているリソースのHTTPS版URLに直接アクセスできるか確認します。
異なるブラウザでテストする
特定のブラウザでのみ問題が発生する場合は、そのブラウザ固有の問題である可能性があります。
CSPバリデーターを利用する
CSPの構文が正しいかオンラインのバリデーターツールで確認します。

サーバーサイドでのCSPヘッダー設定 (例: Node.js + Express)

Node.jsとExpressフレームワークを使用している場合の例です。

const express = require('express');
const app = express();

app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', 'upgrade-insecure-requests;');
  next();
});

app.get('/', (req, res) => {
  res.send('<h1>Hello World!</h1><img src="http://example.com/image.jpg" alt="HTTP画像">');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

この例では、すべてのリクエストに対して、ミドルウェアで Content-Security-Policy ヘッダーを設定しています。値として 'upgrade-insecure-requests;' を指定することで、このページを読み込んだブラウザは、ページ内の http://example.com/image.jpg へのリクエストを自動的に https://example.com/image.jpg にアップグレードしようとします。もし https://example.com/image.jpg が存在すれば画像は表示されますが、存在しなければ読み込みに失敗します。

サーバーサイドでのCSPヘッダー設定 (例: Python + Flask)

PythonとFlaskフレームワークを使用している場合の例です。

from flask import Flask, render_template

app = Flask(__name__)

@app.after_request
def add_csp_header(response):
    response.headers['Content-Security-Policy'] = 'upgrade-insecure-requests;'
    return response

@app.route('/')
def index():
    return render_template('index.html', image_url='http://example.com/image.jpg')

if __name__ == '__main__':
    app.run(debug=True)

templates/index.html の内容例:

<!DOCTYPE html>
<html>
<head>
    <title>Hello</title>
</head>
<body>
    <h1>Hello World!</h1>
    <img src="{{ image_url }}" alt="HTTP画像">
</body>
</html>

Flaskの after_request デコレータを使って、すべてのレスポンスに Content-Security-Policy ヘッダーを追加しています。テンプレート内でHTTPのURL (http://example.com/image.jpg) を使用していますが、ブラウザはこれをHTTPSにアップグレードしようとします。

サーバーサイドでのCSPヘッダー設定 (例: PHP)

PHPでのシンプルな例です。

<?php
header("Content-Security-Policy: upgrade-insecure-requests;");
?>
<!DOCTYPE html>
<html>
<head>
    <title>Hello</title>
</head>
<body>
    <h1>Hello World!</h1>
    <img src="http://example.com/image.jpg" alt="HTTP画像">
</body>
</html>

PHPの header() 関数を使って、CSPヘッダーを設定しています。HTML内でHTTPの画像URLが使われていますが、ブラウザはHTTPSへのアップグレードを試みます。

CSPヘッダーの動的な生成

より複雑なアプリケーションでは、CSPヘッダーの内容を動的に生成する必要がある場合があります。例えば、特定の環境やユーザーに応じてCSPの内容を変更する場合などです。

// Node.js + Express の例

const express = require('express');
const app = express();

app.use((req, res, next) => {
  let cspValue = '';
  if (process.env.NODE_ENV === 'production') {
    cspValue = "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self'; upgrade-insecure-requests;";
  } else {
    cspValue = "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self'; upgrade-insecure-requests;";
  }
  res.setHeader('Content-Security-Policy', cspValue);
  next();
});

// ... (他のルート定義など)

この例では、Node.jsの環境変数 (NODE_ENV) に応じてCSPヘッダーの内容を変更しています。本番環境ではより厳格なポリシーを適用し、開発環境では開発の利便性のために緩いポリシーを設定するなどの目的で使われます。upgrade-insecure-requests はどちらの環境でも設定されています。

実際にHTTPリソースがHTTPSで利用可能かどうかは、サーバー側の設定や外部サービスの提供状況に依存します。"upgrade-insecure-requests" はあくまでブラウザにアップグレードを試みるように指示するだけです。
クライアントサイド（HTMLやJavaScript）で直接 "upgrade-insecure-requests" を設定するメカニズムはありません。CSPはあくまでサーバーからブラウザへの指示です。
これらの例は、サーバーサイドでHTTPレスポンスヘッダーに "Content-Security-Policy: upgrade-insecure-requests;" を設定する方法を示しています。

すべてのリソースをHTTPSで提供する (根本的な解決策)

欠点
大規模なサイトの場合、すべてのURLを更新するのに手間と時間がかかる可能性があります。
利点
これが最も安全で確実な方法です。"upgrade-insecure-requests" に依存する必要がなくなり、Mixed Contentの問題も根本的に解消されます。
プログラミング
- サーバー設定
  Webサーバー（Apache, Nginxなど）を適切に設定し、HTTPSを有効にします。これにはSSL/TLS証明書の取得と設定が含まれます。
- URLの更新
  HTML、CSS、JavaScript内のすべてのHTTP URLをHTTPS URLに更新します。これは手動で行うか、スクリプトを使って自動化することができます。
- 外部リソースの確認
  外部のCDNやAPIなどを利用している場合、それらがHTTPSで提供されているか確認し、HTTPSのURLを使用するように更新します。
説明
最も推奨される代替手段は、Webサイトで提供するすべてのリソース（HTML、CSS、JavaScript、画像、フォントなど）をHTTPS経由で提供することです。

Content Security Policy (CSP) の他のディレクティブを使用する

欠点
どのリソースがHTTPで提供されているかを正確に把握し、適切なCSPディレクティブを設定する必要があります。設定ミスがあると、Webサイトの機能が損なわれる可能性があります。
利点
より詳細なセキュリティポリシーを定義できます。特定のHTTPリソースのみを許可したり、完全にブロックしたりといった制御が可能です。
プログラミング
- default-src https
  これを設定すると、特に指定のないリソースタイプ（script, style, imgなど）のデフォルトのソースをHTTPSのみに制限します。
- script-src https:、style-src https:、img-src https: など
  特定のリソースタイプごとに許可するソースをHTTPSのみに限定します。
- block-all-mixed-content
  これは、HTTPSページ内のすべてのHTTPリソースの読み込みを完全にブロックします。"upgrade-insecure-requests" とは異なり、アップグレードを試みません。
説明
"upgrade-insecure-requests" の代わりに、CSPの他のディレクティブを組み合わせてより細かくセキュリティポリシーを制御する方法です。

例 (Node.js + Express)

app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', "default-src https: 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; block-all-mixed-content;");
  next();
});

この例では、デフォルトのソースとスクリプト、画像ソースをHTTPSに限定し、インラインスタイルを許可し、Data URIスキームの画像を許可し、さらに Mixed Content を完全にブロックしています。"upgrade-insecure-requests" は使用していません。

サーバーサイドでのリダイレクト

欠点
サーバーに追加のリクエスト処理の負荷がかかる可能性があります。また、すべてのHTTPリソースに対応するリダイレクトルールを適切に設定する必要があります。
利点
ブラウザに透過的にHTTPSに誘導できます。古いHTTPのリンクが残っていても、自動的にHTTPSでアクセスさせることができます。
プログラミング
- サーバー設定
  Webサーバーの設定ファイルやアプリケーションのコード内で、HTTPのリクエストを検知し、対応するHTTPS URLにリダイレクトするルールを記述します。
説明
HTTPでリクエストされたリソースに対して、サーバー側で301または302リダイレクトを行い、HTTPSの同じURLにクライアントを転送する方法です。

例 (Apache の .htaccess)

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

これは、HTTPでアクセスされたすべてのリクエストをHTTPSにリダイレクトするApacheの設定例です。

クライアントサイドでのリダイレクト (JavaScript)

欠点
JavaScriptが無効になっている環境では機能しません。また、最初のHTTPリクエストが発生するため、わずかながらセキュリティリスクが存在します。
利点
比較的簡単に実装できます。
プログラミング
- HTMLの <head> セクションなどにJavaScriptコードを追加し、window.location.protocol をチェックしてリダイレクト処理を行います。
説明
JavaScriptを使って、ページがHTTPで読み込まれた場合にHTTPSにリダイレクトする方法です。

例 (HTML 内の JavaScript)

<!DOCTYPE html>
<html>
<head>
  <title>リダイレクト</title>
  <script>
    if (window.location.protocol !== 'https:') {
      window.location.replace('https://' + window.location.host + window.location.pathname + window.location.search + window.location.hash);
    }
  </script>
</head>
<body>
  <h1>コンテンツ</h1>
  <p>このページはHTTPSで提供されます。</p>
</body>
</html>

どの方法を選ぶべきか？

最も推奨されるのは、すべてのリソースをHTTPSで提供することです。これが最も安全で、将来的なセキュリティリスクを減らすための根本的な解決策となります。

"upgrade-insecure-requests" は、HTTPSへの移行期間中や、外部のHTTPリソースを完全に制御できない場合に有効な手段です。

CSPの他のディレクティブを使用する場合は、セキュリティポリシーをより細かく制御できますが、適切な設定には注意が必要です。

サーバーサイドやクライアントサイドのリダイレクトは、HTTPアクセスをHTTPSに誘導するのに役立ちますが、完全な代替手段とは言えません。