入口はきれい、奥は古い？——決済・銀行サイトの「ログイン系ホスト」を入口と比べた調査

この記事はエゴサる版にも掲載しています。

決済・銀行ブランド 341 ドメインについて、誰もが見る入口（フロント）と、ログインや API を担う「ログイン系ホスト」のセキュリティ設定を同じ物差しで観測し、同じブランドの中で両者がそろっているかを比べました。入口は良いのにログイン系が劣るドメインが、その逆より多いと言えるのは HSTS の欠落で 5.1 倍でした。TLS の版の指標では、差があるとは言えませんでした（ブランドごとに 1 件を無作為に選んだ場合）。


著者	中澤祐樹
調査	エゴサる（検索需要）／サイトスカウター Phase 5（受動観測）
観測期間	2026 年 10 月 26 日〜28 日
版	初版（2026 年 10 月 28 日）
やさしい版	小学生向けの漫画版「お店のサイトの『入口』と『奥のドア』」を別ページに用意しています

要旨

決済や銀行のサイトは、誰もが見るトップページ（入口）と、ログイン・取引・アプリ連携を担うホストが別々に運用されていることが多くあります。本調査は、ブランドとドメインの対応を 1 件ずつ確認した決済・銀行ブランドの入口 343 ホスト（341 ドメイン）と、同じブランドのログイン系ホスト 1,010 ホストを、まったく同じ受動観測（DNS・TLS ハンドシェイク・HTTP GET 各 1 回、版固定ハンドシェイク 4 回）で測り、ブランドごとに両者を突き合わせたものです。主な結果は次の 4 点です。

同じブランドの中で「入口は良いのにログイン系が劣る」が、その逆より多いと言えるのは HSTS。 ブランドごとにログイン系を 1 件無作為に選ぶ処理を 1,000 回繰り返した平均で、HSTS の欠落は 83.5 対 16.6（5.1 倍、95% 区間 3.9〜6.8。265 ドメイン）。古い TLS（1.0/1.1）の受け入れは 10.8 対 6.2（1.8 倍、1.1〜2.8）、TLS1.3 未対応は 24.1 対 17.1（1.4 倍、1.1〜1.9）（268 ドメイン）で、区間の下限が 1 倍に近く、ログイン系が 1 件だけのブランドでは逆転もする。TLS の 2 指標については、差があるとは言い切れない。
HSTS の欠落が最も大きな差。 ログイン系ホストの 45.2%（370/818）に HSTS が無く、入口（21.3%、71/334）の約 2 倍。ただしリダイレクト専用のホストが含まれる分は割り引いて読む必要がある。
ホスト名の先頭で傾向が違う。 mobile. merchant. online. my. id. で始まるホストは TLS1.3 未対応が 26.1〜32.5% と高く、login. auth. app. checkout. は 7.1〜12.2% と入口（17.5%）を下回る。古い端末・アプリ向けのホストほど更新が遅れている可能性がある。
「設定の古さ」は、公衆 Wi-Fi からのログインで現実の手口につながる。 ログイン系ホストのうち、HTTP で来ても HTTPS に転送しないものが 38（4.6%）、最初の応答で返された Cookie に Secure 属性が無いものが 29.7%（106/357）。HSTS 欠落と重なるホストが 44 あり、SSL ストリッピングでパスワードとセッションを同時に取られる条件がそろっている。公開バージョンに既知 CVE が当たるホストも 8（遠隔コード実行 2）。

本調査は 1 回の受動観測であり、個別サービスの安全性を評価するものではありません。攻撃の手口は公知の一般論として記述し、実在ホストに対して試したことはありません。ブランド名・ドメイン名は公開しません。

1. 背景と目的

入口はキャンペーンのたびに作り直されますが、奥のホストは古いアプリや端末との互換性を保つ必要があり、設定を変えにくい——そう考えると、「入口は最新、奥は古いまま」というズレが起きていてもおかしくありません。先行調査（決済・アプリの「使えない」検索需要と、入口ホストの露出の交差。決済・銀行920ホストのセキュリティ対策状況）では入口しか見ていませんでした。本調査の目的は、利用者が実際に ID とパスワードを送る先であるログイン系ホストについて、同じ物差しで入口との差を測ることです。

2. 方法

2.1 対象

先行調査でドメインを同定した決済・銀行ブランドの入口 370 ドメインについて、公開前に ブランドとドメインの対応を 1 件ずつ目視で確認しました。確認の手順は、(1) ドメインのトップページの題名と内容がそのブランド（または同一組織）の公式サイトか、(2) 同名の別業種・別国のサイトではないか、の 2 点です。結果は次のとおりです。

判定	ドメイン数	扱い
正しい	268	そのまま集計
誤り（別組織のサイトを拾っていた）	91	うち 75 は正しいドメインを特定し、入口とログイン系を同じ方法で再観測して差し替え。16 は特定できず除外
判断不能	11	除外

本稿の母数は、正しい 268 ＋差し替えた 75 ＝ 343 ホスト（341 ドメイン。決済 163・銀行 180 ホスト） です。誤りの多くは、ブランド名と同じ綴りの別業種・別国のドメインでした（名前は公開しません）。差し替え分の再観測は 10 月 28 日で、入口の観測だけはリダイレクトを追う通常の観測器で行っています（HSTS などは最終応答で判定）。

2.2 ログイン系ホストの選び方

人手で「ここがログイン画面」と決めるのではなく、機械的に 2 段階で集めました。

入口の証明書に書かれた別名（SAN）から、login. auth. id. secure. my. account. api. app. pay. checkout. などで始まる名前を拾う（追加の通信なし。58 ホスト）
同じ接頭辞 36 種を各ドメインに付けて DNS で引き、実在した名前を採用する（952 ホスト）。どんな名前でも応答してしまう「ワイルドカード DNS」のドメイン 20 件は除外

合わせて 1,010 ホストです（差し替えた 75 ドメインの分 163 ホストを含む）。

2.3 観測の内容

入口と完全に同じです。DNS 解決、TLS ハンドシェイク 1 回、HTTP GET 1 回（リダイレクトは追わない）、それに TLS 1.0 / 1.1 / 1.2 / 1.3 を 1 つずつ指定したハンドシェイク 4 回。ログイン画面に何かを入力したり、認証を試したりは一切していません。 サーバーが最初の応答で自ら返す情報だけを記録しています。

2.4 母数

名前は引けても 443 番で応答しないホストが 171 ありました（接続エラー・タイムアウト）。これらを除き、TLS を判定できた 822 ホスト、HTTP 応答のあった 818 ホストで集計しています。入口は TLS 337・HTTP 応答 334 ホストです。ブランド単位の比較は、入口とログイン系の両方を観測できた 268 ドメイン（決済 123・銀行 145。HSTS は 265）です。ログイン系ホストが複数あるブランドは、ホストを 1 件無作為に選ぶ処理を 1,000 回繰り返して平均を取り（乱数 seed 固定、95% 区間を併記）、ホストの数による偏りを避けています。「最も劣る値」で代表させる方法は、ホストが多いブランドほど不利に出るため採りませんでした（3.2 節、第 5 章）。

2.5 指標の定義

指標	意味	判定
旧版（TLS1.0/1.1）も受け入れる	古い暗号化方式でも接続を受け付ける。すべて TLS1.2 以上も話せるので「古い方式にも落とせる余地がある」という意味	版固定ハンドシェイクで 1.0 または 1.1 が成立
TLS1.3 に未対応	現行の推奨方式に未到達。問題ではなく「推奨未達」として別に数える	1.3 指定のハンドシェイクが不成立
HSTS が無い	ブラウザに「必ず HTTPS で来るように」と指示するヘッダが無い	応答ヘッダに `Strict-Transport-Security` が無い
製品のバージョンが見える	サーバー種別やバージョンを応答で明かしている	`Server` 等にバージョン文字列

「旧版のみ」（TLS1.2 以上を話せない）のホストは、TLS を判定できたログイン系 822 ホスト・入口 337 ホストのどちらにも 0 件でした（判定できなかったログイン系のうち 1 件は、TLS1.1 だけが応答して他の版がタイムアウトしたもので、旧版のみとは断定できません）。本稿で「旧版も受け入れる」と書くのはこのためで、「古い TLS でしか繋がらない」という意味ではありません。

3. 結果

3.1 ホスト単位：ログイン系は HSTS が無いことが倍

指標	入口（TLS 337／HTTP 応答 334）	ログイン系（TLS 822／HTTP 応答 818）
旧版も受け入れる	3.6%（12/337）	8.3%（68/822）
TLS1.3 に未対応	17.5%（59/337）	18.6%（153/822）
HSTS が無い	21.3%（71/334）	45.2%（370/818）
製品のバージョンが見える	8.7%（29/334）	4.5%（37/818）

入口もログイン系も、HTTP の応答が得られなかったホストは欠損として除外しています（HSTS・バージョンの分母。TLS 系は版固定ハンドシェイクで判定できたホスト）。

TLS1.3 未対応の差は 1 ポイント、旧版受入は 5 ポイント弱ですが、HSTS は倍の開きがあります。一方、バージョン露出はログイン系の方が少なく、「奥の方が何でも劣る」わけではありません。ログイン系ホストは応答が短い（301/302 のリダイレクトが 273、403 が 104）ため、そもそも明かす情報が少ないことも影響しています。

HSTS については注意が要ります。リダイレクトだけを返すホストや、ブラウザが直接開かない API 用ホストでは、HSTS を付けていない運用が珍しくありません。45.2% という数字には、その分が含まれます。それでも、ログインを担うホストでブラウザが HTTP で来てしまう余地を残すのは望ましくなく、「付けるべき所にも付いていない」比率は無視できない大きさだと考えています。

3.2 ブランド単位：差は HSTS で大きく、TLS では小さい

同じブランド（登録ドメイン）の中で、入口とログイン系がそろっているかを 2×2 で数えました。ログイン系が複数あるブランドは、1 件を無作為に選ぶ処理を 1,000 回繰り返し、各セルの平均と 95% 区間を出しています。

指標（n）	両方良い	入口は良い→ログイン系が劣る	入口が劣る→ログイン系は良い	両方劣る	比（右上÷左下）
旧版も受け入れる（268）	246.2	10.8（4.0%）[8–14]	6.2（2.3%）[4–8]	4.8	1.8 倍 [1.1–2.8]
TLS1.3 に未対応（268）	195.9	24.1（9.0%）[19–29]	17.1（6.4%）[13–21]	30.9	1.4 倍 [1.1–1.9]
HSTS が無い（265）	126.5	83.5（31.5%）[75–92]	16.6（6.3%）[12–21]	38.4	5.1 倍 [3.9–6.8]

比は、1,000 回それぞれの比を平均したものです。表の平均件数どうしを割った値とは、小数点以下で異なることがあります（例: HSTS は 83.5÷16.6＝5.0、表の比は 5.1）。

三つの指標とも平均では「入口は良いのにログイン系が劣る」が、その逆を上回ります。ただし、差があると言えるのは HSTS だけです。

HSTS は大きな差が残る: 83.5 対 16.6（5.1 倍）。区間（3.9〜6.8 倍）は 1 倍から大きく離れている。ログイン系が 1 件だけのブランド（37）に絞っても 13 対 0 で、過半数のホストと比べても 67 対 14（4.8 倍）。
旧版受入と TLS1.3 は、差があるとは言えない: 比は 1.4〜1.8 倍だが、区間の下限は 1.1 倍で、1 倍（差なし）に近い。ログイン系が 1 件だけのブランド（38）に絞ると、旧版受入が 2 対 3、TLS1.3 未対応が 4 対 3 で逆転・拮抗し、過半数のホストと比べても 9 対 5、17 対 15 にとどまる。該当する件数そのものも少ない（旧版受入は 268 ドメイン中、平均で右上 10.8・左下 6.2）。
同じ割合で入口とログイン系が劣っていても、ログイン系は複数のホストの中から「どれか 1 つが劣る」確率が高くなる。この数え方の偏りを除くと、TLS の差は 1.4〜1.8 倍まで小さくなり、HSTS の差は大きく残る。

つまり「入口は新しいのにログイン系は古い」という構図は、HSTS の運用では明確に言える一方、TLS の版では差があるとは言えない、というのが本調査の結論です。

参考: ログイン系が複数あるブランドを「最も劣る値」で代表させると、比は 4.8 倍（旧版）・5.7 倍（TLS1.3）・26 倍（HSTS）になります。これはホストが多いブランドほど「どれか 1 つが劣る」確率が上がる数え方の偏りで、本稿では採用していません。

3.3 決済と銀行で違うか

「入口は良い→ログイン系が劣る」÷「その逆」	決済（123）	銀行（145）
旧版も受け入れる	1.8 倍 [0.8–3.5]（7.1 対 4.3）	1.9 倍 [1.0–2.5]（3.7 対 2.0）
TLS1.3 に未対応	2.1 倍 [1.3–3.5]（11.4 対 5.7）	1.1 倍 [0.7–1.7]（12.8 対 11.5）
HSTS が無い	3.4 倍 [2.3–5.3]（33.1 対 10.0）	7.9 倍 [5.6–11.8]（50.6 対 6.6）

（HSTS の n は決済 123・銀行 142。括弧内は無作為 1 件選択の平均件数）

決済では TLS1.3 未対応の差がやや大きく（2.1 倍）、決済の TLS1.3 だけは区間（1.3〜3.5 倍）が 1 倍から離れています。銀行では 1.1 倍で区間が 1 倍をまたぎます。旧版受入は、決済が区間 0.8〜3.5 倍で 1 倍をまたぎ、銀行は下限がちょうど 1 倍で、どちらも差があるとは言えません。HSTS は決済 3.4 倍・銀行 7.9 倍で、どちらも区間ごと 1 倍から離れており、決済・銀行を問わず共通の傾向です。銀行の方が差が大きいのは、銀行の入口はほぼ HSTS を備えている一方、ログイン系では欠落が残るためです。

地域別（同じ無作為 1 件選択）でも、HSTS は米国 41 ドメインで 4.8 倍、欧州主要国 36 で 9.1 倍、その他 88 で 7.2 倍、国コード不明 96 で 4.0 倍と、どの地域でも大きな差が出ました。TLS の指標は地域で 1 倍前後から 2.7 倍まで幅があり、区間の多くが 1 倍をまたぎ、米国・欧州は件数が小さい（米国では逆向きの組み合わせが 0 件のため比を出せません）ので、差があるとは言えません。

地域はブランドの本拠（先行調査の地域ラベル）で分けています。日本（4 ドメイン）は件数が少なく率は出しません。HSTS の母数は 41＋36＋88＋96＋4＝265 で全体と一致します（TLS 系は 41＋35＋89＋99＋4＝268）。

3.4 ホスト名の先頭で傾向が違う

接頭辞（ホスト数）	TLS1.3 未対応	旧版も受け入れる
`mobile.`（40）	32.5%	10.0%
`merchant.`（26）	30.8%	19.2%
`online.`（27）	29.6%	3.7%
`my.`（21）	28.6%	19.0%
`id.`（23）	26.1%	13.0%
`m.`（59）	20.3%	5.1%
`pay.`（42）	19.0%	7.1%
`portal.`（32）	18.8%	0.0%
`api.`（167）	17.4%	4.8%
`secure.`（39）	15.4%	2.6%
`login.`（41）	12.2%	4.9%
`auth.`（45）	11.1%	11.1%
`payments.`（20）	10.0%	5.0%
`app.`（66）	7.6%	9.1%
`checkout.`（28）	7.1%	7.1%

（TLS を判定できたホストが 20 以上の接頭辞。20〜30 件の行は幅をもって読んでください）

mobile. merchant. online. my. id. は TLS1.3 未対応が 26.1〜32.5% と、入口（17.5%）を大きく上回ります。mobile. online. my. は古いスマートフォンアプリやネットバンキング専用クライアントの接続先として長く使われてきた名前で、「古い端末を切れないから新しい方式も入れられない」という事情が透けて見えます（merchant. は加盟店向けの管理画面や接続先で、同じく古いクライアントを抱えやすい名前です）。逆に login. auth. app. checkout. は 7.1〜12.2% と入口を下回り、近年整備された認証・決済画面の基盤は最新に近いと言えます。

4. 考察：「設定の古さ」は、どんな攻撃につながるのか

ここまでの指標は、それ自体が「穴」ではありません。意味を持つのは、利用者がカフェや駅の公衆 Wi-Fi からログインするような、通信経路に第三者が割り込める場面です。ログイン系ホストはまさにパスワードとセッション Cookie の宛先なので、入口よりも影響が直接です。

4.1 設定と手口の対応

観測した設定	つながる手口	成立する条件	根拠・基準
HSTS が無い	SSL ストリッピング: 利用者の最初の `http://` アクセスを、割り込んだ相手が平文のまま中継し、ログイン画面を偽装・盗聴する	利用者が `http://` で入る（URL 直打ち、古いリンク）＋経路に割り込める	OWASP Transport Layer Security Cheat Sheet。HSTS があれば 2 回目以降ブラウザが `https://` に書き換えるため成立しない
HTTP を HTTPS に転送しない	ストリッピングすら要らない。平文のログイン画面がそのまま出る	同上	同上
Cookie に Secure 属性が無い	ログイン後のセッション Cookie が `http://` 経路にも送られ、盗聴してなりすまし（セッションハイジャック）	ログイン後のページに `http://` の画像・リンクが 1 つでもある、または上のストリッピング	OWASP Session Management Cheat Sheet
Cookie に HttpOnly が無い	サイトに XSS が 1 つあれば、JavaScript から Cookie を持ち出せる	XSS の存在（経路への割り込みは不要）	同上
旧版（TLS1.0/1.1）も受け入れる	ダウングレード: 割り込んだ相手が「古い版しか話せない」ふりをして、既知の弱点がある暗号（CBC モードを狙う BEAST など、RC4）に落とす	経路に割り込める＋利用者側のアプリも旧版を許す	IETF RFC 8996（2021）で TLS1.0/1.1 は廃止。PCI DSS は、SSL および初期の TLS の使用を 2018 年 6 月 30 日以降認めていない（PCI SSC『Migrating from SSL and Early TLS』）
TLS1.3 に未対応	直接の手口はない。1.2 では RSA 鍵交換や古い暗号スイートを残せるため、「前方秘匿性が無い設定」の余地が残る	設定次第	推奨未達として別枠で扱う
製品のバージョンが見える	偵察が不要になる。公開済みの脆弱性情報（CVE）と攻撃手順をそのまま当てられる	該当バージョンに未修正の脆弱性がある	NVD 照合。PHP 5.4／5.6／7.4 はいずれもサポート終了

4.2 ログイン系ホストで、条件はどれくらい重なっているか

観測	ログイン系	入口	備考
HTTP を HTTPS に転送しない	38（4.6%）	5（1.5%）	応答のあった 818 / 334
Cookie に Secure 属性が無い	106（29.7%）	39（22.9%）	Cookie を観測できた 357 / 170 のみ
Cookie に HttpOnly が無い	172（48.2%）	65（38.2%）	同上
Secure 無しかつ HSTS 無し	44	9	ストリッピングでパスワードとセッションを同時に取られる条件
公開バージョンに既知 CVE	8（遠隔コード実行 2）	5（1）	古い nginx／Apache、サポート終了の PHP（8.1 以下）など

入口では「HTTPS に転送しない」が 5 ホストしかないのに、ログイン系では 38 あります。入口は HTTPS 化の点検を受けているが、api. や m. のような「人が直接開かないはず」のホストは点検の外にある、という構図です。しかし古いアプリやブックマークは、そのホストを http:// で開きに行きます。

一つの場面で言い換えると：カフェの Wi-Fi で、古いブックマークから http:// でログイン画面を開く。HSTS が無く転送もしないホストなら、同じ Wi-Fi にいる相手が画面を平文で中継でき、入力したパスワードはそのまま読めます。Secure の無い Cookie なら、ログイン後のセッションも同じ経路で取れます。これが 44 ホストで成立し得る組み合わせです。実際に試してはいません（第 5 章）。

5. 限界と注意

ログイン系ホストは機械的に選んだもので、実際にログイン画面を出しているかは確認していません。404 を返すホストが 143、リダイレクトだけのホストが 273 含まれます。本稿の「ログイン系」は「ブランドが認証・取引・API 用の名前で運用しているホスト」程度の意味です。
HSTS の欠落率には、リダイレクト専用・API 専用ホストの分が含まれます。 ブラウザが直接開かないホストに HSTS が無いこと自体は問題と言い切れません。
観測は 1 回の受動観測で、サービスの安全性を評価するものではありません。旧版受入や TLS1.3 未対応は「設定の古さ」の指標であり、それだけで攻撃が成立するわけではありません。
攻撃の手口は公知の一般論として書いています。本稿のホストに対して、ストリッピングやダウングレードを試したことは一切ありません。CVE の該当も「公開バージョン文字列と NVD の照合」であり、実際に攻撃可能かは確認していません。
Cookie の属性は、最初の応答で Cookie を返したホスト（357／170）でしか観測できません。 ログイン後に発行される本当のセッション Cookie は見ていないので、割合は「そのホストの Cookie 設定の傾向」として読んでください。
ブランド単位の比較は、ログイン系ホストの数に影響されます。 ホストが多いブランドは「どれか 1 つが劣る」確率が高くなるため、本稿は無作為 1 件選択の平均で比べました。それでも、ブランドごとのログイン系ホストの候補数は 1 件（49 ブランド）から 6 件以上（46 ブランド）まで幅があり、同じ重みでは扱えません。候補が 1 件で、かつ入口と両方を観測できたブランド（38、HSTS は 37）に絞った結果は 3.2 節に併記しています。
相関であって因果ではありません。 HSTS では入口が先に整備される構造を示唆しますが、各社の事情は観測していません。
ブランドとドメインの対応は目視で確認しましたが、人の判断であり、誤りが残る可能性はあります。差し替えた 75 ドメインの入口は、リダイレクトを追う通常の観測器で再観測しているため、入口の HSTS などは最終応答での判定です（ログイン系は追跡なしで統一）。
母数は、先行調査でドメインを同定できた大手寄りのブランドです。日本は対にできたドメインが 4 件と少なく、国内の傾向は語れません。
ブランド名・ドメイン名は公開しません。個別の機関を特定できる形での再配布も行いません。

6. 提言：運用者ができること

入口のスキャン結果だけを見て「うちは TLS1.3 対応・HSTS 済み」と安心している組織は、ログイン系・モバイル向け・API 向けのホストを同じ物差しで一度棚卸しすると、ズレが見つかる可能性があります。とくに mobile. online. my. のような古い世代の名前で残っているホストは、まず「まだ使われているか」から確認する価値があります。

点検の順番は、影響の直接さで決めるのが実務的です。

HTTP → HTTPS の転送と HSTS（できれば preload 登録）。これだけでストリッピング系の手口は閉じる
Cookie の Secure／HttpOnly／SameSite。セッションを扱うホストでは必須
TLS1.0／1.1 の無効化。カード決済を扱うホストでは、SSL・初期の TLS の使用が PCI DSS で認められていない
Server／X-Powered-By ヘッダのバージョン非表示と、EOL 製品の更新
TLS1.3 対応（推奨）

7. データと再現性

ブランドの一覧は、決済・銀行・小売などの「使えない」検索需要を 48 地域で集めた先行調査（決済・銀行920ホストのセキュリティ対策状況）から。入口の観測結果はサイトスカウター Phase 5（世界規模セキュリティ調査）の受動観測で、本稿のログイン系ホストも同じ観測器で測りました。
集計 CSV（名前を含まない区分別の件数）は本稿の付録として公開します。ブランド別の内訳は公開しません。
本稿の数値は 2026 年 10 月 26〜28 日の観測によるもので、各社の設定変更により変わります。

付録 A　用語

用語	本稿での意味
入口（フロント）	ブランドの主ドメインと `www.`。誰もが見るトップページ
ログイン系ホスト	証明書 SAN と接頭辞の DNS 解決で機械的に集めた、認証・取引・API 用の名前のホスト
受動観測	DNS 解決・TLS ハンドシェイク・HTTP GET 各 1 回と版固定ハンドシェイク 4 回で、サーバーが自ら返す情報だけを記録すること
旧版も受け入れる	版固定ハンドシェイクで TLS1.0 または 1.1 が成立したホスト。すべて TLS1.2 以上も受け入れる
推奨未達	TLS1.3 指定のハンドシェイクが成立しなかったホスト。問題あり率には含めない
HSTS	`Strict-Transport-Security` ヘッダ。ブラウザに以後 HTTPS のみで接続させる
SSL ストリッピング	最初の `http://` 接続を中間者が平文のまま中継し、HTTPS への移行を妨げる手口