Tutkimus · ResaHost · · Päivitetty 14.9.2026
Huijauslasku nimissäsi, murto sivustollasi: mitä audit paljastaa?
Asiakkaasi saa yrityksesi nimissä laskun, jonka rahat päätyvät huijarille. Tai vanhan lisäosan tietoturva-aukko antaa hyökkääjälle pääsyn sivustoosi. ResaHostin 209 auditiraportin tutkimuksessa löytyi puutteita, jotka voivat altistaa tällaisille uhkille.
Audit auttaa löytämään korjattavaa ennen vahinkoa. Se tarkistaa ulospäin näkyviä sähköpostiasetuksia, ohjelmistoversioita ja sivuston suojauksia. Tutkimuksessa ei selvitetty tapahtuneita murtoja: alla kuvatut uhkat ovat mahdollisia seurauksia, jos puute on hyödynnettävissä.
Tutkimus koski 165 verkkotunnusta. Kunkin luvun yhteydessä kerrotaan, kuinka monesta kohteesta kyseinen asia voitiin mitata. Tulokset eivät kuvaa kaikkia suomalaisyrityksiä.
1. Huijari voi esiintyä yrityksenäsi
Asiakas tunnistaa lähettäjän osoitteen ja maksaa laskun. Tilinumero kuuluu kuitenkin huijarille. Rahojen lisäksi vaarassa on asiakkaan luottamus yritykseesi.
51 verkkotunnukselta 85:stä (60 %) ei löytynyt DMARC-tietuetta. DMARC on sähköpostin asetus, jolla yritys kertoo vastaanottajalle, miten sen nimissä tulevia, lähettäjän tunnistuksen hylkäämiä viestejä pitäisi käsitellä.
Lisäksi 22 verkkotunnuksella asetus oli pelkässä seurantatilassa. Yhteensä 73/85 eli 85,9 %:ssa tietuetta ei löytynyt tai se ei pyytänyt väärennettyjen viestien karanteenia tai hylkäystä. Tämä ei todista, että huijausviesti menisi perille: myös vastaanottajan suodatus ja mahdollinen yläverkkotunnuksen suojaus vaikuttavat.
Mitä audit antaa sinulle? Havainnon, jonka perusteella ylläpitäjä voi selvittää yrityksesi sähköpostisuojauksen. Oikein asetettu DMARC auttaa torjumaan oman verkkotunnuksesi väärentämistä. Se ei estä kaikkia huijauksia, kuten kaapatulta sähköpostitililtä lähetettyä viestiä. Lähde: NCSC.
2. Vanha lisäosa voi avata pääsyn sivustoosi
Sivusto voi näyttää täysin normaalilta, vaikka sen lisäosassa olisi tunnettu tietoturva-aukko. Jos hyökkääjä pystyy käyttämään aukkoa, hän voi esimerkiksi muuttaa sisältöä tai lisätä sivulle haitallista koodia. Seurauksena voi olla käyttökatko, puhdistustyö ja menetettyä myyntiä.
46 sivustolla 73:sta (63 %) havaittiin vähintään yksi vertailuversiota vanhempi lisäosa. Pelkkä vanha versio ei todista tietoturva-aukkoa. Se kertoo, että asennettu versio ja saatavilla olevat korjaukset pitää selvittää.
Riski on todellinen: vuonna 2024 Really Simple Security -lisäosan vika mahdollisti tietyillä asetuksilla pääsyn ylläpitäjän tilille. Tätä vikaa ei todettu tutkimuksemme sivustoilla; se on esimerkki siitä, mitä korjaamaton lisäosavika voi aiheuttaa. Lähde: haavoittuvuuden löytänyt Wordfence.
Mitä audit antaa sinulle? Julkisesti tunnistetut lisäosaversiot ylläpitäjän tarkistettavaksi. Ylläpitäjä varmistaa asennetut versiot ja korjaustarpeen, ottaa varmuuskopion sekä testaa sivuston päivityksen jälkeen.
3. Toimiva sivusto voi pyöriä ohjelmistolla, jonka tuki on päättynyt
PHP on ohjelmisto, jolla palvelin suorittaa esimerkiksi WordPressiä. Kun version tuki päättyy, PHP-projekti ei enää toimita siihen tietoturvakorjauksia. Sivun normaali toiminta ei kerro, saako sen taustalla oleva ohjelmisto korjauksia.
9 tunnistettua PHP-versiota 25:stä (36 %) kuului PHP-projektin tuen ulkopuoliseen haaraan. Palveluntarjoaja voi silti toimittaa vanhaan versioon omia korjauksia. Audit ei varmistanut tällaista jatkotukea, eikä muiden sivustojen versiota saatu tunnistettua.
Mitä audit antaa sinulle? Tunnistetun version ja syyn selvittää sen tukitilanne palveluntarjoajalta. Jos korjauksia ei toimiteta, ohjelmisto pitää päivittää tuettuun versioon. PHP:n päättyneet versiohaarat · Mitä palveluntarjoajan omat korjaukset tarkoittavat?
Miltä oman yrityksesi tilanne näyttää?
ResaHostin maksuton audit näyttää ulospäin havaittavia puutteita, jotka voivat jäädä sivuston normaalissa käytössä huomaamatta. Raportti antaa lähtökohdan korjaustarpeen selvittämiseen.
Audit ei kirjaudu ylläpitoosi eikä takaa, että sivusto olisi turvallinen. Jos raportista löytyy korjattavaa, voimme käydä havainnot kanssasi läpi ja selvittää, mitä ylläpidossa pitää tehdä.
Kaikki 20 havaintoa ja tutkimuksen tausta
Selvitys perustuu 209 raporttiin, jotka oli tallennettu ResaHostin auditointipalveluun 12.8.–10.9.2026. Raportit koskivat 165 eri verkkotunnusta. Jokaisesta valittiin uusin tallennettu raportti. Niistä 128 sisälsi tähän tilastointiin soveltuvat rakenteiset diagnostiikkatiedot.
Luvut kuvaavat auditoituja verkkotunnuksia. Aineistosta ei voi vahvistaa erillisten yritysten määrää. Eri testeihin kelpuutettujen kohteiden määrät vaihtelevat, joten jokaisen prosentin yhteydessä kerrotaan myös lukumäärä.
Uhkat liittyvät siihen, mitä hyökkääjä voisi tehdä, jos suojausten puute yhdistyisi hyödynnettävään heikkouteen. Tässä selvityksessä ei tutkittu tapahtuneita tietomurtoja tai huijauksista syntyneitä rahallisia vahinkoja.
51 sähköpostidomainilta ei löytynyt DMARC-tietuetta
Sähköpostin MX-tietue löytyi 85 verkkotunnukselta. Niistä 51:ltä eli 60,0 prosentilta audit ei löytänyt DMARC-tietuetta kysytystä DNS-nimestä. DMARC kertoo vastaanottavalle sähköpostipalvelulle, miten lähettäjän tunnistuksen läpäisemättömiä viestejä halutaan käsiteltävän. SPF ja DKIM tuottavat tunnistamiseen tarvittavaa tietoa. NCSC:n sähköpostisuojausohje
Lisäksi 22 verkkotunnuksella eli 25,9 prosentilla DMARC-politiikka oli p=none. Se ei itsessään pyydä hylkäämään viestiä tai siirtämään sitä karanteeniin. Tällainen politiikka voi olla perusteltu käyttöönoton vaihe, kun yrityksen oikeita lähetysjärjestelmiä kartoitetaan. Raportoinnin toimivuus vaatii myös siihen liittyvät asetukset. NCSC: DMARC-politiikan käyttöönotto
Yhteensä 73:ssa 85 verkkotunnuksesta eli 85,9 prosentissa DMARC-tietuetta ei löytynyt kysytystä nimestä tai löydetyn tietueen politiikka oli p=none. Muissa 12:ssa politiikka pyysi karanteenia tai hylkäystä: 11:ssä quarantine ja yhdessä reject.
Yritykselle olennainen uhka on lähettäjän väärentäminen. Kuvitteellisessa tapauksessa asiakas saa tutulta yritykseltä näyttävän laskun, jonka maksutiedot ohjaavat huijarin tilille. Jos väärennetty lähettäjäosoite läpäisee vastaanottajan tarkastukset, vahinko voi syntyä asiakkaan maksusta ja yrityksen nimissä toimimisesta. DMARC auttaa torjumaan oman verkkotunnuksen väärentämistä, mutta se ei ratkaise kaikkia huijaustapoja. Esimerkiksi samannäköinen vieras verkkotunnus ja kaapattu oikea sähköpostitili ovat eri ongelmia. NCSC:n ohje
Auditin DNS-havainto ei osoita, että jokaisen näistä 73 verkkotunnuksesta voisi väärentää onnistuneesti. Vastaanottajan omat suodattimet sekä mahdollinen yläverkkotunnuksesta periytyvä DMARC-politiikka vaikuttavat lopputulokseen. Niitä ei varmennettu tässä tilastossa. DMARC-määrittely: politiikan haku ja vastaanottajan päätös
SPF-tietuetta ei löytynyt viideltä 85:stä eli 5,9 prosentilta. DKIM-tietue puolestaan löytyi vähintään yhdellä testatulla selektorilla 36:lta 128 verkkotunnuksesta eli 28,1 prosentilta. DKIMin löytymättömyydestä ei laskettu puutetta, koska tunnistin ei tunne kaikkia mahdollisia selektorinimiä.
Ylläpitäjän seuraava työ on selvittää kaikki oikeat lähettäjät, myös laskutus-, uutiskirje- ja asiakkuudenhallintajärjestelmät. Sen jälkeen SPF, DKIM ja DMARC sovitetaan yhteen ja tiukempaan käsittelyyn siirrytään hallitusti. Näin myös oikeiden viestien toimitus voidaan varmentaa. NCSC: väärennettyjen viestien hylkääminen
46 sivustolla lisäosaversio oli vertailuversiota vanhempi
WordPress tunnistettiin 89 sivustolla 128:sta eli 69,5 prosentilla. Lisäosavertailuun kelpasi 73 sivustoa, joilta saatiin vähintään yhdelle lisäosalle numeerinen havaittu versio ja WordPress.orgista haettu vertailuversio.
Näistä 46:ssa eli 63,0 prosentissa vähintään yksi lisäosaversio oli vertailuversiota vanhempi. Versio tunnistettiin julkisista tiedostoista tai sivun resurssien versionumeroista. Ylläpitoon kirjautumalla tehtyä asennusluettelon varmennusta aineistossa ei ollut.
Päivitysviive muuttuu hyökkäysriskiksi silloin, kun käytössä olevaan versioon sisältyy hyödynnettävä haavoittuvuus. Seuraukset riippuvat viasta. Hyökkääjä voi esimerkiksi saada ylläpitäjän oikeuksia, muuttaa sivuston sisältöä tai lisätä haitallista koodia. Pelkkä uudemman version olemassaolo ei vielä todista tällaista vikaa.
Historiallinen esimerkki riskistä on Really Simple Security -lisäosasta vuonna 2024 löydetty tunnistautumisen ohitus. Tietyissä versioissa ja asetuksissa hyökkääjä saattoi päästä myös ylläpitäjän tilille. Tämä on ulkopuolinen esimerkki haavoittuvuuden seurauksesta; selvitys ei osoita kyseisen haavoittuvuuden esiintyneen ResaHostin aineistossa. Haavoittuvuuden löytäneen Wordfencen kuvaus
Päivityksille tarvitaan nimetty vastuuhenkilö, toimiva varmuuskopio ja tapa todeta sivuston toiminta päivityksen jälkeen. Käyttämättömät lisäosat on syytä poistaa. WordPressin oma ylläpito-ohje nostaa lisäosien ajantasaisuuden ja tarpeettomien lisäosien poistamisen suojaustoimiksi. WordPressin suojausohje
Yhdeksällä sivustolla havaittiin PHP-projektin tuen ulkopuolinen versio
PHP:n numeerinen versio tunnistettiin 25 sivustolta 128:sta eli 19,5 prosentilta. Näistä seitsemän käytti havainnon perusteella PHP 5- tai 7-sarjaa. Kun mukaan lasketaan kaksi PHP 8.0 -havaintoa, yhdeksän 25:stä eli 36,0 prosenttia kuului PHP-projektin tuen ulkopuoliseen versiohaaraan.
Havaitut haarat olivat PHP 5.3, 5.4, 7.2, 7.4 ja 8.0. Viimeisimpänä näistä PHP 8.0:n tuki päättyi 26.11.2023. PHP-projekti varoittaa, että vanhoissa haaroissa voi olla haavoittuvuuksia ja virheitä, jotka on korjattu uudempiin versioihin. PHP:n päättyneet versiohaarat
Uhka on korjausten puuttuminen palvelimen suorittamasta ohjelmistosta. Sivusto voi näyttää normaalilta, vaikka sen käyttämän ohjelmiston alkuperäinen ylläpitäjä ei enää toimita korjauksia. Tietyn vian hyödyntäminen riippuu silti palvelimen asetuksista ja käytetystä sovelluksesta.
Näkyvä versionumero ei ratkaise koko tukitilannetta. Palveluntarjoaja voi toimittaa korjauksia vanhaan versioon muuttamatta sitä uusimmaksi pääversioksi. Siksi ylläpitäjältä tarvitaan tieto käytössä olevasta ohjelmistopaketista, sen korjauksista ja mahdollisesta jatkotuesta. Red Hatin kuvaus korjausten backportauksesta
Luku 36 prosenttia koskee vain niitä 25 sivustoa, joiden versio tunnistettiin. Muiden 103 sivuston PHP-versiota tai edes PHP:n käyttöä ei voi ratkaista tästä havainnosta.
Selaimen suojauksissa näkyi puutteita
CSP-header puuttui 102 HTTP-vastauksesta 127:stä eli 80,3 prosentista. Oikein määritetty Content Security Policy voi rajata, mistä sivu saa suorittaa JavaScriptiä ja ladata sisältöä. Se voi pienentää esimerkiksi XSS-hyökkäyksen vaikutusta, jos hyökkääjän syöte pääsee sivulle suoritettavaksi koodiksi. MDN: Content Security Policy
Tällaisen hyökkäyksen mahdollisia seurauksia ovat sivun sisällön muuttaminen tai toimintojen tekeminen kirjautuneen käyttäjän oikeuksilla. Kuvitteellisessa verkkokauppatapauksessa haitallinen selainkoodi voisi pyrkiä keräämään asiakkaan lomakkeelle kirjoittamia tietoja. CSP:n puuttuminen ei kuitenkaan yksin osoita, että koodin syöttäminen sivulle onnistuisi. Myös HTML:n meta-elementissä määritelty CSP jäi tämän header-mittarin ulkopuolelle. MDN:n kuvaus XSS-suojauksesta
X-Frame-Options puuttui 92 vastauksesta eli 72,4 prosentista. Headerilla voidaan rajoittaa sivun upottamista toisen sivun sisään. Ilman toimivaa upotusrajoitusta hyökkääjän sivu voi sopivassa tilanteessa johtaa käyttäjän klikkaamaan kohdesivun toimintoa harhaanjohtavan näkymän kautta. Tätä kutsutaan clickjackingiksi. Vastaava rajoitus voi tulla CSP:n frame-ancestors-asetuksesta, joten pelkkä X-Frame-Optionsin puute ei osoita suojauksen puuttumista. MDN: X-Frame-Options
X-Content-Type-Options puuttui 88 vastauksesta eli 69,3 prosentista. Sen nosniff-arvo rajoittaa selaimen tekemää tiedostotyypin arvailua. Oikean Content-Type-määrityksen kanssa se auttaa estämään tilanteita, joissa sisältö käsiteltäisiin suoritettavana tiedostona väärän tulkinnan vuoksi. MDN: X-Content-Type-Options
Referrer-Policy puuttui 113 vastauksesta eli 89,0 prosentista, ja Permissions-Policy 115 vastauksesta eli 90,6 prosentista. Ensin mainittu säätelee mukana lähetettäviä viittaustietoja. Jälkimmäisellä voi rajata selaimen ominaisuuksia sivulla ja sen upotuksissa. Nämä suuret osuudet eivät tarkoita vastaavaa tietovuotojen määrää: selaimilla on oletuskäytäntöjä, eikä Permissions-Policyn puuttuminen ohita esimerkiksi kameran käyttöön tarvittavaa käyttäjän lupaa. MDN: Referrer-Policy, MDN: Permissions-Policy
HTTPS-yhteyden lisäksi myös sivun resurssit tarvitsevat salauksen
HSTS-header puuttui 84 vastauksesta 127:stä eli 66,1 prosentista. HSTS ohjaa selaimen käyttämään kyseiseen verkkotunnukseen HTTPS-yhteyttä. Jos selaimelta puuttuu tällainen käytäntö ja yhteys alkaa HTTP:llä, verkossa oleva hyökkääjä voi tietyissä olosuhteissa puuttua salaamattomaan alkuvaiheeseen. Aiemmin tallentunut HSTS-käytäntö, yläverkkotunnuksen asetus tai selaimen preload-lista voi silti suojata yhteyttä. MDN: HSTS
HTTP-resurssiviite kirjattiin kuuteen raporttiin 127:stä eli 4,7 prosenttiin. Jos resurssi todella siirtyy salaamattomana, verkossa oleva hyökkääjä voi päästä lukemaan tai muuttamaan sitä. Selaimet kuitenkin päivittävät osan pyynnöistä HTTPS:ään ja estävät osan latauksista. Käytännön seuraus voi siten olla myös puuttuva kuva tai toimimaton toiminto. Auditissa ei varmennettu selaimen toteuttamaa latausta. MDN: Mixed content
Salausprotokollasta löytyi myös myönteinen havainto: 120 yhteyttä 127:stä eli 94,5 prosenttia muodostui TLS 1.3:lla. Muissa seitsemässä käytettiin TLS 1.2:ta. Yhteyden salaus ei kuitenkaan kerro lisäosien päivityksistä tai sähköpostin lähettäjäsuojauksesta.
Julkinen tekijätieto ja vanhempi protokolla eivät ole sama asia kuin haavoittuvuus
59 WordPress-sivustolta 80:stä eli 73,8 prosentilta löytyi julkinen tekijätieto tai ohjaus tekijäsivulle. Julkinen nimi voi antaa taustatietoa esimerkiksi kohdennetun huijausviestin laatimiseen. Tästä ei silti voi päätellä, että kirjautumistunnus tai salasana olisi vuotanut. Tekijän nimen julkaiseminen voi kuulua sivuston tarkoitukseen.
93 verkkotunnukselle 125:stä eli 74,4 prosentille ei löytynyt IPv6:n AAAA-tietuetta. Yhdeksässä testiyhteydessä 121:stä eli 7,4 prosentissa ei käytetty HTTP/2:ta. Nämä ovat teknisiä havaintoja. Niistä ei sellaisinaan seuraa tietoturvauhkaa tai näyttöä hitaasta sivustosta.
Korjaustyö kannattaa aloittaa lähettäjistä ja ohjelmistoversioista
Tulkintamme on, että tämän aineiston perusteella ensimmäiseksi kannattaa selvittää sähköpostin lähetysjärjestelmät ja havaittujen ohjelmistoversioiden päivitys- tai tukitilanne. Niistä saadaan konkreettiset vastuutehtävät: kuka vastaa yrityksen nimissä lähetettävien viestien tunnistamisesta, kuka lisäosapäivityksistä ja kuka palvelimen ohjelmistotuesta.
Selaimen suojaukset käydään tämän jälkeen läpi sivuston todellista toimintaa vasten. CSP ja upotusrajoitukset sovitetaan käytössä oleviin palveluihin. HSTS:n yhteydessä varmistetaan HTTPS:n toimivuus myös niillä aliverkkotunnuksilla, joihin asetus ulottuu.
Päivitysten tai headerien lukumäärä ei kerro hyökkäyksen todennäköisyyttä. Yrityksen kannalta ratkaiseva lopputulos on nimetty ylläpitäjä, sovittu korjaus ja varmistus siitä, että sivusto sekä sähköposti toimivat muutoksen jälkeen.
Näin selvitys tehtiin
ResaHost teki selvityksen oman auditointipalvelunsa säilyneistä raporteista. Aineisto poimittiin 10.9.2026 klo 13.24.59 Suomen aikaa. Se ei ole satunnaisotos suomalaisista yrityksistä. ResaHost tarjoaa verkkosivujen ylläpitopalveluja, joten selvityksellä on myös kaupallinen yhteys sen toimintaan.
Saman verkkotunnuksen eri raportit yhdistettiin, ja kustakin käytettiin uusinta tallennettua raporttia. Uusin tallennus ei välttämättä ole uusin mittaus. Vanhoja raportteja on voitu poistaa säilytysajan perusteella, joten 209 raporttia ei tarkoita palvelun kaikkia koskaan tehtyjä auditeja.
Kunkin havainnon nimittäjään otettiin vain kyseiseen laskentaan kelpaavat raportit. Puuttuvaa diagnostiikkaa ei laskettu puutteeksi. Kuuden headerin tallennetut tilat verrattiin erikseen tallennettuihin raakavastauksiin: kussakin vertailussa oli 127 kohdetta ja nolla ristiriitaa. HTML-haun onnistumista ei voitu varmentaa kaikille kielteisille resurssihavainnoille. Kohdesivustoja ei skannattu uudelleen tätä artikkelia varten.
Auditin lisäosien haavoittuvuusluokitusta, yleistä WordPressin vanhentuneisuuslippua ja epävarmoja evästehallinnan puuttumishavaintoja ei käytetty uhkien esiintymismäärien laskemiseen. Artikkelin hyökkäysesimerkit kuvaavat mahdollisia seurauksia, eivät tässä aineistossa todennettuja tapahtumia.
Kaikki 20 havaintoa ja niiden laskentaperusteet sekä poiminnan luvut muodostavat tämän artikkelin tilastolähteen. PHP:n tukitilanne tulkittiin 10.9.2026 tilanteeseen. Uudet johdetut luvut ovat 73/85 = 85,9 prosenttia ja 9/25 = 36,0 prosenttia.
Kaikki 20 havaintoa
Lukumäärät koskevat eri verkkotunnusten uusimpia tallennettuja raportteja. Sama verkkotunnus voi esiintyä usealla rivillä. Osuuksia ei lasketa yhteen. Lukumäärän jälkimmäinen luku on kyseiseen vertailuun kelpuutettu otoskoko.
Laskentaperusteet ja rajaukset
Verkkotunnuksista yhtenäistettiin isot ja pienet kirjaimet, www-alku sekä nimen lopun piste. Muita aliverkkotunnuksia ei yhdistetty.
- DMARC-tietuetta ei löytynyt auditin DNS-kyselyssä. MX-tietue löytyi ja DMARC-kysely tuotti tuloksen; moduuli- ja kyselyvirheet poistettu. Havainto koskee kysyttyä nimeä, ei todista kaiken sähköpostisuojauksen puuttumista.
- DMARC-politiikka oli p=none. Sama MX-joukko kuin kohdassa 1. Tietue ei p-kentässään pyydä karanteenia tai hylkäystä; tämä ei ole testi viestien toimituksesta.
- DMARC-politiikka pyysi karanteenia tai hylkäystä. Sama MX-joukko. Näistä 11:llä p=quarantine ja yhdellä p=reject. Vastaanottajien toiminta, pct-arvo ja SPF/DKIM alignment eivät ole tämän laskelman kohteena.
- SPF-tietuetta ei löytynyt auditin DNS-kyselyssä. MX-tietue löytyi ja SPF-tarkistus tuotti tuloksen. Ei väitettä toteutuneista sähköpostiväärennöksistä.
- DKIM-tietue löytyi vähintään yhdellä testatulla selektorilla. Positiivinen DNS-löydös. 128 raportissa oli tulos. Muista ei päätellä DKIMin puuttumista, sillä tunnistin kokeilee rajattua selektorilistaa.
- HSTS-header puuttui auditin HTTP-vastauksesta. 127 raportissa onnistunut HTTP-status 200–399 ja tallennetut headerit. Kuvaa kyseistä vastausta; ei koko selaimen HTTPS-suojauksen auditointi.
- Content-Security-Policy-header puuttui auditin HTTP-vastauksesta. Sama 127 raportin header-joukko. HTML:n CSP-meta ja muut suojauskeinot eivät sisälly tähän mittariin.
- X-Frame-Options-header puuttui auditin HTTP-vastauksesta. Sama header-joukko. Esimerkiksi CSP:n frame-ancestors voi toteuttaa vastaavan rajoituksen.
- X-Content-Type-Options-header puuttui auditin HTTP-vastauksesta. Sama header-joukko. Mittaa headerin olemassaoloa, ei sisällön hyväksikäytettävyyttä.
- Referrer-Policy-header puuttui auditin HTTP-vastauksesta. Sama header-joukko. Selaimen oletukset ja HTML-meta eivät ole tämän laskennan kohteena.
- Permissions-Policy-header puuttui auditin HTTP-vastauksesta. Sama header-joukko. Puuttuminen ei osoita, että sivusto olisi saanut käyttäjän laiteoikeuksia.
- Teknologiatunnistin tunnisti WordPressin. 128 uusimmassa raportissa oli teknologiatunnistimen rakenne. Muut alustat ja havaitsematta jääneet WordPress-asennukset ovat mahdollisia.
- Audit tunnisti vähintään yhden lisäosaversion, joka oli WordPress.orgin vertailuversiota vanhempi. Vertailuun kelpuutettiin 73 sivustoa, joilta saatiin vähintään yhdelle lisäosalle havaittu ja WordPress.orgin vertailuversio. Kummankin version tuli sisältää 2–3 numeerista osaa ja vertailun onnistua. Löydökseksi laskettiin vähintään yksi vanhempi versio. Julkisista tiedostoista pääteltyä asennusversiota ei varmennettu kirjautumalla.
- WordPress-sivustolta löytyi julkinen tekijätieto tai ohjaus tekijäsivulle. 80 WordPressiksi tunnistettua sivustoa, joilla löytyi positiivinen tulos tai kumpikaan tarkistetuista reiteistä ei jäänyt testaamatta. Ei tarkoita salasanavuotoa tai kirjautumistunnuksen paljastumista.
- PHP:n numeerinen versio saatiin tunnistettua. Versio tunnistettiin 25 sivustolta 128 diagnostiikkaraportista. Tuntemattomat ja muut ei-numeeriset arvot eivät kelvanneet löydökseksi. Muiden 103 sivuston tilanne jää avoimeksi.
- Tunnistettu PHP-versio kuului 5- tai 7-sarjaan. Vain 25 sivustoa, joiden PHP-versio tunnistettiin. PHP 5 -sarjaa kaksi ja PHP 7 -sarjaa viisi. Ei laskelma kaikista tuen ulkopuolisista PHP-versioista.
- Auditoidulle verkkotunnukselle ei löytynyt IPv6:n AAAA-tietuetta. 125 eksplisiittistä DNS-tulosta. Timeoutit ja tuntemattomat jätetty pois. Ei testi yrityksen koko IPv6-valmiudesta.
- HTTP/2:ta ei käytetty auditin testiyhteydessä. 121 eksplisiittistä protokollatulosta. Ei väitettä kaikista sivuston yhteyksistä tai koetusta nopeudesta.
- Haetusta HTML:stä löytyi salaamattomaan HTTP-osoitteeseen viittaavia resursseja. 127 raportissa oli resurssitarkistuksen tulos ja HTTP-status 200–399. HTML-havainto ei osoita, että selain olisi ladannut resurssin tai että kaikki resurssit olisi tarkastettu. HTML-haun onnistumista ei voitu varmentaa kaikille kielteisille resurssihavainnoille.
- Auditin TLS-yhteys muodostui TLS 1.3:lla. 127 raportissa tunnistettu TLS-versio; muissa seitsemässä TLS 1.2. TLS 1.2:sta ei päätellä turvattomuutta.