🔒 HTTP-tietoturvaotsakkeet WordPressille: täydellinen asennusopas

WordPress-sivustosi on käynnissä, tietoturvalisäosa on asennettu, mutta securityheaders.com-sivuston tarkistus antaa arvosanaksi F. Kuulostaako tutulta?

HTTP-tietoturvaotsakkeet ovat näkymätön suojakerros, joka unohtuu helposti, vaikka olisit asentanut palomuurin ja kaksivaiheisen tunnistautumisen. Ne eivät tarvitse lisenssien uusimista, eivät kuormita palvelinta ja estävät kokonaisia hyökkäysluokkia klikkauskaappauksesta istuntokaappaukseen. Ja niiden lisäämiseen menee 10 minuuttia.

Alla vaihe vaiheelta: mitä otsakkeita oikeasti tarvitset, miten ne määritetään.htaccessin, functions.php:n tai lisäosan kautta ja miten varmistat, että suojaus on toiminnassa, ei vain listattuna.

💡 Pikaopas:

• Tarkista sivustosi nykyiset otsakkeet securityheaders.com- tai Mozilla Observatory -palvelun kautta nähdäksesi todellisen tilanteen
• Ota käyttöön 4-5 otsakkeen perussarja: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Valitse tapasi: pari riviä.htaccess-tiedostossa (Apache/LiteSpeed), koodinpätkä functions.php:ssä tai Headers Security Advanced & HSTS WP -lisäosa
• Jätä CSP myöhemmäksi: sen määrittäminen on hankalaa ja se rikkoo Gutenbergin, jos teet sen testaamatta
• Tarkista toteutuksen jälkeen uudelleen: A+-arvosana on saavutettavissa 10 minuutissa

Mitä HTTP-tietoturvaotsakkeet ovat

Kun selain pyytää sivua, verkkopalvelin lähettää takaisin muutakin kuin vain HTML-koodia. Jokainen HTTP-vastaus sisältää palvelukenttiä, otsakkeita. Jotkut käsittelevät välimuistia ja sisältötyyppiä, ja jotkut käsittelevät tietoturvaa.

Selain lukee tietoturvaotsakkeet jo ennen kuin se alkaa edes renderöidä sivua. Jos palvelin sanoo "kiellän tämän sivuston upottamisen kehyksiin", selain ei tee sitä, vaikka sivun koodi sisältäisi <iframe>-elementin. Jos palvelin sanoo "käytä vain HTTPS:ää vuoden ajan", selain muistaa tämän eikä mene HTTP-versioon, vaikka käyttäjä kirjoittaisi sen manuaalisesti.

Mikään JavaScript, lisäosa tai palomuuri ei vaikuta tähän. Tämä on protokollataso. Juuri siksi otsakkeet ovat erillinen, itsenäinen puolustuslinja.

Miksi WordPress-sivusto tarvitsee tätä

Tietoturvalisäosat, kuten Wordfence tai Solid Security, sulkevat haavoittuvuuksia sovellustasolla: brute force -hyökkäykset, injektiot, haitalliset tiedostojen lataukset. HTTP-otsakkeet toimivat yhtä tasoa ylempänä: ne suojaavat itse palvelimen ja kävijän välistä viestintäkanavaa.

Tässä on, mitä oikein määritetyt otsakkeet estävät:

• Klikkauskaappaus. Hyökkääjä upottaa sivustosi läpinäkyvään kehykseen omansa päälle ja kaappaa käyttäjän klikkaukset. Estetään X-Frame-Options-otsakkeella tai frame-ancestors-direktiivillä CSP:ssä.

• MIME-tyypin arvaus. Selain yrittää "arvata" tiedostotyypin ja saattaa suorittaa ladatun kuvan JavaScriptinä. Estetään otsakkeella X-Content-Type-Options: nosniff.

• Istuntokaappaus. Hyökkääjä avoimessa Wi-Fi-verkossa muuttaa palvelimen vastausta ja varastaa kirjautumisevästeet. HSTS kieltää selainta käyttämästä sivuston HTTP-versiota.

• Viittaajan tietovuoto. Ulkoista linkkiä seurattaessa kohdesivusto näkee, miltä sivulta käyttäjä tuli, mukaan lukien URL-osoitteen parametreineen. Referrer-Policy rajoittaa tätä.

• Luvaton laitteiston käyttö. Verkkosivu pyytää mikrofonia, kameraa tai sijaintia käyttäjän tietämättä. Permissions-Policy estää tällaiset pyynnöt selaintasolla.

CSP lisää toisen kerroksen: määrittelet tarkasti, mitkä verkkotunnukset voivat ladata skriptejä, tyylejä ja fontteja. Vaikka haitallista koodia päätyisi tietokantaan, selain ei suorita sitä, koska lähde ei ole sallittujen listalla. Mutta CSP vaatii huolellisuutta: yksi pieni virhe, ja Gutenberg-editori lakkaa toimimasta.

Keskeiset HTTP-tietoturvaotsakkeet: mitä ne sisältävät ja miksi

Alla ovat otsakkeet, jotka kannattaa määrittää mille tahansa WordPress-sivustolle. Jokaisen kohdalla kerromme: miltä hyökkäykseltä se suojaa, suositellun arvon ja missä asiat voivat hajota.

X-Content-Type-Options

Yksinkertaisin ja turvallisin määrittää. Ainoa kelvollinen arvo on nosniff. Selain lopettaa tiedoston MIME-tyypin "arvaamisen" sen sisällön perusteella ja luottaa vain tyyppiin, jonka palvelin lähetti Content-Type-otsakkeessa.

Ilman tätä otsaketta selain saattaa käsitellä käyttäjän lataaman kuvan skriptinä ja suorittaa sen, mikä on klassinen tiedostolataushyökkäysskenaario.

Suositeltu arvo: nosniff

Rikkoutumisriskit: minimaaliset. Ongelmat ovat mahdollisia vain, jos palvelin tarjoilee tiedostoja väärällä Content-Typellä, mutta se on erillinen ongelma, joka kannattaa korjata eikä peittää.

X-Frame-Options

Hallitsee, voidaanko sivustosi upottaa <frame>, <iframe> tai <object> -elementtiin toisella sivustolla.

Kaksi pääarvoa:

• DENY, täydellinen upotuskielto. Maksimaalinen suoja.
• SAMEORIGIN, upotus sallittu vain samasta domainista. Tarpeen, jos käytät itse kehyksiä omille sivuillesi (esimerkiksi esikatselu hallintapaneelissa).

Useimmille WordPress-sivustoille SAMEORIGIN toimii. Jos tiedät varmasti, ettei kehyksiä käytetä, aseta DENY.

Suositeltu arvo: SAMEORIGIN

Rikkoutumisriskit: jotkin lisäosat käyttävät iframeja esikatseluihin. Jos jokin lakkaa näkymästä hallintapaneelissa DENYn käyttöönoton jälkeen, vaihda arvoon SAMEORIGIN.

Strict-Transport-Security (HSTS)

Kertoo selaimelle: "seuraavan N sekunnin ajan käytä tähän domainiin vain HTTPS-yhteyttä." Suojaa alennushyökkäyksiltä ja evästeiden kaappaukselta avoimissa verkoissa.

Keskeinen parametri on max-age. On suositeltavaa aloittaa pienellä arvolla (päivä tai viikko) ja varmennuksen jälkeen kasvattaa se vuoteen.

Valinnainen includeSubDomains-parametri laajentaa säännön kaikkiin alidomaineihin, mikä on tärkeää, jos sinulla on niitä useita ja käytät CDN:ää.

preload-parametri lisää sivuston selainten globaaliin HSTS-listaan: Chrome, Firefox ja Safari käyttävät domainiisi vain HTTPS-yhteyttä jo ennen ensimmäistä pyyntöä. Lähetä hakemus osoitteessa hstspreload.org.

Suositeltu arvo: max-age=31536000; includeSubDomains

Rikkoutumisriskit: jos otat HSTS:n käyttöön ja SSL-varmenne vanhenee, käyttäjät eivät pääse sivustolle lainkaan. Pidä silmällä varmenteen automaattista uusintaa.

Referrer-Policy

Hallinnoi, mitä tietoa lähdesivusta selain lähettää seuratessaan linkkiä toiselle sivustolle.

Pääarvot, tiukimmasta sallivimpaan:

• no-referrer, mitään ei lähetetä lainkaan.
• strict-origin-when-cross-origin, eri domainiin lähetetään vain domain (ei polkua tai parametreja); omaan domainiin lähetetään koko URL. Optimaalinen tasapaino yksityisyyden ja analytiikan välillä.
• strict-origin, aina vain domain, ei polkua.

Jos et halua kohdesivustojen tietävän, mistä käyttäjä tuli, aseta no-referrer. Mutta muista: menetät viittausliikenteen omassa analytiikassasi.

Suositeltu arvo: strict-origin-when-cross-origin

Rikkoutumisriskit: minimaaliset. Jotkin kolmannen osapuolen palvelut saattavat vaatia viittaajan toimiakseen (esimerkiksi maksuyhdyskäytävät, joissa on lähdeverifiointi). Voit seurata tällaisia tapauksia selaimen konsolin kautta.

Permissions-Policy

Aiemmin nimeltään Feature-Policy. Rajoittaa verkkosivun pääsyä "laitteisto"-selainrajapintoihin: mikrofoni, kamera, geopaikannus, USB, maksurajapinnat ja niin edelleen.

Muoto: название-фичи=(разрешённый-источник). Esimerkiksi:

1
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Tämä esimerkki estää kokonaan pääsyn kameraan ja mikrofoniin kaikista lähteistä ja sallii geopaikannuksen vain sivustolle itselleen (self).

Täydellinen lista ominaisuuksista osoitteessa MDN. WordPress-sivustolle, jossa ei ole videokeskusteluja ja PWA-ominaisuuksia, riittää kameran, mikrofonin ja geopaikannuksen estäminen; loput ovat valinnaisia.

Suositeltu arvo: riippuu sivuston toiminnallisuudesta. Vähimmäisvaatimus: camera=(), microphone=(), geolocation=(self).

Rikkoutumisriskit: jos sivustolla on videopuhelu-, PWA- tai WebUSB-toiminnallisuus, tarkista mitä ominaisuuksia se tarvitsee äläkä estä niitä.

Content-Security-Policy (CSP)

Tehokkain ja vaarallisin määritettävä otsake. Määrittelee sallittujen lähteiden listan skripteille, tyyleille, fonteille, kuville, kehyksille ja muille resursseille.

Esimerkki WordPressin minimikäytännöstä:

1
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
2

*Miksi unsafe-inline ja unsafe-eval:* WordPress, Gutenberg ja kymmenet lisäosat tuottavat inline-skriptejä ja käyttävät eval()-funktiota. Ilman näitä direktiivejä hallintapaneeli ei yksinkertaisesti toimi. Tämä on yhteensopivuuden hinta.

Suositus: älä ota CSP:tä käyttöön ensimmäisenä. Määritä ensin muut 5 otsaketta. Ota CSP käyttöön vain, jos sinulla on resursseja testaukseen ja seurantaan; aloita Content-Security-Policy-Report-Only-tilassa ja kerää rikkomuslokeja pari viikkoa ennen pakottavaan tilaan siirtymistä.

Rikkoutumisriskit: korkeat. Virhe CSP:ssä voi rikkoa täysin julkisivun ja hallintapaneelin. Testaa aina staging-ympäristössä tai Report-Onlyn kautta.

Kuinka tarkistaa sivustosi nykyiset otsakkeet

Ennen määritystä, auditointi. Kolme työkalua, yksinkertaisesta yksityiskohtaiseen:

• securityheaders.com, syötä URL ja saat arvosanan A+:sta F:ään ja erittelyn jokaisesta otsakkeesta. Ilmainen, ei rekisteröitymistä.

• Mozilla Observatory, yksityiskohtaisempi auditointi: arvioi otsakkeiden lisäksi myös TLS-asetukset, evästeattribuutit, CORS:n ja muita näkökohtia. Myös ilmainen.

• Chrome DevTools, avaa Network-välilehti, valitse mikä tahansa sivustollesi kohdistuva pyyntö ja katso Response Headers -osio. Nopea tapa tarkistaa, menivätkö muutokset "läpi".htaccessin muokkauksen jälkeen.

Tarkista sivustosi heti. Jos arvosana on alle B, sinulla ei ole edes perusotsakkeita, ja kolmasosan alla olevista kohdista määrität viidessä minuutissa.

Tapoja määrittää HTTP-otsakkeet WordPressissä

Kolme polkua, manuaalisesta automaattiseen. Valitse tilanteesi mukaan.

Tapa 1:.htaccessin kautta (Apache/LiteSpeed)

Nopein tapa Apachea tai LiteSpeediä käyttäville sivustoille. Lisää .htaccess-tiedostoon sivuston juuressa (ennen # BEGIN WordPress -riviä):

1
<IfModule mod_headers.c>
2
    Header set X-Content-Type-Options "nosniff"
3
    Header set X-Frame-Options "SAMEORIGIN"
4
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
5
    Header set Referrer-Policy "strict-origin-when-cross-origin"
6
    Header set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
7
</IfModule>

<IfModule mod_headers.c> -kääre varmistaa, ettei sivusto kaadu 500-virheeseen, jos mod_headers-moduuli ei ole käytössä. Jos tiedät varmasti, että se on aktiivinen, voit jättää sen pois.

Tallennuksen jälkeen aja terminaalissa (jos sinulla on WP-CLI) tai avaa vain sivusto ja tarkista otsakkeet securityheaders.comin kautta. .htaccess-muutokset tulevat voimaan heti; palvelimen uudelleenkäynnistystä ei tarvita.

Tapa 2: functions.php:n kautta (Nginx / yleispätevä)

Toimii verkkopalvelimesta riippumatta, sopii sekä Nginxille että Apachelle. Lisää lapsiteemasi functions.php-tiedostoon tai Code Snippets -lisäosan kautta:

1
function sdstudio_add_security_headers() {
2
    header( 'X-Content-Type-Options: nosniff' );
3
    header( 'X-Frame-Options: SAMEORIGIN' );
4
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
5
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
6
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(self)' );
7
}
8
add_action( 'send_headers', 'sdstudio_add_security_headers' );

send_headers-koukku laukeaa ennen kuin WordPress alkaa lähettää sisältöä, joten otsakkeet lähtevät aivan ensimmäisessä palvelinvastauksessa.

Nginxille tämä tapa on parempi kuin palvelimen konfiguraatioon kaivautuminen (erityisesti jaetulla hostingilla, jossa pääsyä nginx.conf-tiedostoon ei usein ole). Huono puoli: otsakkeet toimivat vain PHP-pyynnöille, jotka kulkevat WordPressin kautta. Staattiset tiedostot (kuvat, CSS, JS) Nginx palvelee suoraan, eivätkä ne saa otsakkeita. Ne vaativat palvelintason määrityksen.

Tapa 3: Headers Security Advanced & HSTS WP -lisäosan kautta

Jos et halua koskea koodiin, käytä tarkoitukseen tehtyä lisäosaa. Headers Security Advanced & HSTS WP kokoaa kaikki tietoturvaotsakkeet yhteen käyttöliittymään ja ottaa ne käyttöön yhdellä napin painalluksella.

Lisäosa asettaa esiasetetut arvot kaikille keskeisille otsakkeille heti aktivoinnin jälkeen: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy ja useita lisäotsakkeita (CORP, COOP, COEP). Jokaisen otsakkeen voi poistaa käytöstä tai mukauttaa tarpeisiisi.

Tämän lähestymistavan etu: lisäosa ei ole riippuvainen verkkopalvelimesta ja toimii samalla tavalla Apachen, Nginxin, LiteSpeedin ja IIS:n kanssa. Deaktivoitaessa se palauttaa sivuston asetukset alkuperäiseen tilaansa.

Vaihtoehto: Redirection

Redirection -lisäosa tunnetaan uudelleenohjausten hallintatyökaluna, mutta sillä voi myös lisätä HTTP-otsakkeita. Asennuksen ja perusmäärityksen jälkeen siirry Site → Headers -osioon; käyttöliittymässä voit määrittää mitä tahansa "otsake: arvo" -pareja.

Tämä vaihtoehto toimii, jos sinulla on Redirection jo asennettuna linkkien hallintaan etkä halua lisätä toista lisäosaa. Mutta erillinen otsakelisäosa antaa enemmän hallintaa ja valmiita esiasetuksia.

Videolla visuaalinen esittely otsakkeiden määrittämisestä Headers Security Advanced -lisäosalla: asennuksesta tuloksen tarkistamiseen securityheaders.comissa.

⁉️🤔 Usein kysytyt kysymykset

Entä jos sivusto hajoaa otsakkeiden käyttöönoton jälkeen?

Tarkista ensin Content-Security-Policy-otsake: se aiheuttaa valtaosan ongelmista. Ota CSP pois käytöstä (tai vaihda se Report-Only-tilaan) ja tarkista sivusto uudelleen. 500-virhe.htaccessin muokkauksen jälkeen: tarkista syntaksista ylimääräinen välilyönti, sulkemattomat lainausmerkit tai puuttuva mod_headers-moduuli. FTP:n kautta nimeä.htaccess uudelleen, sivusto palaa henkiin ja voit rauhassa etsiä virheen.

9 tapauksessa 10:stä ongelma on nimenomaan CSP, ei muut otsakkeet. X-Content-Type-Options, X-Frame-Options, HSTS ja Referrer-Policy eivät fyysisesti voi rikkoa sivustoa; ne eivät vaikuta renderöintiin tai PHP-logiikkaan. Aloita aina niistä.

Onko lisäosa pakollinen vai voiko tämän tehdä koodilla?

Voi ja kannattaa tehdä koodilla, jos osaat muokata functions.php- tai.htaccess-tiedostoa. Otsakkeiden asettaminen suoraan palvelimen konfiguraation kautta toimii nopeammin kuin lisäosa, ilman PHP-kerrosta välissä. Mutta lisäosa on kätevämpi niille, jotka eivät halua koskea koodiin, ja se tarjoaa visuaalisen käyttöliittymän ja esiasetukset jokaiselle otsakkeelle.

Testisivustoillamme käytämme molempia tapoja: tuotannossa.htaccessia (vähemmän vikapisteitä); asiakassivustoilla, joilla hosting ei salli konfiguraation muokkaamista, lisäosaa. Tulos securityheaders.comissa on identtinen: A+ molemmissa tapauksissa.

Tarvitseeko CSP:n määrittää, jos sivusto on WordPressissä?

Useimmille sivustoille ei. CSP WordPressissä vaatii unsafe-inline- ja unsafe-eval-määritykset, jotta Gutenberg ja kymmenet lisäosat toimivat, mikä vähentää suojaavan vaikutuksen symboliseksi. Täysimittainen CSP on järkevä korkean kuormituksen projekteissa, joissa on oma tietoturva-asiantuntija analysoimassa jokaista rikkomusraporttia. Kaikille muille viisi perusotsaketta antavat leijonanosan käytännön suojasta.

Miten varmistan, että otsakkeet toimivat asennuksen jälkeen?

Avaa sivusto selaimessa, käynnistä DevTools (F12) → Network-välilehti → klikkaa ensimmäistä pyyntöä verkkotunnukseesi → Response Headers -osio. Jos näet lisätyt otsakkeet, kaikki toimii. Automaattiseen tarkistukseen käytä securityheaders.comia: se näyttää paitsi olemassaolon myös arvojen oikeellisuuden sekä loppuarvosanan A+:sta F:ään.

Entä jos hosting ei salli.htaccessin muokkaamista eikä functions.php-tiedostoon ole pääsyä?

Asenna Headers Security Advanced & HSTS WP WordPressin hallintapaneelin kautta. Lisäosa lisää otsakkeet PHP-tasolla eikä vaadi palvelintiedostojen muokkaamista. Tämä toimii millä tahansa hostingilla, jossa WordPress pyörii, halvasta jaetusta Managed Wordpressiin.

Vaikuttavatko HTTP-otsakkeet sivuston nopeuteen?

Eivät käytännössä. Otsakkeet ovat muutaman kymmenen tavun tekstiä palvelimen vastauksessa. Ne eivät suorita laskutoimituksia, tee tietokantakyselyitä eivätkä kuormita suoritinta. Niiden aiheuttama viive mitataan mikrosekunneissa. Ainoa poikkeus on CSP, jossa on monimutkainen satojen verkkotunnusten sallittujen lista: selain käyttää aikaa sen jäsentämiseen, mutta silloinkaan vaikutus renderöintinopeuteen ei ylitä paria millisekuntia.

Mitä asettaa ja mistä aloittaa

HTTP-tietoturvaotsakkeet eivät ole kertaluonteinen "aseta ja unohda" -toimenpide. Ne ovat perustaso, jonka pitäisi olla jokaisella sivustolla oletuksena, kuten SSL-sertifikaatin.

Suunnitelma tälle päivälle:

• Tarkista sivustosi securityheaders.comissa. Jos arvosana on D tai F, sinulla ei ole edes X-Content-Type-Options-otsaketta.

• Lisää 5 perusotsaketta millä tahansa kolmesta yllä olevasta tavasta. Jos sivusto on Apachen päällä,.htaccessin kautta (30 sekuntia). Nginx ilman konfiguraatiopääsyä, functions.php:n kautta (2 minuuttia). Jos et halua koskea koodiin, Headers Security Advanced -lisäosa (3 minuuttia asennuksineen).

• Tarkista sivusto uudelleen. Arvosanan pitäisi nousta A:han tai A+:aan.

• Jätä CSP toistaiseksi sivuun. Palaa siihen, kun perusotsakkeet ovat toimineet kuukauden ongelmitta ja sinulla on aikaa testaukseen Report-Only-tilan kautta.

Yksi tunti, ja WordPress-sivustosi saa suojakerroksen, joka valtaosalta internetin sivustoista puuttuu. Aloita tarkistuksella heti.