Verkkosivuston tietoturvan tarkistus ilman hakkerointia

Verkkokaupan passiiviset tietoturvatarkistukset: TLS-varmenne, HSTS, CSP, nosniff, evästemääritteet, sekasisältö, vanha jQuery, security.txt ja DMARC.

FixReportsin toimitusLukuaika 9 min

Verkkokaupan tietoturva-asetuksista voi tarkistaa paljon ulkopuolelta lukemalla sitä, mitä sivusto jo lähettää jokaiselle kävijälle: TLS-varmenteen, uudelleenohjaukset, HTTP-vastausotsakkeet, evästeet, ladattavat skriptit ja julkiset DNS-tietueet. Nämä passiiviset tarkistukset eivät lähetä hyökkäysliikennettä eivätkä vaadi kirjautumista, joten ne kuormittavat kauppaa yhtä vähän kuin tavallinen käynti. Ne paljastavat kokoonpanon puutteita, kuten vanhenemassa olevan varmenteen, puuttuvan HSTS:n, turvattomat evästeet, sekasisällön tai jQuery-version, jossa on tunnettuja haavoittuvuuksia. Ne eivät ole tunkeutumistestaus, eivätkä ne voi todistaa, että kauppa on turvallinen.

Tärkeimmät kohdat

  • Julkisesti luotetut TLS-varmenteet, jotka on myönnetty 15.3.2026 tai sen jälkeen, voivat olla voimassa enintään 200 päivää; raja laskee 100 päivään maaliskuussa 2027 ja 47 päivään maaliskuussa 2029 (CA/Browser Forum (avautuu uuteen välilehteen)).
  • Selaimet ohittavat HSTS-otsakkeen, jos se lähetetään salaamattoman HTTP-yhteyden kautta (MDN (avautuu uuteen välilehteen)).
  • CSP:n frame-ancestors-direktiivi ei toimi <meta>-tagissa; sen on oltava vastausotsake (MDN (avautuu uuteen välilehteen)).
  • jQueryn 3.5.0:aa vanhemmat versiot ovat alttiita kahdelle XSS-haavoittuvuudelle, ja CISA lisäsi niistä toisen, CVE-2020-11023:n, tunnetusti hyödynnettyjen haavoittuvuuksien luetteloonsa (Known Exploited Vulnerabilities) 23.1.2025 (NVD (avautuu uuteen välilehteen)).
  • security.txt-tiedostossa on oltava kentät Contact ja Expires, ja sen on sijaittava polussa /.well-known/security.txt (RFC 9116 (avautuu uuteen välilehteen)).

Mikä lasketaan passiiviseksi tietoturvatarkistukseksi?

Passiivinen tarkistus lukee vain sen, mitä sivusto tai sen DNS palauttaa tavalliseen pyyntöön.

Tämä tarkoittaa julkisten sivujen lataamista, varmenteen ja vastausotsakkeiden lukemista, sivun asettamien evästeiden ja skriptien listaamista sekä julkisten DNS-tietueiden kyselyä. Passiivinen tarkistus ei arvaa salasanoja, lähetä injektiohyötykuormia (injection payloads), koettele hallintapaneelien URL-osoitteita eikä skannaa portteja. Kaiken alla kuvatun voi tehdä selaimella sekä työkaluilla curl, openssl ja dig.

Miten tarkistat TLS-varmenteen ja sen vanhenemisen?

Lue varmenteen päivämäärät ja nimet suoraan ja varmista, että uusiminen on automatisoitu.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Tarkista, että notAfter on reilusti tulevaisuudessa, että varmenne kattaa sekä osoitteen example.com että osoitteen www.example.com, jos käytät molempia (selaimen varmennenäkymä luettelee nimet), ja ettei selain näytä varoituksia. Varmenteiden voimassaoloajat lyhenevät CA/Browser Forumin Baseline Requirements -vaatimusten (kohta 6.3.2, versio 2.3.1 lokakuussa 2026) mukaisesti. Muutos perustuu 11.4.2025 hyväksyttyyn äänestykseen SC-081v3 (avautuu uuteen välilehteen):

Varmenne myönnettyEnimmäisvoimassaolo
Ennen 15.3.2026398 päivää
15.3.2026 ja 14.3.2027 välisenä aikana200 päivää
15.3.2027 ja 14.3.2029 välisenä aikana100 päivää
15.3.2029 alkaen47 päivää

Lyhyet voimassaoloajat tekevät manuaalisesta uusimisesta riskialtista, joten varmista, että palveluntarjoajasi tai varmennetyökalusi uusii varmenteen automaattisesti. Varmista myös, että salaamaton HTTP ohjautuu HTTPS:ään:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Tavoitteena on vastaus 301 (tai 308) ja location-otsake, joka alkaa https://.

Mitä tietoturvaotsakkeita verkkokaupan pitäisi lähettää?

Pieni joukko vastausotsakkeita torjuu yleisiä selainpuolen hyökkäyksiä lähes ilman kustannuksia.

OtsakeMitä se tekeeTyypillinen arvoLähde
Strict-Transport-SecurityKäskee selaimia käyttämään vain HTTPS:ää ja estää käyttäjiä ohittamasta varmennevirheitämax-age=31536000; includeSubDomainsMDN (avautuu uuteen välilehteen)
Content-Security-Policy: frame-ancestorsMäärää, mitkä sivustot saavat upottaa sivujasi, mikä suojaa clickjacking-hyökkäyksiltäframe-ancestors 'self'MDN (avautuu uuteen välilehteen)
X-Frame-OptionsVanhempi upotuksen hallintakeino; OWASPin mukaan frame-ancestors tekee sen tarpeettomaksi sitä tukevissa selaimissaDENY tai SAMEORIGINOWASP (avautuu uuteen välilehteen)
X-Content-Type-OptionsEstää MIME-tyypin arvaamisen (MIME sniffing) ja torjuu skriptit ja tyylitiedostot, jotka tarjoillaan väärällä tyypillänosniffMDN (avautuu uuteen välilehteen)
Referrer-PolicyRajoittaa, kuinka suuri osa URL-osoitteistasi lähetetään muille sivustoillestrict-origin-when-cross-originOWASP
X-XSS-ProtectionSelaimen XSS-suodattimen otsake; OWASPin mukaan se voi luoda XSS-haavoittuvuuksia muuten turvallisiin sivustoihinÄlä aseta, tai 0OWASP

Tarkista, mitä kauppasi lähettää:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Kaksi varoitusta. includeSubDomains estää kaikki aliverkkotunnukset, jotka toimivat vain HTTP:n kautta, joten tarkista aliverkkotunnukset ensin. HSTS-esilataus (preload) edellyttää, että max-age on vähintään 31536000 ja että includeSubDomains on mukana, joten lisää preload vasta, kun jokainen aliverkkotunnus on valmis HTTPS:ään. Kattava, skriptejä rajoittava CSP kannattaa ottaa käyttöön, mutta OWASP huomauttaa, että sen määrittäminen ja ylläpito on monimutkaista, ja kauppojen, joissa on paljon sovelluksia, on testattava se huolellisesti.

Onko evästeissäsi määritteet Secure, HttpOnly ja SameSite?

Istunto- ja ostoskorievästeillä pitäisi olla kaikki kolme määritettä, ja näet ne Set-Cookie-vastausotsakkeista.

MääriteVaikutus (MDN:n (avautuu uuteen välilehteen) mukaan)Missä sillä on merkitystä
SecureLähetetään vain HTTPS:n kautta; salaamatonta HTTP:tä käyttävät sivustot eivät voi asettaa sitäJokainen eväste HTTPS-kaupassa
HttpOnlyJavaScript ei voi lukea sitä document.cookie-ominaisuuden kautta, mikä auttaa XSS:ää vastaanKirjautumisistunnot ja ostoskorit
SameSite=Lax tai StrictRajoittaa, milloin eväste lähetetään sivustojen välisissä pyynnöissäIstunnot; Strict sopii todennus- ja ostoskorievästeille
SameSite=NoneLähetetään sivustojen välisissä pyynnöissä; on yhdistettävä Secure-määritteeseenVain upotetut kolmannen osapuolen toiminnot, jotka tarvitsevat sitä

Jos SameSite-määritettä ei ole asetettu, selaimet käsittelevät evästettä Lax-evästeenä. Evästeet, jotka omien skriptiesi on luettava, eivät voi olla HttpOnly-evästeitä, joten keskity niihin, jotka tunnistavat kirjautuneen asiakkaan tai ylläpitäjän.

curl -sI https://example.com/ | grep -i "^set-cookie"

Selaimen kehittäjätyökalut näyttävät samat tiedot, myös evästeet, jotka skriptit asettavat sivun latautumisen jälkeen.

Miten löydät sekasisällön?

Sekasisältöä (mixed content) on mikä tahansa HTTP:n kautta ladattu resurssi HTTPS:n kautta tarjoillulla sivulla, ja selaimen konsoli luettelee sen.

MDN (avautuu uuteen välilehteen) jakaa sen kahteen ryhmään. Kuvat, ääni ja video ovat ”päivitettäviä” (upgradable): selaimet pyytävät ne automaattisesti HTTPS:n kautta. Skriptit, tyylitiedostot, iframe-kehykset, fontit ja fetch()-pyynnöt ovat ”estettäviä” (blockable): selaimet estävät ne, mikä rikkoo kaiken niistä riippuvan. Myös pelkkään IP-osoitteeseen kohdistuvat päivitetyt pyynnöt estetään.

Etsi sekasisältö avaamalla konsoli tärkeimmillä sivupohjilla (etusivu, kokoelma, tuote, ostoskori) ja etsimällä teemasi koodista, sivujen sisällöstä ja sovellusten asetuksista merkkijonoa http://. Shopifyn ohjekeskuksen mukaan jokainen kaupan sivu, jolla on resurssi, jota ei toimiteta HTTPS:n kautta, katsotaan turvattomaksi (avautuu uuteen välilehteen), ja Shopify suosittelee resurssien isännöintiä Shopifyssa tai niiden tarjoilua HTTPS:n kautta. WooCommercessa tarkista vanhojen kirjoitusten sisältö ja teeman asetukset, jos sivusto on joskus toiminut http://-osoitteessa.

Miten tunnistat vanhentuneet JavaScript-kirjastot, joissa on tunnettuja CVE-haavoittuvuuksia?

Listaa kirjastot, jotka kukin sivu lataa, lue niiden versiot ja vertaa niitä National Vulnerability Database -tietokantaan (NVD).

Aloita jQuerysta. Selaimen konsolissa $.fn.jquery palauttaa ladatun version (jQuery API (avautuu uuteen välilehteen)). Versiot, joihin kannattaa kiinnittää huomiota:

CVEHaavoittuvat versiotOngelmaNVD-pisteet (v3.1)
CVE-2020-11022 (avautuu uuteen välilehteen)1.12.0 ja uudemmat, ennen 3.5.0:aaEpäluotettavan HTML:n välittäminen metodeille, kuten .html() tai .append(), voi suorittaa koodia6,1 (keskitaso)
CVE-2020-11023 (avautuu uuteen välilehteen)1.0.3 ja uudemmat, ennen 3.5.0:aaSama <option>-elementtejä sisältävälle HTML:lle; CISA:n KEV-luettelossa 23.1.2025 alkaen6,1 (keskitaso)
CVE-2019-11358 (avautuu uuteen välilehteen)3.4.0:aa vanhemmatPrototyypin saastuttaminen (prototype pollution) jQuery.extend(true, ...)-kutsun kautta6,1 (keskitaso)

Molemmat vuoden 2020 ongelmat on korjattu jQueryn versiossa 3.5.0. Haavoittuva versio tarkoittaa, että virheellinen koodi on mukana; se, voidaanko sitä hyödyntää, riippuu siitä, miten sivusto välittää sille dataa. WordPress on sisältänyt jQueryn version 3.5.1 versiosta 5.6 alkaen (avautuu uuteen välilehteen), joten vanha jQuery WooCommerce-kaupassa viittaa vanhentuneeseen WordPressiin tai teemaan tai lisäosaan, joka lataa oman kopionsa. Shopifyssa tarkista teematiedostosi ja skriptejä lisäävät sovellukset.

Mikä on security.txt ja tarvitseeko kauppasi sellaisen?

Se on tekstitiedosto, joka kertoo tietoturvatutkijoille, miten he voivat ilmoittaa sinulle haavoittuvuudesta.

RFC 9116:n (avautuu uuteen välilehteen) (huhtikuu 2022; Informational-tyyppinen RFC, joten sen noudattaminen on vapaaehtoista) mukaan tiedosto on tarjoiltava HTTPS:n kautta polussa /.well-known/security.txt tyypillä text/plain. Contact ja Expires ovat pakollisia, ja RFC suosittelee Expires-päivämäärää, joka on alle vuoden päässä.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

WooCommercessa voit sijoittaa tiedoston palvelimellesi. Isännöidyllä alustalla tarkista, voitko julkaista tiedoston tähän polkuun; jos et voi, selkeästi merkitty tietoturvayhteystieto yhteystietosivullasi auttaa silti.

Miten DMARC suojaa kauppaasi sähköpostin väärentämiseltä?

DMARCin avulla voit pyytää postilaatikkopalveluja asettamaan karanteeniin tai hylkäämään postin, joka käyttää verkkotunnustasi From-osoitteessa läpäisemättä kohdistettua SPF:ää tai DKIM:ää.

p=none-tasoinen tietue vain kerää raportteja; se ei pysäytä väärennettyä postia. Asiakkaat odottavat tilausvahvistuksia ja salasanan palautusviestejä sinun verkkotunnuksestasi, joten tietojenkalasteluviesti, jossa näkyy täsmälleen sinun verkkotunnuksesi, kannattaa estää. Tarkista käytäntösi komennolla dig +short TXT _dmarc.example.com, ja katso määrittely standardista RFC 9989 (avautuu uuteen välilehteen). DMARC ei kata samannäköisiä verkkotunnuksia, vaan ainoastaan sen verkkotunnuksen, joka julkaisee tietueen.

Mitä Shopify hallinnoi ja mitä sinä hallitset WooCommercessa?

Shopify ylläpitää kauppojensa taustalla olevia palvelimia, kun taas itse ylläpidetyssä WooCommerce-kaupassa palvelinasetukset jäävät sinun ja palveluntarjoajasi vastuulle.

TarkistusShopifyWooCommerce (itse ylläpidetty)
TLS-varmenneIlmainen kaikille Shopifyhin lisätyille verkkotunnuksille (avautuu uuteen välilehteen); kolmannen osapuolen verkkotunnuksilla voi kestää jopa 48 tuntiaPalveluntarjoajasi tai oma kokoonpanosi
Uudelleenohjaus HTTP:stä HTTPS:äänAlustaVerkkopalvelimen, CDN:n tai palveluntarjoajan asetukset
TietoturvaotsakkeetShopifyn palvelimet lähettävätVerkkopalvelin, CDN tai lisäosa
Evästeiden määritteetAlusta asettaa Shopifyn omat evästeet; sovellusten ja teeman evästeet ovat sinun vastuullasiWordPressin ydin, lisäosat ja palvelin
Sekasisältö ja JS-kirjastotTeemasi, sisältösi ja sovelluksesiTeemasi, sisältösi ja lisäosasi
security.txt ja DMARCVerkkotunnuksesi ja DNSVerkkotunnuksesi ja DNS

Kun tarkistimme lokakuussa 2026 useita Shopifyn isännöimiä kauppoja, niiden vastauksissa oli HSTS noin 91 päivän max-age-arvolla, X-Content-Type-Options: nosniff ja CSP, jossa oli upgrade-insecure-requests, kun taas frame-ancestors vaihteli kaupoittain. Shopify kertoo olevansa sertifioitu PCI DSS -tason 1 mukaiseksi (avautuu uuteen välilehteen). Teemasi ja asentamasi sovellukset ovat edelleen sinun vastuullasi.

WooCommercessa WordPressin koventamisopas (avautuu uuteen välilehteen) neuvoo pitämään WordPressin ja lisäosat päivitettyinä, poistamaan lisäosat, joita et käytä, ja kysymään palveluntarjoajaltasi, mitä tietoturvatoimia se tekee.

Miksi tämä ei ole tunkeutumistestaus?

Tunkeutumistestauksessa yritetään aktiivisesti hyökätä; passiiviset tarkistukset vain havainnoivat.

NIST SP 800-115 määrittelee tunkeutumistestauksen (penetration testing) tietoturvatestaukseksi, jossa arvioijat jäljittelevät todellisia hyökkäyksiä löytääkseen keinoja kiertää järjestelmän tietoturvaominaisuudet (NISTin sanasto (avautuu uuteen välilehteen)). Passiiviset tarkistukset eivät näe lisäosien palvelinpuolen virheitä, heikkoja tai uudelleenkäytettyjä ylläpitäjän salasanoja, puuttuvaa kaksivaiheista tunnistautumista, rikkinäistä pääsynhallintaa tai haavoittuvaa koodia, joka ei koskaan näy sivun lähdekoodissa. Käytä niitä lähtötasona, jonka voit toistaa milloin tahansa. Syvällisempää varmuutta varten tilaa tunkeutumistestaus, jolla on kirjallinen rajaus, järjestelmiin, jotka omistat tai joiden testaamiseen sinulla on lupa.

Ilmainen skannaus tekee kaupallesi ensimmäisen tarkistuskierroksen. Verkkosivuston tietoturvaraportti kattaa tämän artikkelin passiiviset tarkistukset TLS:stä ja uudelleenohjauksista otsakkeisiin, evästeisiin, sekasisältöön, vanhentuneisiin kirjastoihin, security.txt:hen ja DMARCiin, ja antaa korjausohjeet jokaiseen havaintoon. Kuten mikä tahansa passiivinen tarkastelu, se ei voi taata, että kauppa on turvallinen.

Usein kysytyt kysymykset

Vaarantavatko passiiviset tietoturvatarkistukset kauppani?

Eivät enempää kuin tavallinen käynti. Ne pyytävät samoja julkisia sivuja ja DNS-tietueita kuin mikä tahansa selain tai postipalvelin, eivätkä ne yritä kirjautua sisään tai lähettää hyökkäyskuormia.

Voinko lisätä tietoturvaotsakkeita Shopifyssa?

Kaupan vastausotsakkeet tulevat Shopifyn palvelimilta, joten ota yhteyttä Shopifyn tukeen, jos tarvitsemasi otsake puuttuu. Teemaan lisätty CSP:n <meta>-tagi voi lisätä joitakin direktiivejä, mutta MDN huomauttaa, ettei frame-ancestors-direktiiviä tueta <meta>-tagissa.

Tarkoittaako vanha jQuery-versio, että kauppaani on murtauduttu?

Ei. Se tarkoittaa, että ladattuna on koodia, jossa on tunnettuja haavoittuvuuksia, mikä kasvattaa riskiä, jos sivusto välittää epäluotettavaa HTML:ää haavoittuville metodeille. Päivitä se tai poista teema tai lisäosa, joka lataa sen.

Kuinka kauan TLS-varmenne voi nyt olla voimassa?

Julkisesti luotetut varmenteet, jotka on myönnetty 15.3.2026 tai sen jälkeen, voivat olla voimassa enintään 200 päivää. Raja laskee 100 päivään 15.3.2027 alkaen ja 47 päivään 15.3.2029 alkaen.

Onko security.txt-tiedosto pakollinen?

RFC 9116 on Informational-tyyppinen RFC, joten tiedoston julkaiseminen on standardin mukaan vapaaehtoista. Sen julkaiseminen on edullista, ja se antaa tutkijoille selkeän tavan ottaa sinuun yhteyttä.

Tarkoittaako puhdas passiivinen skannaus, että kauppani on turvallinen?

Ei. Se osoittaa, että julkinen kokoonpano näyttää oikealta. Palvelinpuolen haavoittuvuudet, tilien tietoturva ja liiketoimintalogiikan virheet vaativat muunlaista testausta.

Lähteet

Kaikki oppaat