【実践編】Chromeのプライバシーとセキュリティタブでセキュリティ問題を解決する方法【実例付き】

1 こんなエラー、出ていませんか？
2 プライバシーとセキュリティタブの開き方と基本操作
- 2.1 開き方
- 2.2 基本的なUI構成
3 証明書情報の確認方法
4 Mixed Contentの確認と修正
5 CSPエラーの確認と対処
6 5. 実務でのセキュリティトラブル解決事例
7 HTTPSへの移行チェックリスト
8 よくあるハマりポイントと解決策
9 セキュリティベストプラクティス
10 まとめ
11 参考リンク

こんなエラー、出ていませんか？

「Mixed Content」の警告が出て画像が表示されない
証明書エラーでサイトにアクセスできない
「Refused to load… violates CSP directive」というエラーメッセージ
HTTPSに移行したのに「保護されていません」と表示される

この記事では、Chrome DevToolsのプライバシーとセキュリティタブを使って、これらの問題を実際に解決する方法を、実例とともに解説します。

プライバシーとセキュリティタブの開き方と基本操作

開き方

デベロッパーツールを開く（F12 または Ctrl + Shift + I / Cmd + Option + I）
上部タブに「プライバシーとセキュリティ」があればクリック
なければ「>>」をクリックして「プライバシーとセキュリティ」を選択

基本的なUI構成

プライバシーとセキュリティタブは2つのセクションに分かれています：

プライバシーセクション

サードパーティCookieの制限と検査
Cookieのブロック状況

セキュリティセクション

ページのオリジン情報
HTTPSセキュリティ警告
オリジンの詳細と証明書情報

左側のサイドバーには、ページが読み込んでいるすべてのオリジン（ドメイン）が表示されます。

証明書情報の確認方法

証明書の詳細を表示する

プライバシーとセキュリティタブを開く
セキュリティセクションの概要で証明書表示をクリック

確認すべき重要な項目

① 発行先（Issued to / Subject）

証明書が発行されたドメイン名を確認します：

Common Name (CN): example.com
Subject Alternative Names (SAN): example.com, www.example.com

チェックポイント：

アクセスしているドメイン名と一致しているか
ワイルドカード証明書の場合：*.example.comのような表記

よくある問題：

ドメイン不一致：www.example.comにアクセスしているのに、証明書はexample.comのみ
サブドメイン問題：blog.example.comにアクセスしているのに、証明書に含まれていない

② 発行元（Issued by / Issuer）

認証局（CA）の情報を確認します：

Organization (O): Let's Encrypt
Common Name (CN): R3

主要なCA：

Let’s Encrypt（無料、自動更新可能）
DigiCert
Sectigo（旧Comodo）
GlobalSign

注意：

自己署名証明書の場合、発行者と発行先が同じになります
ブラウザは自己署名証明書を信頼しないため、警告が表示されます

③ 有効期限（Valid from / Valid to）

証明書が有効な期間を確認します：

Valid from: Monday, January 1, 2025 at 9:00:00 AM
Valid to: Thursday, April 1, 2025 at 8:59:59 AM

重要：

2020年9月以降、証明書の最長有効期限は398日（約13ヶ月）
有効期限切れの証明書は即座にエラーになります
期限切れ前に更新が必要（自動更新を推奨）

④ 証明書チェーン

証明書は階層構造になっています：

ルート証明書（Root CA）
  ↓
中間証明書（Intermediate CA）
  ↓
サーバー証明書（End-entity / Leaf Certificate）

確認方法：証明書タブで、詳細タブを確認

チェックポイント：

すべての証明書が信頼されているか
中間証明書が正しくインストールされているか

証明書エラーの種類と対処法

エラー1：NET::ERR_CERT_DATE_INVALID

原因：証明書の有効期限切れ、または有効期間前

対処法：

サーバー管理者に連絡して証明書を更新
Let’s Encryptの場合：certbot renewコマンドで更新
システムの日時が正しいか確認（クライアント側の問題の可能性）

エラー2：NET::ERR_CERT_COMMON_NAME_INVALID

原因：ドメイン名の不一致

対処法：

証明書のSANにアクセスしているドメインが含まれているか確認
ワイルドカード証明書を使用するか、マルチドメイン証明書を発行

エラー3：NET::ERR_CERT_AUTHORITY_INVALID

原因：信頼されていないCAが発行した証明書（自己署名証明書など）

対処法：

本番環境：信頼されたCAから証明書を取得
開発環境：ローカルにCA証明書をインストール（テスト目的のみ）

Mixed Contentの確認と修正

Mixed Contentの検出方法

方法1：プライバシーとセキュリティタブで確認

プライバシーとセキュリティタブを開く
セキュリティセクションに警告が表示されます：
- 「This page includes HTTP resources」
- 「Mixed Content: This page was loaded over HTTPS, but requested…」
左側のサイドバーで問題のあるオリジンを確認
- 赤い警告アイコンが表示されます

方法2：Consoleタブで確認

Consoleタブには詳細なエラーメッセージが表示されます：

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, 
but requested an insecure resource 'http://cdn.example.com/image.jpg'. 
This request has been blocked; the content must be served over HTTPS.

または、自動アップグレードされた場合：

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, 
but requested an insecure image 'http://cdn.example.com/image.jpg'. 
This content should also be served over HTTPS.

方法3：Networkタブで確認

ネットワークタブを開く
ページをリロード（Ctrl + RまたはCommand + R）
フィルターボックスに「http://」と入力
ステータスカラムに「(blocked:mixed-content)」または「(upgraded)」と表示されます

どのリソースが問題か特定する

ネットワークタブとプライバシーとセキュリティタブを併用します：

ネットワークタブ：どのリソースが読み込まれているか確認
イニシエータカラム：どのファイルがそのリソースを読み込んでいるか確認
プライバシーとセキュリティ：オリジンごとのセキュリティ状態を確認

例：

名前: image.jpg
ステータス: (blocked:mixed-content)
イニシエータ: index.html:45
タイプ: img

これは、index.htmlの45行目でHTTP画像を読み込もうとしていることを示します。

Mixed Contentの修正方法

方法1：URLをHTTPSに変更（推奨）

最も基本的で確実な方法です：

html

<!-- ❌ Mixed Content -->
<img src="http://example.com/image.jpg">
<script src="http://cdn.example.com/script.js"></script>
<link rel="stylesheet" href="http://cdn.example.com/style.css">

<!-- ✅ 修正後 -->
<img src="https://example.com/image.jpg">
<script src="https://cdn.example.com/script.js"></script>
<link rel="stylesheet" href="https://cdn.example.com/style.css">

確認方法：外部リソースのURLをブラウザで直接開いて、HTTPSでアクセスできるか確認

方法2：プロトコル相対URL

プロトコル部分を省略し、ページと同じプロトコルを使用します：

html

<!-- プロトコル相対URL -->
<img src="//example.com/image.jpg">
<script src="//cdn.example.com/script.js"></script>

動作：

HTTPSページから読み込む場合：https://example.com/image.jpg
HTTPページから読み込む場合：http://example.com/image.jpg

注意：

HTTPページ自体を作らない方針なら、明示的にhttps://と書く方が安全
ローカル開発（file://）では動作しない可能性があります

方法3：Upgrade-Insecure-Requests ヘッダー

HTTPヘッダーで自動アップグレードを指示します：

http

Content-Security-Policy: upgrade-insecure-requests

または、HTMLの<meta>タグで：

html

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

効果：

すべてのHTTPリソースを自動的にHTTPSへ変換
ブラウザが自動的にhttp://をhttps://に置き換えてリクエスト

注意：

リソースがHTTPSに対応していない場合は失敗します
あくまで応急措置であり、根本的にはソースコードを修正すべきです

方法4：外部リソースの置き換え

HTTPSに対応していない外部リソースは、別のものに置き換えます：

例1：CDNの変更

html

<!-- ❌ HTTPSに対応していないCDN -->
<script src="http://old-cdn.com/jquery.js"></script>

<!-- ✅ HTTPSに対応しているCDNに変更 -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

例2：自サーバーへのホスティング

html

<!-- ❌ 外部のHTTPリソース -->
<img src="http://external.com/logo.jpg">

<!-- ✅ 自サーバーにアップロード -->
<img src="https://yoursite.com/images/logo.jpg">

推奨CDN（すべてHTTPS対応）：

cdnjs.cloudflare.com
unpkg.com
jsdelivr.net
fonts.googleapis.com（Google Fonts）

CSPエラーの確認と対処

CSPエラーの検出方法

Consoleタブで確認

CSP違反は、Consoleタブに明確なエラーメッセージが表示されます：

Refused to load the script 'https://untrusted.com/script.js' 
because it violates the following Content Security Policy directive: 
"script-src 'self' https://trusted.com".

Refused to execute inline script because it violates the following 
Content Security Policy directive: "script-src 'self'". 
Either the 'unsafe-inline' keyword, a hash ('sha256-...'), 
or a nonce ('nonce-...') is required to enable inline execution.

Issues タブで確認（Chrome 84以降）

デベロッパーツールの3点リーダー→その他のツール→問題タブを開く
CSP違反が構造化された形で表示されます
違反したディレクティブ、ブロックされたURL、ソースコードの位置などが確認できます

CSPポリシーの確認方法

方法1：ネットワークタブで確認

ネットワークタブを開く
ページのHTMLドキュメント（通常は最初のリクエスト）をクリック
「ヘッダー」タブを開く
「レスポンスヘッダー」セクションでContent-Security-Policyを探す

例：

http

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.com; img-src *

方法2：Consoleで確認

Consoleで以下を実行：

javascript

console.log(document.querySelector('meta[http-equiv="Content-Security-Policy"]')?.content);

よくあるCSPエラーと対処法

エラー1：インラインスクリプトがブロックされる

エラーメッセージ：

Refused to execute inline script because it violates the following 
Content Security Policy directive: "script-src 'self'".

原因：

html

<!-- ❌ インラインスクリプト -->
<script>
  console.log('Hello');
</script>

<button onclick="doSomething()">クリック</button>

対処法1：外部ファイルに分離（推奨）

html

<!-- ✅ 外部ファイル化 -->
<script src="/js/app.js"></script>

<!-- ✅ イベントリスナーをJavaScriptで登録 -->
<button id="myButton">クリック</button>
<script src="/js/button-handler.js"></script>

button-handler.js:

javascript

document.getElementById('myButton').addEventListener('click', function() {
  doSomething();
});

対処法2：nonceを使用（動的ページ向け）

サーバー側でランダムなnonceを生成：

html

<!-- サーバー側でnonceを生成 -->
<meta http-equiv="Content-Security-Policy" 
      content="script-src 'self' 'nonce-2726c7f26c'">

<!-- スクリプトに同じnonceを付与 -->
<script nonce="2726c7f26c">
  console.log('Hello');
</script>

注意：nonceはページ表示ごとに変更する必要があります

対処法3：hashを使用（静的ページ向け）

スクリプトのSHA-256ハッシュを計算してCSPに登録：

html

<meta http-equiv="Content-Security-Policy" 
      content="script-src 'self' 'sha256-abc123...'">

<script>
  console.log('Hello');
</script>

ハッシュ値の取得方法：

Consoleのエラーメッセージに表示される
または、以下のコマンドで計算：

bash

echo -n "console.log('Hello');" | openssl dgst -sha256 -binary | openssl base64

エラー2：外部ドメインからのリソース読み込みがブロックされる

エラーメッセージ：

Refused to load the script 'https://cdn.example.com/script.js' 
because it violates the following Content Security Policy directive: 
"script-src 'self'".

対処法：CSPに外部ドメインを追加

http

<!-- ❌ 現在のCSP -->
Content-Security-Policy: default-src 'self'; script-src 'self'

<!-- ✅ 外部ドメインを追加 -->
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com

複数ドメインの場合：

http

Content-Security-Policy: script-src 'self' https://cdn.example.com https://analytics.example.com

すべてのドメインを許可（非推奨）：

http

Content-Security-Policy: script-src *

注意：セキュリティが大幅に弱まるため、本番環境では避けるべきです

エラー3：Google Fonts / Google Analyticsがブロックされる

エラーメッセージ：

Refused to load the stylesheet 'https://fonts.googleapis.com/css2?family=Roboto'
because it violates the following Content Security Policy directive: "style-src 'self'".

対処法：Google関連のドメインをCSPに追加

http

Content-Security-Policy: 
  default-src 'self';
  style-src 'self' https://fonts.googleapis.com;
  font-src https://fonts.gstatic.com;
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  img-src 'self' https://www.google-analytics.com data:;
  connect-src 'self' https://www.google-analytics.com

エラー4：eval()がブロックされる

エラーメッセージ：

Refused to evaluate a string as JavaScript because 'unsafe-eval' 
is not an allowed source of script.

原因：

javascript

// ❌ eval()の使用
eval("console.log('Hello')");
new Function("console.log('Hello')")();
setTimeout("console.log('Hello')", 1000);

対処法1：eval()を使わない（推奨）

javascript

// ✅ 直接実行
console.log('Hello');

// ✅ 関数を渡す
setTimeout(function() {
  console.log('Hello');
}, 1000);

対処法2：’unsafe-eval’を許可（非推奨）

http

Content-Security-Policy: script-src 'self' 'unsafe-eval'

注意：XSS攻撃のリスクが高まるため、できる限り避けるべきです

CSPの段階的な導入

ステップ1：Report-Onlyモードで検証

本番環境で影響を確認してから適用します：

http

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted.com; report-uri /csp-report

効果：

ブロックはせず、違反をレポートのみ
実際の影響を事前に確認できる

ステップ2：レポートを収集

違反が発生すると、指定したエンドポイントにPOSTリクエストが送信されます：

json

{
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "violated-directive": "script-src 'self'",
    "blocked-uri": "https://evil.com/malicious.js",
    "line-number": 42,
    "source-file": "https://example.com/page.html"
  }
}

ステップ3：ポリシーを調整

レポートを分析して、正当なリソースをホワイトリストに追加：

http

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://trusted.com https://cdn.example.com;
  img-src * data:;
  report-uri /csp-report

ステップ4：本番環境に適用

問題がなければ、Report-Onlyを外して本番適用します。

5. 実務でのセキュリティトラブル解決事例

事例1：HTTPSに移行したらCDNの画像が表示されない

問題の状況

サイトをHTTPSに移行したが、一部の画像が表示されなくなった。
Consoleには「Mixed Content」の警告が表示されている。

原因の特定

プライバシーとセキュリティタブで確認
- セキュリティセクションに「This page includes HTTP resources」の警告
Consoleタブで確認

   Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, 
   but requested an insecure image 'http://cdn.oldprovider.com/image.jpg'. 
   This request has been blocked.

問題の特定
- 使用しているCDNがHTTPSに対応していない
- ソースコードでHTTPでハードコーディングされている

解決方法

方法1：HTTPS対応のCDNに変更

html

<!-- ❌ 変更前 -->
<img src="http://cdn.oldprovider.com/image.jpg">

<!-- ✅ 変更後：Cloudflareなどに変更 -->
<img src="https://cdn.cloudflare.com/yourproject/image.jpg">

方法2：自サーバーにホスティング

html

<!-- ✅ 自サイトにアップロード -->
<img src="https://example.com/images/image.jpg">

方法3：一括置換スクリプト

データベースやCMSのコンテンツに古いURLが残っている場合：

sql

-- WordPressの例
UPDATE wp_posts 
SET post_content = REPLACE(post_content, 
  'http://cdn.oldprovider.com/', 
  'https://cdn.newprovider.com/')
WHERE post_content LIKE '%http://cdn.oldprovider.com/%';

再発防止策

今後はプロトコル相対URL（//cdn.example.com/）を使用
または、環境変数でCDN URLを管理

事例2：証明書エラーが出る（有効期限切れ）

問題の状況

サイトにアクセスすると「NET::ERR_CERT_DATE_INVALID」エラーが表示される。
ページが表示されず、ユーザーからの問い合わせが急増している。

原因の特定

プライバシーとセキュリティタブで証明書を確認
- 「View certificate」をクリック
- Valid toの日付が過去になっている
確認結果

   Valid from: Monday, January 1, 2024 at 9:00:00 AM
   Valid to: Wednesday, April 1, 2024 at 8:59:59 AM  ← 期限切れ！

解決方法

Let’s Encryptの場合

bash

# サーバーにSSH接続
ssh user@yourserver.com

# 証明書を更新
sudo certbot renew

# Nginxの場合：設定をリロード
sudo systemctl reload nginx

# Apacheの場合
sudo systemctl reload apache2

他のCAの場合

CA管理画面にログイン
証明書を再発行
新しい証明書をサーバーにインストール
Webサーバーを再起動

再発防止策

自動更新の設定（Let’s Encrypt）

bash

# 自動更新のcronジョブを確認
sudo cat /etc/cron.d/certbot

# 手動で追加する場合
sudo crontab -e

# 毎日2回チェック（0時と12時）
0 0,12 * * * certbot renew --quiet

有効期限のモニタリング

有効期限の30日前にアラートを設定
監視ツール（Datadog、Mackerel等）を使用
SSL証明書監視サービス（SSL Labs等）を利用

事例3：Google Fontsが読み込めない（CSPでブロック）

問題の状況

サイトでGoogle Fontsを使用しているが、フォントが表示されない。
デフォルトのシステムフォントで表示されてしまう。

原因の特定

Consoleタブで確認

   Refused to load the stylesheet 'https://fonts.googleapis.com/css2?family=Roboto' 
   because it violates the following Content Security Policy directive: 
   "style-src 'self'".

問題の特定
- CSPでstyle-src 'self'のみ許可している
- Google Fontsのドメインが許可されていない

解決方法

CSPポリシーの修正

サーバー設定ファイル（Nginx）の場合：

nginx

# ❌ 変更前
add_header Content-Security-Policy "default-src 'self'; style-src 'self'" always;

# ✅ 変更後
add_header Content-Security-Policy "default-src 'self'; style-src 'self' https://fonts.googleapis.com; font-src https://fonts.gstatic.com" always;

Apacheの場合（.htaccess）：

apache

# ✅ Google Fonts対応
Header set Content-Security-Policy "default-src 'self'; style-src 'self' https://fonts.googleapis.com; font-src https://fonts.gstatic.com"

HTMLの<meta>タグの場合：

html

<meta http-equiv="Content-Security-Policy" 
      content="default-src 'self'; 
               style-src 'self' https://fonts.googleapis.com; 
               font-src https://fonts.gstatic.com">

設定後の確認

ブラウザのキャッシュをクリア（Ctrl + Shift + Delete）
ページをリロード（Ctrl + F5でハードリロード）
Consoleでエラーが消えたか確認
フォントが正しく表示されているか確認

HTTPSへの移行チェックリスト

移行前の準備

SSL/TLS証明書の取得
- Let’s Encrypt（無料）またはCA選定
- ドメイン所有権の確認
- 証明書のインストール
内部リンクの確認
- データベース内のURLをチェック
- ハードコーディングされたHTTP URLを洗い出し
外部リソースの確認
- CDN、画像、スクリプトなどがHTTPSに対応しているか
- 対応していない場合は代替案を検討

移行時の作業

すべての内部リンクをHTTPSに変更

sql

  -- WordPressの一括変換例
  UPDATE wp_options SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com');
  UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');
  UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://example.com', 'https://example.com');

外部リソースをHTTPSに変更
- 画像、CSS、JavaScriptのURL確認
- CDNのプロトコルをHTTPSに変更
HTTPからHTTPSへの301リダイレクト設定 Nginx:

nginx

  server {
      listen 80;
      server_name example.com www.example.com;
      return 301 https://$server_name$request_uri;
  }

Apache (.htaccess):

apache

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

Cookieの設定を更新
- Secure属性を追加（HTTPS通信のみでCookieを送信）
- SameSite属性も設定推奨

php

  // PHP の例
  setcookie('session_id', $value, [
      'secure' => true,      // HTTPS のみ
      'httponly' => true,    // JavaScript からアクセス不可
      'samesite' => 'Lax'    // CSRF 対策
  ]);

HSTS（HTTP Strict Transport Security）の設定 Nginx:

nginx

  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache:

  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

注意：HSTSを有効にすると、指定期間中はHTTPアクセスが完全にブロックされます

移行後の確認

プライバシーとセキュリティタブで確認
- Mixed Contentの警告がないか
- 証明書情報が正しいか
- すべてのリソースがHTTPSで読み込まれているか
ネットワークタブで確認
- すべてのリクエストがHTTPSか
- (blocked:mixed-content)がないか
コンソールタブで確認
- Mixed Contentやセキュリティ関連のエラーがないか
主要ブラウザでテスト
- Chrome
- Firefox
- Safari
- Edge
モバイルでも確認
- スマートフォン（iOS / Android）
- タブレット
外部ツールでチェック
- SSL Labs Server Test：証明書とTLS設定の評価（A+を目指す）
- Why No Padlock：Mixed Contentの検出
- Chrome Lighthouse：セキュリティスコアの確認
SEO対策
- Google Search Consoleでサイトマップを更新
- HTTPSバージョンをプロパティとして追加
- アドレス変更ツールを使用（必要に応じて）
アナリティクスの設定更新
- Google AnalyticsのデフォルトURLをHTTPSに変更
- その他の解析ツールも更新

よくあるハマりポイントと解決策

ハマりポイント1：ローカル開発環境での証明書エラー

問題：

NET::ERR_CERT_AUTHORITY_INVALID
この接続ではプライバシーが保護されません

原因：

localhostや自己署名証明書を使用している
ブラウザが証明書を信頼していない

解決策：

方法1：mkcertを使用（推奨）

bash

# mkcertのインストール（Mac）
brew install mkcert

# ローカルCAをインストール
mkcert -install

# localhost用の証明書を生成
mkcert localhost 127.0.0.1 ::1

# 生成されたファイル
# - localhost+2.pem （証明書）
# - localhost+2-key.pem （秘密鍵）

Webサーバーの設定（Nginxの例）：

nginx

server {
    listen 443 ssl;
    server_name localhost;
    
    ssl_certificate /path/to/localhost+2.pem;
    ssl_certificate_key /path/to/localhost+2-key.pem;
    
    # その他の設定...
}

方法2：Chromeで警告を無視（開発時のみ）

証明書エラーページで「詳細設定」をクリック
「localhost にアクセスする（安全ではありません）」をクリック

注意：本番環境では絶対に使用しない

ハマりポイント2：サブドメインで証明書エラー

問題：

メインドメイン（example.com）は問題ないが、
サブドメイン（blog.example.com）で証明書エラーが出る

原因：

証明書がサブドメインをカバーしていない

解決策：

方法1：ワイルドカード証明書を使用

Common Name: *.example.com

これでblog.example.com、shop.example.comなどすべてのサブドメインをカバーできます。

注意：*.example.comはexample.com自体をカバーしません。必要であれば両方を登録：

SANs: example.com, *.example.com

方法2：マルチドメイン証明書（SAN証明書）

複数のドメインを明示的に指定：

SANs: example.com, www.example.com, blog.example.com, shop.example.com

ハマりポイント3：HTTPリダイレクトループ

問題：

このページは動作していません
example.com でリダイレクトが繰り返し行われました。

原因：

リバースプロキシ（Nginx、Apache）とアプリケーション（WordPress等）の両方でリダイレクト設定
$_SERVER['HTTPS']の値が正しく取得できていない

解決策：

Nginxの設定に追加：

nginx

location / {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    
    # その他のproxy設定...
}

WordPressの場合（wp-config.php）：

php

// リバースプロキシ経由の場合
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

ハマりポイント4：Mixed ContentがConsoleに表示されない

問題：

画像が表示されないが、Consoleにエラーが出ない

原因：

ブラウザが自動的にHTTPSへアップグレードしている
アップグレード後、リソースが見つからない（404エラー）

確認方法：

ネットワークタブを開く
ステータスカラムを確認
(upgraded)と表示されていないかチェック
Status codeが404になっていないか確認

解決策：

リソースがHTTPSで実際にアクセス可能か確認
URLを直接ブラウザで開いてテスト

セキュリティベストプラクティス

本番リリース前のチェック

ステップ1：プライバシーとセキュリティタブで全確認

すべてのオリジンが緑の鍵アイコン
Mixed Contentの警告ゼロ
証明書が有効（有効期限を確認）

ステップ２：SSL Labsで外部チェック

SSL Labs Server TestでA+評価を目指します：

チェック項目：

証明書の信頼性
プロトコルサポート（TLS 1.2以上）
暗号スイートの強度
HSTS設定
脆弱性の有無

定期的な確認（運用フェーズ）

月次チェック

証明書の有効期限確認
- 有効期限の30日前にはアラート
- Let’s Encryptの自動更新が動作しているか確認
セキュリティヘッダーの確認
- HSTS
- Content-Security-Policy
- X-Content-Type-Options
- X-Frame-Options

週次チェック

Mixed Contentの監視
- 新しいページや機能追加後は必ずチェック
- CMSでコンテンツ追加時に古いHTTP URLが混入していないか
CSPレポートの確認
- Report-Uriで収集したレポートを分析
- 新しい違反パターンがないか確認

随時チェック

外部ライブラリの更新時
- CDN URLが変わっていないか
- CSPに新しいドメインを追加する必要がないか
新機能追加時
- サードパーティサービス（Google Maps、YouTube等）のHTTPS対応
- APIエンドポイントのHTTPS確認

CSPの段階的な厳格化

Phase 1：基本的なCSP（導入初期）

http

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src * data:

Phase 2：インラインを制限（中期）

http

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://trusted-cdn.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src https://fonts.gstatic.com;
  img-src 'self' https:

Phase 3：厳格なCSP（理想形）

http

Content-Security-Policy: 
  default-src 'none';
  script-src 'self' https://trusted-cdn.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src https://fonts.gstatic.com;
  img-src 'self' https: data:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self'

その他のセキュリティヘッダー

HTTPSとCSPに加えて、以下のヘッダーも設定推奨：

nginx

# HSTS（HTTP Strict Transport Security）
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# クリックジャッキング対策
add_header X-Frame-Options "SAMEORIGIN" always;

# MIMEタイプスニッフィング対策
add_header X-Content-Type-Options "nosniff" always;

# XSS対策（古いブラウザ向け）
add_header X-XSS-Protection "1; mode=block" always;

# リファラー制御
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# 権限ポリシー
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

セキュリティ監視ツールの活用

自動監視ツール

Mozilla Observatory：セキュリティヘッダーの包括的なチェック
Security Headers：HTTPヘッダーのセキュリティ評価
SSL Labs：SSL/TLS設定の評価
Qualys SSL Server Test：詳細な証明書チェック

継続的監視

javascript

// Sentryなどのエラー監視ツールでCSP違反を収集
// CSP Report-Uri エンドポイントの実装例（Node.js）
app.post('/csp-report', express.json({ type: 'application/csp-report' }), (req, res) => {
  console.log('CSP Violation:', req.body);
  
  // 違反をログに記録
  logger.warn('CSP Violation', {
    documentUri: req.body['csp-report']['document-uri'],
    violatedDirective: req.body['csp-report']['violated-directive'],
    blockedUri: req.body['csp-report']['blocked-uri']
  });
  
  res.status(204).end();
});