Beveiliging van de 920 betaal- en banksites waar mensen naar zoeken — 13.4 miljoen zoeksuggesties gekoppeld aan het Phase5-onderzoek

• In 48 regio's en 20 talen verzamelde ik 13.4 miljoen zoeksuggesties (9.28 miljoen uniek) voor 3,472 merken uit betalen, bankieren, retail en dagelijkse dienstverlening, en bekeek ik de publieke configuratie van de 920 sites waarnaar die suggesties verwijzen, met één gewone paginaweergave per site. Elke koppeling tussen merk en site is daarna met de hand gecontroleerd; de 680 sites die die controle doorstonden, vormen de basis van alle cijfers in dit artikel.
• Van de 269 betaal- en banksites had 26.4% (71) minstens één van de volgende tekortkomingen: geen HSTS, een zichtbare serverversie of een end-of-life-versie. Het vaakst ontbrak HSTS (20.1%). 16.4% onderhandelde geen TLS 1.3; elke site die antwoordde, gebruikte TLS 1.2 of beter.
• Geen enkele betaal- of banksite toonde een end-of-life PHP-versie. Van alle 1,705 nieuw gescande hosts maakten er slechts 18 (9 sites als apex en www samen worden geteld) een PHP-versie bekend, en daarvan waren er 5 (3 sites) end-of-life. Vergeleken met de algemene populatie in het Security Exposure Survey 2026 verbergen betaal- en banksites hun versie of houden ze die actueel.
• Het aandeel suggesties met woorden als "storing", "betaling mislukt" of "kan niet inloggen" (het probleemzoekaandeel) bedroeg 0.29% van de 3.18 miljoen suggesties die op alleen een merknaam terugkwamen. Het hoogste aandeel voor één merk was 10.0%, en meer dan de helft van alle merken had er geen. Zoekopdrachten waarin over storingen wordt geklaagd, zijn zeldzaam in suggesties.
• Twintig goede voorbeelden (tabel A) en 92 sites met waargenomen tekortkomingen (tabel B) worden bij naam genoemd. Tabel B legt publieke feiten vast — TLS-instellingen en HTTP-headers — en betekent niet dat bij een site is vastgesteld dat die misbruikt kan worden.

Dit artikel is ook in het Engels gepubliceerd op sitescouter.net en nkzw.jp, en in het Japans op sitescouter.net. Dit is de Nederlandse editie op Site Scouter, vertaald uit de Engelse versie.

Methode

Dit artikel koppelt twee onderzoeken aan elkaar (figuur 1).

1. Verzameling van zoeksuggesties (Egosaru). In 48 regio's en 20 talen legde ik de suggesties vast die Google, Bing, Yahoo!, Yandex, Naver, Baidu, Daum en Shopee tonen wanneer een merknaam in het zoekvak wordt getypt. Er zijn twee soorten seeds gebruikt: alleen de merknaam ("kale seed") en de merknaam plus een probleemwoord ("samengestelde seed"). Dat leverde 83,275 ophaaltaken op (83,016 voltooid, 259 mislukt) en 13,438,498 suggesties (9,280,238 uniek), verzameld van 24 tot 26 oktober 2026.
2. Observatie van de publieke configuratie (Site Scouter Phase5). Voor de merken die naar voren kwamen, heb ik hun sites bepaald (5,408 kandidaat-hosts, waarvan er 2,842 antwoordden op DNS en HTTPS) en de 1,705 hosts die nog niet in het eerdere onderzoek zaten, nieuw geobserveerd. Elke observatie bestaat uit een DNS-opvraging, één TLS-handshake en één HTTP GET — hetzelfde als de site één keer in een browser openen. Er is geen poortscan, geen kwetsbaarheidsonderzoek, geen inlogpoging en geen exploitverkeer gebruikt. De observaties liepen van 22 tot 26 oktober 2026.
3. De twee zijn op merkniveau gekoppeld, wat 9,181 rijen merk × regio × zoekmachine en 920 unieke hosts opleverde. Van alle 920 is daarna met de hand gecontroleerd of de host echt de officiële site van het merk is; de 680 hosts die slaagden, vormen overal de noemer (212 verkeerd geïdentificeerde en 28 niet te bepalen hosts zijn uitgesloten). Alle noemers in dit artikel zijn aantallen hosts.

Het koppelen van een merk aan zijn site gebeurde automatisch op basis van exacte (2,630) en gedeeltelijke (2,778) overeenkomsten in de hostnaam, waardoor ook ongerelateerde sites met een gelijkende naam worden opgepikt. Bij de handmatige controle van alle 920 hosts bleken er 212 (23.0%) niet bij het merk te horen (bijvoorbeeld "Hello bank" gekoppeld aan een ongerelateerde site met een gelijkende naam, of "SMBC Nikko Securities" gekoppeld aan de site van de bank) en konden er 28 niet worden bepaald. De fouten concentreren zich rond generieke merknamen als "Easy", "Media" of "Wi-Fi" en rond ongerelateerde organisaties met dezelfde naam. De totalen in §4 en de tabellen A en B gebruiken alleen de 680 hosts die deze controle doorstonden. De gemeten instellingen van de uitgesloten hosts zijn op zich correct, maar ze zijn weggelaten omdat de branche en het land die eraan waren toegekend, niet klopten.

Definities

• Probleemzoekaandeel: het aandeel van de suggesties voor alleen een merknaam dat een vooraf per taal vastgesteld probleemwoord bevat — "storing", "plat", "betaling mislukt", "kan niet inloggen", "app opent niet", "kortingscode werkt niet" en dergelijke. Het betekent niet dat er een storing gaande is. Het geeft bij benadering aan hoeveel gebruikers naar problemen zoeken.
• Een probleemwoord in een suggestie betekent niet dat de dienst door een kwetsbaarheid of een inbraak is stilgevallen. De oorzaken lopen uiteen van netwerkincidenten en drukte tot gebruikersfouten en nagalm van eerdere gebeurtenissen, en het moment waarop de suggesties zijn verzameld, valt niet samen met het moment van de beveiligingsobservatie. Door de twee naast elkaar te zetten wordt geen correlatie of oorzakelijk verband beweerd; het laat "de configuratie op het observatiemoment zien van de diensten die gebruikers het vaakst noemen".
• Configuratieprobleem (wat "heeft tekortkomingen" in dit artikel betekent): (1) geen HSTS-header (de header die HTTPS afdwingt); (2) het serverproduct of de versie is van buitenaf zichtbaar; (3) de zichtbare versie is end-of-life of valt binnen het bereik van een gepubliceerde CVE. Er zijn geen ingrijpende tests gedaan, en niets hier zegt dat een site "daadwerkelijk kan worden binnengedrongen".
• Geen TLS 1.3: er werd TLS 1.2 onderhandeld bij een handshake die TLS 1.3 aanbood. Dit staat in een aparte kolom als "onder het aanbevolen niveau" en telt niet als tekortkoming. Sites die alleen TLS 1.0/1.1 ondersteunen, krijgen geen verbinding en zijn met deze methode niet te onderscheiden van andere fouten (de kolom "accepteert TLS 1.0/1.1" in tabel B komt uit een aparte, extra handshake en is ter referentie opgenomen).
• Aantallen CVE's zijn een bovengrens op basis van de versiestring in de header. Distributies als Debian en RHEL backporten fixes zonder het versienummer te wijzigen, en dat kan deze methode niet zien. CVE-2024-3566 is grotendeels een Windows-specifiek geval, dus het percentage RCE-blootstelling wordt ook zonder deze CVE gegeven.

Probleemzoekaandeel — klachten zijn een kleine minderheid van de zoekopdrachten

Van de 3,178,854 suggesties voor alleen een merknaam bevatten er 9,104 (0.29%) een probleemwoord. Over de 8,236 combinaties van merk × regio × zoekmachine met minstens 100 suggesties op een kale seed was de mediaan 0.0%, het 90e percentiel 0.9%, het 99e percentiel 3.0% en het maximum 10.0% (BIDV SmartBanking in Vietnam, Google). 5,169 combinaties (62.8%) hadden helemaal geen suggestie met een probleemwoord.

Per land scoorden Ierland (0.83%), Australië (0.76%), Nederland (0.63%), Nieuw-Zeeland (0.55%) en het Verenigd Koninkrijk (0.54%) het hoogst; Hongkong (0.02%), de VAE (0.04%), Chili (0.08%) en Portugal (0.08%) het laagst. Japan kwam uit op 0.28% (van 549,558 suggesties op een kale seed) en stond daarmee 21e van 41 landen. Omdat het gedrag van suggesties en de probleemwoordenschat per taal verschillen, zijn verschillen tussen landen slechts indicatief.

In Japan (Google) lagen de hoogste aandelen bij 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%) en NURO Hikari (2.5%) — een rij breedband- en mobiele providers. Onder de betaal- en bankmerken lagen Rakuten Pay (2.3%), Vandle Card (2.2%), Rakuten Card (2.0%), QUICPay (1.9%) en d-Barai (1.8%) voorop, allemaal rond 2%.

Probleemwoorden zijn op woordgrenzen vergeleken met elke suggestie waaruit de merknaam was verwijderd (de vergelijkingsmethode is op 27 oktober 2026 herzien, en alle waarden in dit artikel zijn van na die herziening).

Een hoog probleemzoekaandeel is geen kwetsbaarheid — NURO Hikari en menu

Voor twee Japanse diensten waarvan de suggesties probleemwoorden bevatten, staan hier de suggesties zelf naast de observatie van de publieke configuratie uit dezelfde periode. Een probleemwoord in een suggestie betekent niet dat de dienst door een kwetsbaarheid of een inbraak is stilgevallen. Lijnstoringen, systeemuitval, onderhoud en bugs in apps — problemen die los staan van kwetsbaarheden — worden met dezelfde woorden gezocht, en het moment van verzamelen van de suggesties valt niet samen met het observatiemoment.

NURO Hikari trekt zoekopdrachten als "maakt geen verbinding", zoals bij een breedbanddienst te verwachten is, maar de publieke configuratie liet geen tekortkomingen zien: de problemen van gebruikers ontstaan op de lijn of in de apparatuur thuis, een andere laag dan de instellingen van de website. Bij menu is het aandeel probleemwoorden laag; in plaats daarvan verschijnen suggesties als "dienst beëindigd" en "terugtrekking", en de site gaf bij beide observaties 502. In geen van beide gevallen komen de probleemwoorden in suggesties overeen met tekortkomingen in de configuratie. Het probleemzoekaandeel laat zien waar gebruikers mee worstelen wanneer ze zoeken; het is geen indicator van zwakke beveiliging.

In deze gegevens was er geen zichtbaar verband tussen het probleemzoekaandeel en de vraag of een site configuratieproblemen had (figuur 2). Zoals §2 uitlegt, worden de twee op verschillende momenten en door verschillende oorzaken bepaald. Het suggestieonderzoek dient daarom als steekproefkader — "diensten die vaak worden genoemd in zoekopdrachten naar betalen, bankieren en retail" — en §4–§6 beschrijven de configuratie van die steekproef.

Beveiligingsstatus

Per categorie (680 hosts)

De categorie van elke host is het segment dat het vaakst voorkomt onder de rijen merk × regio × zoekmachine die ernaar verwijzen; 40 hosts buiten deze vier segmenten ("overig") zijn uit de tabel weggelaten.

Betalen en bankieren samen genomen hadden 71 van de 269 hosts (26.4%) tekortkomingen: bij 54 (20.1%) ontbrak HSTS en 25 (9.3%) toonden een versie; 44 (16.4%) onderhandelden geen TLS 1.3. Dat is lager dan bij retail (39.3%) en dagelijkse diensten (36.3%), dus betaal- en banksites zijn relatief goed geconfigureerd — toch heeft één op de vier een tekortkoming en heeft één op de vijf geen HSTS.

Per regio

Regio betekent het eigen land van de host (afgeleid uit landcodedomeinen en dergelijke), niet de regio waarin naar het merk is gezocht. 292 van de 680 hosts (42.9%) gebruiken .com of andere domeinen waarvan het land niet te bepalen is; die staan in een aparte rij. De 17 EU-landen zijn Duitsland, Frankrijk, Italië, Spanje, Nederland, België, Oostenrijk, Portugal, Ierland, Zweden, Denemarken, Finland, Polen, Tsjechië, Griekenland, Hongarije en Roemenië.

Alleen de Verenigde Staten (83) hebben 20 of meer hosts; daarna volgen Vietnam (18, waarvan 11 met tekortkomingen), Japan (18, waarvan 8 met tekortkomingen) en Italië (16, waarvan 8 met tekortkomingen). Met zulke kleine steekproeven worden landen niet gerangschikt.

De 18 Japanse hosts zijn grotendeels .jp-domeinen. Acht hadden tekortkomingen, en bij allemaal ontbrak HSTS (povo, LINEMO, IIJmio, TVer, NHK, Qoo10, PayID, Alipay). Geen enkele Japanse host toonde een versie, en er is geen end-of-life PHP of versie binnen het bereik van een RCE-CVE gevonden.

Banken en betaaldiensten doen het goed — goede voorbeelden (tabel A)

Selectie: in aflopende volgorde van zichtbaarheid in zoekopdrachten (aantal suggesties op een kale seed), diensten die verbinding maakten met TLS 1.3, HSTS meestuurden en geen serverversie toonden. De 19 waarvan de koppeling tussen host en merk zowel door mij als door de dataleverancier onafhankelijk is bevestigd, staan hieronder, de meest gezochte eerst. Uit Japan komen PASMO, JCB Card en BitCash.

Grensoverschrijdende betaaldiensten — PayPal, Stripe, Wise, Klarna, Venmo, Paytm, PhonePe — voldeden allemaal aan de drie voorwaarden. Dat betekent niet dat hun beveiliging "voldoende" is; het betekent dat de drie van buitenaf zichtbare basisinstellingen geen tekortkomingen vertoonden.

Diensten met waargenomen tekortkomingen (tabel B)

Selectie: per land, in aflopende volgorde van zichtbaarheid in zoekopdrachten, diensten waarbij ontbrekende HSTS, een zichtbare versie of een end-of-life-versie is waargenomen. De 99 waarvan de koppeling tussen host en merk door mij en door de dataleverancier is bevestigd, staan per land en naar zichtbaarheid in zoekopdrachten. Vierenzeventig rijen waarvan de automatische identificatie fout was (bijvoorbeeld "Hello bank" gekoppeld aan een ongerelateerde site met een gelijkende naam, of "SMBC Nikko Securities" gekoppeld aan de site van de bank), zijn uitgesloten. Merken waarnaar buiten hun thuisland is gezocht (Commerzbank, Morrisons, Jean Coutu, Qantas), staan onder hun thuisland. URL's staan als platte tekst, niet als link. Elke rij is een observatie op het vermelde moment; de instelling kan sindsdien zijn gecorrigeerd.

Bij alle zeven Japanse vermeldingen ontbreekt HSTS en geen enkele toont een versie; Alipay en Qoo10 accepteerden daarnaast verbindingen via TLS 1.0/1.1. End-of-life PHP kwam voor op twee sites — ACI in Italië (de automobielclub, 7.4.33) en TPG in Australië (telecom, 7.4.33) — en geen van beide is een betaal- of bankdienst.

Aanpak van de PHP-kwetsbaarheid — nul end-of-life-versies bij betaal- en banksites

Zo staan de 1,705 nieuw geobserveerde hosts ervoor ten opzichte van de kritieke PHP-kwetsbaarheid uit 2026 (CVSS 9.8) die wordt besproken in A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? en het Security Exposure Survey 2026.

Met slechts 18 hosts die PHP bekendmaken, zeggen aantallen meer dan percentages. Dertien van de 18 draaien een gecorrigeerde versie uit 2026 — ze verbergen de versie niet, maar ze werken wel bij. De drie end-of-life-sites zijn een Italiaanse automobielclub, een Australisch telecombedrijf en een Peruaanse instantie voor sociale verzekeringen; geen ervan is een betaal- of bankdienst. Dat staat in scherp contrast met de algemene Japanse sites in het Security Exposure Survey 2026, waar 52.3% van de sites die PHP bekendmaakten een end-of-life-versie toonde.

Beperkingen en kanttekeningen

• Niet-ingrijpende observatie: één DNS-opvraging, één TLS-handshake en één HTTP GET per site (plus één extra handshake voor de kolom TLS 1.0/1.1 in tabel B). Er is geen aanval geprobeerd.
• Blootstellingscijfers zijn bovengrenzen; een oude versiestring kan via backports al gepatcht zijn.
• De identificatie van merk naar site was geautomatiseerd: bij de handmatige controle van alle 920 hosts bleken er 212 (23.0%) verkeerd geïdentificeerd en 28 niet te bepalen. De totalen en de tabellen A en B gebruiken alleen de 680 hosts die slaagden, maar ook een handmatige controle kan fouten missen.
• Suggesties geven de vraag slechts bij benadering weer. Ze verschillen per regio, taal en moment, en hetzelfde merk levert op Google en Bing andere kandidaten op. De probleemwoordenschat is per taal vastgesteld en is niet uitputtend.
• Sommige landen hebben kleine steekproeven. Japan heeft 18 hosts; de percentages zijn indicatief en staan met aantallen vermeld. Landen worden niet gerangschikt.
• De timing verschilt: suggesties zijn verzameld van 24 tot 26 oktober, observaties gedaan van 22 tot 26 oktober.
• CSP, cookie-attributen en certificaten vallen hier buiten (zie het Security Exposure Survey 2026).

Wat beheerders moeten controleren

1. Schakel HSTS in. Bij 20.1% van de betaal- en banksites ontbrak het. Door Strict-Transport-Security: max-age=31536000; includeSubDomains terug te sturen, worden gebruikers die HTTP proberen vastgezet op HTTPS.
2. Schakel TLS 1.3 in en TLS 1.0/1.1 uit. 16.4% van de betaal- en banksites bleef steken op TLS 1.2.
3. Verberg serverversies (expose_php = Off, ServerTokens Prod, server_tokens off) — nadat u hebt bijgewerkt.
4. Vervang end-of-life-versies. Stap bij PHP over op 8.3 of hoger en op de gecorrigeerde releases uit 2026 (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) of nieuwer. De stapsgewijze procedure staat in How to upgrade PHP in practice.
5. Controleer uw eigen site. Voer een URL in bij de serverinformatiecheck (/server/) van Site Scouter om met dezelfde methode als in dit artikel in ongeveer tien seconden te zien wat uw server aan de buitenwereld laat zien (TLS, HSTS, serverheaders, certificaat, cookie-attributen). Registratie is niet nodig.

Gerelateerd: A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? (blog van de auteur) / Security Exposure Survey 2026 (Site Scouter)

Veelgestelde vragen

Is dit een aanval?

Nee. Elke site kreeg dezelfde toegang als wanneer u hem één keer in een browser opent, en er zijn alleen publieke HTTP-responsen en DNS-gegevens gebruikt.

Zijn de diensten in tabel B gevaarlijk?

Tabel B somt configuratietekortkomingen op die op het vermelde moment uit publieke informatie waarneembaar waren; er wordt niet mee vastgesteld dat een site kan worden binnengedrongen. Een ontbrekende HSTS-header of een zichtbare versie lekt op zichzelf geen gegevens; het zijn tekortkomingen waarvan de impact groeit in combinatie met andere omstandigheden.

Waarom ze bij naam noemen?

De feiten zijn TLS-instellingen en HTTP-headers — publieke informatie die iedereen met dezelfde stappen kan reproduceren. Aanvallers kennen ze al, dus publicatie voegt weinig risico toe, terwijl gebruikers en beheerders er baat bij hebben de staat van hun diensten te kennen. Er is vooraf geen melding gestuurd voordat dit werd gepubliceerd.

Waar stuur ik vragen of correcties naartoe?

Naar de contactgegevens van de auteur onderaan deze pagina. Als een instelling na de observatie is gecorrigeerd, observeer ik opnieuw en voeg ik een notitie toe.

Zijn de gegevens aangepast?

Suggesties zijn per ophaaltaak toegevoegd en observatieresultaten zijn opgeslagen in een tabel waaraan alleen kan worden toegevoegd. Tijdens het aggregeren is de vergelijkingsmethode voor het probleemzoekaandeel herzien (§3) en het aandeel opnieuw berekend; het artikel gebruikt de herberekende waarden, en de waarden van vóór de correctie worden niet gepubliceerd.

Bronnen

Laatst gecontroleerd: 2026-10-28. Specificaties en beleid kunnen veranderen; raadpleeg de primaire bronnen voordat u actie onderneemt.

• MDN: Strict-Transport-Security
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• PHP: Supported Versions (php.net)
• NVD - National Vulnerability Database (NIST)
• Egosaru (search suggestion tool)