Security Posture of the 920 Payment and Bank Sites People Search For — 13.4 Million Search Suggestions Joined with the Phase5 Survey

日本語版: 日本語版

Also published on Site Scouter and Egosaru.

Summary

• Across 48 regions and 20 languages, I collected 13.4 million search suggestions (9.28 million unique) for 3,472 payment, bank, retail and everyday-service brands, and observed the public configuration of the 920 sites that those suggestions point to, with one ordinary page load each. Each brand-to-site mapping was then checked by hand, and the 680 sites that passed form the basis of every figure in this article.
• Of the 269 payment and bank sites, 26.4% (71) had at least one of: no HSTS, an exposed server version, or an end-of-life version. The most common gap was missing HSTS (20.1%). 16.4% did not negotiate TLS 1.3; every site that answered used TLS 1.2 or better.
• No payment or bank site exposed an end-of-life PHP version. Across all 1,705 newly scanned hosts, only 18 (9 sites counting apex and www) disclosed a PHP version, and 5 of those (3 sites) were end-of-life. Compared with the general population in the Security Exposure Survey 2026, payment and bank sites either hide their version or keep it current.
• The share of suggestions carrying words such as “outage”, “payment failed” or “can’t log in” (the trouble-search ratio) was 0.29% of the 3.18 million suggestions returned for a brand name alone. The maximum for any brand was 10.0%, and more than half of all brands had none. Searches that complain about outages are rare in suggestions.
• Twenty good examples (Table A) and 92 sites with observed issues (Table B) are named. Table B records public facts — TLS settings and HTTP headers — and does not mean that any site was found to be exploitable.

1. Method

This article joins two surveys (Figure 1).

1. Suggestion collection (Egosaru). In 48 regions and 20 languages, I captured the suggestions shown by Google, Bing, Yahoo!, Yandex, Naver, Baidu, Daum and Shopee when a brand name is typed into the search box. Two kinds of seed were used: the brand name alone (“plain seed”) and the brand name plus a trouble word (“compound seed”). This produced 83,275 fetch jobs (83,016 completed, 259 failed) and 13,438,498 suggestions (9,280,238 unique), collected 24–26 October 2026.
2. Public-configuration observation (Site Scouter Phase5). For the brands that appeared, I identified their sites (5,408 candidate hosts, of which 2,842 answered DNS and HTTPS) and newly observed the 1,705 hosts not already in the earlier survey. Each observation consists of a DNS lookup, one TLS handshake and one HTTP GET — the same as opening the site once in a browser. No port scanning, vulnerability probing, authentication attempts or exploit traffic were involved. Observations ran 22–26 October 2026.
3. The two were joined at brand level, giving 9,181 brand × region × engine rows and 920 unique hosts. Every one of the 920 was then checked by hand to confirm that the host really is the brand’s official site; the 680 hosts that passed are the denominator used throughout (212 misidentified and 28 undeterminable hosts were excluded). All denominators in this article are host counts.

Figure 1. Survey pipeline (suggestion collection → domain identification → Phase5 observation → join)

Mapping a brand to its site was an automated process using exact (2,630) and partial (2,778) host-name matches, which picks unrelated sites with similar names. Checking all 920 hosts by hand found 212 (23.0%) that did not belong to the brand (for example “Hello bank” mapped to an unrelated site with a similar name, or “SMBC Nikko Securities” mapped to the bank’s site) and 28 that could not be determined. The errors cluster around generic brand names such as “Easy”, “Media” or “Wi-Fi” and around unrelated organisations with the same name. The aggregates in §4 and Tables A and B use only the 680 hosts that passed this check. The measured settings of the excluded hosts are themselves valid, but they were dropped because the industry and country attributed to them were wrong.

2. Definitions

• Trouble-search ratio: among the suggestions returned for a brand name alone, the share that contains a trouble word defined per language in advance — “outage”, “down”, “payment failed”, “can’t log in”, “app not opening”, “coupon not working” and the like. It does not mean an outage is occurring. It approximates how much users are searching about problems.
• A trouble word in a suggestion does not mean the service was stopped by a vulnerability or an intrusion. Causes range from network incidents and congestion to user error and lingering traces of past events, and the time at which suggestions were collected does not coincide with the time of the security observation. Showing the two side by side does not claim correlation or causation; it shows “the configuration, at observation time, of the services users name most often”.
• Configuration issue (what “has issues” means in this article): (1) no HSTS header (the header that forces HTTPS); (2) the server product or version is visible from outside; (3) the exposed version is end-of-life or within the range of a published CVE. No intrusive testing was done, and nothing here says a site “can actually be breached”.
• No TLS 1.3: TLS 1.2 was negotiated on a handshake that offered TLS 1.3. It is shown in a separate column as “below the recommended level” and is not counted as an issue. Sites that only support TLS 1.0/1.1 fail to connect and cannot be distinguished from other failures with this method (the “accepts TLS 1.0/1.1” column in Table B comes from a separate additional handshake and is given for reference).
• CVE counts are an upper bound derived from the version string in the header. Distributions such as Debian and RHEL backport fixes without changing the version number, which this method cannot see. CVE-2024-3566 is mostly a Windows-specific case, so the RCE exposure rate is also given with it excluded.

3. Trouble-search ratio — complaints are a small minority of searches

Of the 3,178,854 suggestions returned for a brand name alone, 9,104 (0.29%) contained a trouble word. Across the 8,236 brand × region × engine combinations with at least 100 plain-seed suggestions, the median was 0.0%, the 90th percentile 0.9%, the 99th percentile 3.0%, and the maximum 10.0% (BIDV SmartBanking in Vietnam, Google). 5,169 combinations (62.8%) had no trouble-word suggestion at all.

By country, Ireland (0.83%), Australia (0.76%), the Netherlands (0.63%), New Zealand (0.55%) and the UK (0.54%) were highest; Hong Kong (0.02%), the UAE (0.04%), Chile (0.08%) and Portugal (0.08%) were lowest. Japan was 0.28% (of 549,558 plain-seed suggestions), ranking 21st of 41 countries. Because suggestion behaviour and trouble vocabulary differ by language, differences between countries are indicative only.

In Japan (Google), the highest ratios were Wi-Fi (4.1%), au Hikari (3.7%), docomo Hikari (3.7%), OCN (3.4%), Ekinet (3.1%), SoftBank Hikari (3.0%), Rakuten Mobile (2.7%), BIGLOBE (2.7%) and NURO Hikari (2.5%) — a list of broadband and mobile carriers. Among payment and bank brands, Rakuten Pay (2.3%), Vandle Card (2.2%), Rakuten Card (2.0%), QUICPay (1.9%) and d-Barai (1.8%) led, all at around 2%.

Trouble words were matched on word boundaries against each suggestion with the brand name removed (the matching method was revised on 27 October 2026, and every value in this article is from after that revision).

A high trouble-search ratio is not a vulnerability — NURO Hikari and menu

For two Japanese services whose suggestions contain trouble words, here are the suggestions themselves next to the public-configuration observation from the same period. A trouble word in a suggestion does not mean the service was stopped by a vulnerability or an intrusion. Line faults, system outages, maintenance and app bugs — problems unrelated to vulnerabilities — are searched for with the same words, and the suggestion collection time does not coincide with the observation time.

NURO Hikari attracts “won’t connect” searches, as a broadband service would, yet its public configuration showed no gaps: users’ problems arise on the line or in home equipment, a different layer from the website’s settings. menu’s trouble-word share is low; instead, suggestions such as “service ended” and “withdrawal” appear, and the site returned 502 on both observations. In neither case do the trouble words in suggestions correspond to configuration gaps. The trouble-search ratio indicates what users are struggling with when they search; it is not an indicator of security weakness.

Figure 2. Trouble-search ratio × presence of issues, by category

In this data, there was no visible relationship between the trouble-search ratio and whether a site had configuration issues (Figure 2). As §2 explains, the two are determined at different times and by different causes. The suggestion survey therefore serves as a sampling frame — “services frequently named in payment, bank and retail searches” — and §4–§6 describe the configuration of that sample.

4. Security posture

By category (680 hosts)

Each host’s category is the most frequent segment among the brand × region × engine rows that point to it; 40 hosts outside these four segments (“other”) are left out of the table.

Taking payment and bank together, 71 of 269 hosts (26.4%) had issues: 54 (20.1%) lacked HSTS and 25 (9.3%) exposed a version; 44 (16.4%) did not negotiate TLS 1.3. That is lower than retail (39.3%) and everyday services (36.3%), so payment and bank sites are relatively well configured — yet one in four has a gap, and one in five has no HSTS.

Figure 3. Issue rates by category (no HSTS / version exposed / no TLS 1.3)

By region

Region means the host’s own country (derived from country-code domains and similar), not the region in which the brand was searched. 292 of the 680 hosts (42.9%) use .com or other domains whose country cannot be determined; they are shown as a separate row. The 17 EU countries are Germany, France, Italy, Spain, the Netherlands, Belgium, Austria, Portugal, Ireland, Sweden, Denmark, Finland, Poland, Czechia, Greece, Hungary and Romania.

Only the United States (83) has 20 or more hosts; Vietnam (18, 11 with issues), Japan (18, 8 with issues) and Italy (16, 8 with issues) follow. With samples this small, countries are not ranked.

Japan’s 18 hosts are mostly .jp domains. Eight had issues, all of them missing HSTS (povo, LINEMO, IIJmio, TVer, NHK, Qoo10, PayID, Alipay). No Japanese host exposed a version, and no end-of-life PHP or version within an RCE CVE range was found.

Figure 4. Share of hosts with issues by region (JP, US, EU plus top/bottom five countries)

5. Banks and payment services hold up — good examples (Table A)

Selection: in descending order of search exposure (plain-seed suggestion count), services that connected with TLS 1.3, sent HSTS, and did not expose a server version. The 19 whose host-to-brand mapping was confirmed independently by me and by the data provider are listed, most-searched first. Japan contributes PASMO, JCB Card and BitCash.

Cross-border payment services — PayPal, Stripe, Wise, Klarna, Venmo, Paytm, PhonePe — all met the three conditions. This does not mean their security is “sufficient”; it means the three externally visible baseline settings had no gaps.

6. Services with observed issues (Table B)

Selection: per country, in descending order of search exposure, services where missing HSTS, an exposed version or an end-of-life version was observed. The 99 whose host-to-brand mapping was confirmed by me and by the data provider are listed by country and search exposure. Seventy-four rows whose automated identification was wrong (for example “Hello bank” mapped to an unrelated site with a similar name, or “SMBC Nikko Securities” mapped to the bank’s site) were excluded. Brands searched in a region other than their home (Commerzbank, Morrisons, Jean Coutu, Qantas) are listed under their home country. URLs are given as plain text, not links. Each row is an observation at the stated time; the setting may have been fixed since.

All seven Japanese entries are missing HSTS and none exposes a version; Alipay and Qoo10 additionally accepted TLS 1.0/1.1 connections. End-of-life PHP appeared on two sites — ACI in Italy (the automobile club, 7.4.33) and TPG in Australia (telecom, 7.4.33) — neither a payment or bank service.

7. PHP vulnerability response — zero end-of-life versions among payment and bank sites

Here is how the 1,705 newly observed hosts stand against the critical 2026 PHP vulnerability (CVSS 9.8) covered in A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? and the Security Exposure Survey 2026.

With only 18 PHP-disclosing hosts, counts are more meaningful than rates. Thirteen of the 18 run a 2026 fixed version — they do not hide the version, but they do update. The three end-of-life sites are an Italian automobile club, an Australian telecom and a Peruvian social-insurance agency; none is a payment or bank service. This contrasts sharply with the general Japanese sites in the Security Exposure Survey 2026, where 52.3% of PHP-disclosing sites showed an end-of-life version.

8. Limits and caveats

• Non-intrusive observation: one DNS lookup, one TLS handshake and one HTTP GET per site (plus one additional handshake for the TLS 1.0/1.1 column in Table B). No attack was attempted.
• Exposure figures are upper bounds; an old version string may already be patched by backports.
• Brand-to-site identification was automated: checking all 920 hosts by hand found 212 (23.0%) misidentified and 28 undeterminable. The aggregates and Tables A and B use only the 680 hosts that passed, but a manual check can also miss errors.
• Suggestions approximate demand only. They vary by region, language and time, and the same brand yields different candidates on Google and Bing. The trouble vocabulary was defined per language and is not exhaustive.
• Some countries have small samples. Japan has 18 hosts; its rates are indicative and shown with counts. Countries are not ranked.
• Timing differs: suggestions were collected 24–26 October, observations 22–26 October.
• CSP, cookie attributes and certificates are not covered here (see the Security Exposure Survey 2026).

9. What operators should check

1. Enable HSTS. 20.1% of payment and bank sites lacked it. Returning Strict-Transport-Security: max-age=31536000; includeSubDomains pins users who try HTTP to HTTPS.
2. Enable TLS 1.3 and disable TLS 1.0/1.1. 16.4% of payment and bank sites stopped at TLS 1.2.
3. Hide server versions (expose_php = Off, ServerTokens Prod, server_tokens off) — after updating.
4. Replace end-of-life versions. For PHP, move to 8.3 or later and to the 2026 fixed releases (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) or newer. The step-by-step procedure is in How to upgrade PHP in practice.
5. Check your own site. Enter a URL into Site Scouter’s Server information check (/server/) to see, with the same method as this article, what your server shows the outside world (TLS, HSTS, server headers, certificate, cookie attributes) in about ten seconds. No registration needed.

Related: A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? (author’s blog) / Security Exposure Survey 2026 (Site Scouter)

10. Method notes, disclaimer and FAQ

Is this an attack? No. Each site received the same access as opening it once in a browser, and only public HTTP responses and DNS data were used.

Are the services in Table B dangerous? Table B lists configuration gaps observable from public information at the stated time; it does not establish that any site can be breached. A missing HSTS header or an exposed version does not leak data on its own; these are gaps whose impact grows when combined with other conditions.

Why name them? The facts are TLS settings and HTTP headers — public information anyone can reproduce with the same steps. Attackers already know them, so publication adds little risk, while users and operators benefit from knowing the state of their services. No advance notice was sent before publication.

Where do I send questions or corrections? To the author’s contacts at the end of this page. Where a setting has been fixed since observation, I will re-observe and add a note.

Was the data altered? Suggestions were appended per fetch and observation results were stored in an append-only table. During aggregation the matching method for the trouble-search ratio was revised (§3) and the ratio recomputed; the article uses the recomputed values, and the pre-correction values are not published.

About the author

Yuki Nakazawa (nkzw.jp)

• Website: nkzw.jp
• YouTube: @yknkzw
• Instagram: @nkzwyk
• LinkedIn: yukinakazawa
• X: @YukiNakazawa331
• Telegram: @yknkzw

2026.10.27 / written by Yuki Nakazawa

Update history

• 1st edition posted 2026-10-27 23:20 JST
• 2nd edition updated 2026-10-27 23:24 JST (denominator changed to the 680 verified hosts)
• 3rd edition updated 2026-10-27 23:25 JST (denominator changed to the 680 verified hosts)
• 4th edition updated 2026-10-27 23:25 JST (denominator changed to the 680 verified hosts)
• 5th edition updated 2026-10-27 23:28 JST (denominator changed to the 680 verified hosts)
• 6th edition updated 2026-10-27 23:28 JST (denominator changed to the 680 verified hosts)
• 7th edition updated 2026-10-27 23:31 JST (added the NURO Hikari / menu section)
• 8th edition updated 2026-10-27 23:33 JST (reworded the matching-method note)
• 9th edition updated 2026-10-27 23:35 JST (related articles now referred to by title)
• 10th edition updated 2026-10-27 23:38 JST (added links to the Site Scouter and Egosaru editions)
• 11th edition updated 2026-10-27 23:57 JST (added a figure under each heading)