Clean at the Front, Outdated Further In? — A Survey Comparing the "Login-Side Hosts" of Payment and Bank Sites with Their Front Hosts

For 341 payment and bank brand domains, I observed the security settings of the front host that everyone sees and of the "login-side hosts" that handle login and APIs with the same yardstick, and compared whether the two are aligned within the same brand. The indicator for which we can say that domains with a good front but a weaker login side outnumber the reverse was missing HSTS, at 5.1x. For the TLS version indicators, we could not say there was a difference (when one host per brand is picked at random).

This article is also published on the author's blog (nkzw.jp) and on Egosaru. Japanese edition: 日本語版

Summary

Payment and bank sites often operate the top page that everyone sees (the front) separately from the hosts that handle login, transactions and app integration. This survey measured 343 front hosts (341 domains) of payment and bank brands, whose brand-to-domain correspondence was checked one by one, and 1,010 login-side hosts of the same brands, using exactly the same passive observation (one DNS lookup, one TLS handshake and one HTTP GET each, plus four version-pinned handshakes), and matched the two against each other within each brand. The main results are the following four points.

1. Within the same brand, HSTS is where we can say that "good front, but a weaker login side" outnumbers the reverse. Averaged over 1,000 repetitions of randomly picking one login-side host per brand, missing HSTS was 83.5 vs. 16.6 (5.1x, 95% interval 3.9–6.8; 265 domains). Accepting legacy TLS (1.0/1.1) was 10.8 vs. 6.2 (1.8x, 1.1–2.8) and no TLS 1.3 was 24.1 vs. 17.1 (1.4x, 1.1–1.9) (268 domains); the lower ends of the intervals are close to 1x, and for brands with only one login-side host the direction even reverses. For the two TLS indicators, it cannot be said for certain that there is a difference.
2. Missing HSTS is the largest gap. 45.2% (370/818) of login-side hosts have no HSTS, about twice the rate of front hosts (21.3%, 71/334). However, this needs to be discounted to the extent that redirect-only hosts are included.
3. Trends differ by the beginning of the host name. Hosts beginning with mobile. merchant. online. my. id. have high no-TLS 1.3 rates of 26.1–32.5%, while login. auth. app. checkout. are at 7.1–12.2%, below the front hosts (17.5%). Hosts serving older devices and apps may be lagging further behind in updates.
4. "Outdated settings" connect to real-world attack techniques when logging in from public Wi-Fi. Among login-side hosts, 38 (4.6%) do not redirect to HTTPS when accessed over HTTP, and for 29.7% (106/357) the cookie returned in the first response lacks the Secure attribute. 44 hosts overlap with missing HSTS, so the conditions are in place for SSL stripping to capture the password and the session at the same time. There are also 8 hosts whose disclosed version matches a known CVE (2 involving remote code execution).

This survey is a single passive observation and is not an evaluation of the security of any individual service. Attack techniques are described as publicly known generalities, and none have been tried against real hosts. Brand names and domain names are not disclosed.

1. Background and Purpose

The front is rebuilt with every campaign, but the hosts further in must stay compatible with old apps and devices, and their settings are hard to change. Seen that way, it would not be surprising if a gap where "the front is up to date, but the inside stays old" had opened up. The earlier survey (the intersection of "not working" search demand for payments and apps with the exposure of front hosts; Security Posture of the 920 Payment and Bank Sites People Search For) looked only at the front. The purpose of this survey is to measure, with the same yardstick, how the login-side hosts, which are where users actually send their IDs and passwords, differ from the front.

2. Method

2.1 Target

For the 370 front domains of payment and bank brands whose domains had been identified in the earlier survey, I visually checked the brand-to-domain correspondence one by one before publication. The check consisted of two points: (1) whether the title and content of the domain's top page are those of the official site of that brand (or the same organization), and (2) whether it is not a site of a different industry or country with the same name. The results are as follows.

The population of this article is 268 correct + 75 replaced = 343 hosts (341 domains; 163 payment and 180 bank hosts). Most of the errors were domains of a different industry or country spelled the same as the brand name (names are not disclosed). The replacements were re-observed on October 28, and only the front observation was done with the regular observer that follows redirects (HSTS and the like were judged on the final response).

2.2 How the Login-Side Hosts Were Selected

Rather than having a person decide "this is the login screen", I collected them mechanically in two stages.

1. From the alternative names (SAN) written in the front host's certificate, pick up names beginning with login. auth. id. secure. my. account. api. app. pay. checkout. and so on (no additional traffic; 58 hosts)
2. Attach the same 36 kinds of prefix to each domain, look them up in DNS, and adopt the names that existed (952 hosts). 20 domains with "wildcard DNS", which responds to any name, were excluded

That makes 1,010 hosts in total (including 163 hosts for the 75 replaced domains).

2.3 What Was Observed

Exactly the same as for the front: DNS resolution, one TLS handshake, one HTTP GET (redirects not followed), plus four handshakes each pinned to one of TLS 1.0 / 1.1 / 1.2 / 1.3. Nothing was entered on any login screen, and no authentication was attempted at all. Only the information the server returns of its own accord in its first response is recorded.

2.4 Denominators

There were 171 hosts whose names resolved but which did not respond on port 443 (connection errors, timeouts). Excluding these, the aggregation uses the 822 hosts for which TLS could be determined and the 818 hosts that returned an HTTP response. For the front, there are 337 TLS hosts and 334 HTTP-response hosts. The brand-level comparison covers the 268 domains where both the front and the login side could be observed (123 payment, 145 bank; 265 for HSTS). For brands with multiple login-side hosts, the process of randomly picking one host is repeated 1,000 times and averaged (fixed random seed, 95% interval shown alongside) to avoid bias from the number of hosts. Representing a brand by its "worst value" was not adopted, because it puts brands with more hosts at a disadvantage (Section 3.2, Section 5).

2.5 Definitions of the Indicators

There were 0 "legacy-only" hosts (unable to speak TLS 1.2 or later) among both the 822 login-side hosts and the 337 front hosts for which TLS could be determined (one of the login-side hosts that could not be determined responded only to TLS 1.1 while the other versions timed out, so it cannot be concluded to be legacy-only). This is why this article writes "also accepts legacy TLS"; it does not mean "can connect only with old TLS".

3. Results

3.1 Host Level: Login-Side Hosts Lack HSTS Twice as Often

For both the front and the login side, hosts from which no HTTP response was obtained are excluded as missing (the denominators for HSTS and version; for the TLS indicators, the hosts that could be judged by version-pinned handshake).

The difference in no TLS 1.3 is 1 point and in legacy acceptance just under 5 points, but HSTS differs twofold. On the other hand, version exposure is lower on the login side, so it is not the case that "the inner hosts are worse in every respect". The login-side hosts give short responses (273 are 301/302 redirects, 104 are 403), so they have less information to disclose in the first place, which also has an effect.

HSTS calls for caution. For hosts that return only redirects, or API hosts that browsers do not open directly, operating without HSTS is not unusual. The figure of 45.2% includes those. Even so, leaving room for a browser to arrive over HTTP at a host that handles login is undesirable, and I consider the share of hosts where it is "missing even where it should be set" to be too large to ignore.

3.2 Brand Level: The Gap Is Large for HSTS and Small for TLS

Within the same brand (registered domain), I counted in a 2×2 table whether the front and the login side are aligned. For brands with multiple login-side hosts, the random pick of one host is repeated 1,000 times, and the mean and 95% interval of each cell are reported.

The ratio is the mean of the ratios from each of the 1,000 runs. It may differ after the decimal point from the value obtained by dividing the mean counts in the table by each other (e.g. for HSTS, 83.5 ÷ 16.6 = 5.0, while the ratio in the table is 5.1).

For all three indicators, on average "good front, but a weaker login side" exceeds the reverse. However, HSTS is the only one for which we can say there is a difference.

• HSTS retains a large gap: 83.5 vs. 16.6 (5.1x). The interval (3.9–6.8x) is far from 1x. Even when restricted to brands with only one login-side host (37), it is 13 vs. 0, and even when compared with the majority of the hosts, it is 67 vs. 14 (4.8x).
• For legacy acceptance and TLS 1.3, we cannot say there is a difference: the ratios are 1.4–1.8x, but the lower ends of the intervals are 1.1x, close to 1x (no difference). Restricted to brands with only one login-side host (38), legacy acceptance is 2 vs. 3 and no TLS 1.3 is 4 vs. 3, reversed or roughly even, and even when compared with the majority of the hosts they are only 9 vs. 5 and 17 vs. 15. The number of applicable cases is itself small (for legacy acceptance, out of 268 domains, an average of 10.8 in the upper right and 6.2 in the lower left).
• Even if the front and the login side were worse at the same rate, the login side would have a higher probability that "any one" of its multiple hosts is worse. Once this counting bias is removed, the TLS difference shrinks to 1.4–1.8x, while the HSTS difference remains large.

In other words, the conclusion of this survey is that the picture of "the front is new, but the login side is old" can clearly be stated for HSTS operation, while for TLS versions we cannot say there is a difference.

Note: If brands with multiple login-side hosts are represented by their "worst value", the ratios become 4.8x (legacy), 5.7x (TLS 1.3) and 26x (HSTS). This is a counting bias in which brands with more hosts are more likely to have "any one" that is worse, and it is not adopted in this article.

3.3 Is There a Difference Between Payment and Bank?

(n for HSTS: 123 payment, 142 bank. Figures in parentheses are the mean counts from the random one-host pick)

For payment, the no-TLS 1.3 gap is somewhat larger (2.1x), and payment's TLS 1.3 is the only case whose interval (1.3–3.5x) is away from 1x. For bank it is 1.1x, and the interval straddles 1x. For legacy acceptance, payment's interval of 0.8–3.5x straddles 1x and bank's lower end is exactly 1x, so neither can be said to show a difference. HSTS is 3.4x for payment and 7.9x for bank, with both intervals entirely away from 1x, a trend common to payment and bank alike. The gap is larger for banks because bank front hosts almost all have HSTS, while it is still missing on the login side.

By region as well (with the same random one-host pick), HSTS showed a large gap in every region: 4.8x for the 41 US domains, 9.1x for the 36 in major European countries, 7.2x for the 88 others, and 4.0x for the 96 with an unknown country code. The TLS indicators range from around 1x to 2.7x across regions, most of the intervals straddle 1x, and the US and Europe have small counts (for the US, the ratio cannot be computed because the reverse combination has 0 cases), so we cannot say there is a difference.

Regions are divided by the brand's home base (the region label from the earlier survey). Japan (4 domains) has too few cases, so no rates are given. The HSTS denominator is 41 + 36 + 88 + 96 + 4 = 265, matching the total (for the TLS indicators, 41 + 35 + 89 + 99 + 4 = 268).

3.4 Trends Differ by the Beginning of the Host Name

(Prefixes with 20 or more hosts for which TLS could be determined. Please read the rows with 20–30 hosts with some latitude)

mobile. merchant. online. my. id. have no-TLS 1.3 rates of 26.1–32.5%, well above the front (17.5%). mobile. online. my. are names that have long been used as connection endpoints for old smartphone apps and dedicated online banking clients, and one can glimpse a situation of "we can't cut off old devices, so we can't introduce the new method either" (merchant. is a name for merchant-facing admin screens and endpoints, and likewise tends to carry old clients). Conversely, login. auth. app. checkout. are at 7.1–12.2%, below the front, and it can be said that the infrastructure for the authentication and payment screens built in recent years is close to up to date.

4. Discussion: What Attacks Can "Outdated Settings" Lead To?

The indicators so far are not "holes" in themselves. They become meaningful in situations where a third party can intrude on the communication path, such as a user logging in from public Wi-Fi at a café or a station. Login-side hosts are precisely the destination of passwords and session cookies, so the impact is more direct than for the front.

4.1 Mapping Settings to Techniques

4.2 How Much Do the Conditions Overlap on Login-Side Hosts?

While only 5 front hosts "do not redirect to HTTPS", there are 38 on the login side. The picture is that the front undergoes HTTPS checks, but hosts such as api. or m. that "people supposedly don't open directly" are outside those checks. Yet old apps and bookmarks do go and open those hosts over http://.

Put as a single scene: on café Wi-Fi, someone opens a login screen over http:// from an old bookmark. If the host has no HSTS and does not redirect either, a person on the same Wi-Fi can relay the screen in plaintext, and the password entered can be read as is. If the cookie lacks Secure, the post-login session can be taken over the same path. This is the combination that could hold for 44 hosts. It has not actually been tried (Section 5).

5. Limitations and Caveats

• The login-side hosts were selected mechanically, and whether they actually serve a login screen was not checked. They include 143 hosts that return 404 and 273 redirect-only hosts. "Login-side" in this article means roughly "hosts that the brand operates under names for authentication, transactions or APIs".
• The missing-HSTS rate includes redirect-only and API-only hosts. The absence of HSTS on hosts that browsers do not open directly cannot in itself be called a problem with certainty.
• The observation is a single passive observation and does not evaluate the security of the services. Legacy acceptance and no TLS 1.3 are indicators of "outdated settings"; they do not by themselves make an attack succeed.
• Attack techniques are described as publicly known generalities. Stripping and downgrades have never been tried against the hosts in this article. The CVE matches are also "disclosed version strings checked against NVD", and whether they are actually exploitable was not confirmed.
• Cookie attributes can be observed only for hosts that returned a cookie in their first response (357 / 170). The real session cookies issued after login were not seen, so please read the percentages as "the tendency of that host's cookie settings".
• The brand-level comparison is affected by the number of login-side hosts. Brands with more hosts have a higher probability that "any one" is worse, so this article compared using the mean of a random one-host pick. Even so, the number of login-side host candidates per brand ranges from 1 (49 brands) to 6 or more (46 brands), and they cannot be treated with equal weight. Results restricted to brands with a single candidate where both the front and the login side could be observed (38; 37 for HSTS) are shown alongside in Section 3.2.
• This is correlation, not causation. For HSTS, the results suggest a structure in which the front is put in order first, but the circumstances of each company were not observed.
• The brand-to-domain correspondence was checked visually, but this is human judgment, and errors may remain. The front hosts of the 75 replaced domains were re-observed with the regular observer that follows redirects, so HSTS and the like for those front hosts were judged on the final response (the login side is uniformly observed without following redirects).
• The population consists of larger brands whose domains could be identified in the earlier survey. For Japan, only 4 domains could be paired, so nothing can be said about trends in Japan.
• Brand names and domain names are not disclosed. Nor will the data be redistributed in a form that identifies individual institutions.

6. Recommendations: What Operators Can Do

Organizations that look only at the scan results for their front and feel reassured that "we support TLS 1.3 and have HSTS" may find gaps if they take a one-time inventory of their login-side, mobile and API hosts with the same yardstick. In particular, for hosts remaining under old-generation names such as mobile. online. my., it is worth first checking "whether they are still in use".

In practice, it makes sense to decide the order of checks by how direct the impact is.

1. HTTP → HTTPS redirect and HSTS (preload registration if possible). This alone closes off stripping-type techniques
2. Cookie Secure / HttpOnly / SameSite. Essential on hosts that handle sessions
3. Disabling TLS 1.0 / 1.1. On hosts that handle card payments, PCI DSS does not permit the use of SSL and early TLS
4. Hiding versions in the Server / X-Powered-By headers, and updating EOL products
5. TLS 1.3 support (recommended)

7. Data and Reproducibility

• The brand list comes from the earlier survey (Security Posture of the 920 Payment and Bank Sites People Search For), which collected "not working" search demand for payment, banking, retail and so on in 48 regions. The front observation results come from the passive observation of Site Scouter Phase 5 (a global security survey), and the login-side hosts in this article were measured with the same observer.
• The aggregated CSV (counts by category, with no names) will be published as an appendix to this article. Per-brand breakdowns will not be published.
• The figures in this article are based on observations from October 26–28, 2026, and will change as companies change their settings.

Appendix A: Terms

Author and Contact

Yuki Nakazawa

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