WordPress ja Secure Headers (CSP, HSTS, X-Frame-Options)

WordPressin tietoturvasta puhuttaessa huomio kiinnittyy usein päivityksiin, lisäosiin ja käyttäjähallintaan. Yksi alihyödynnetyimmistä, mutta tehokkaimmista suojakerroksista löytyy kuitenkin HTTP-tasolta: Secure Headers. Ne eivät muuta WordPressin koodia riviäkään, mutta vaikuttavat suoraan siihen, miten selain saa käyttää sivustoa.

Secure headerit ovat kuin selaimelle annettu käyttöohje: mitä saa tehdä, mitä ei, ja millä ehdoilla.

Miksi HTTP-headerit ovat kriittisiä WordPressissä

WordPress on:

• laajennettava

• plugin-vetoinen

• usein monen tekijän muokkaama

Tämä tarkoittaa:

• enemmän hyökkäyspintaa

• enemmän kolmannen osapuolen JavaScriptiä

• enemmän riskejä XSS-, clickjacking- ja MITM-hyökkäyksille

Secure headerit toimivat viimeisenä puolustuslinjana, vaikka jokin muu kerros pettäisi.

Content Security Policy (CSP)

Mitä CSP tekee

CSP määrittelee:

• mistä lähteistä skriptit saavat latautua

• saako inline-JavaScriptiä ajaa

• saako iframeja upottaa

• minne dataa saa lähettää

Käytännössä CSP:

• rajoittaa XSS-hyökkäyksiä

• estää haitallisten skriptien ajon

• pakottaa kehittäjän eksplisiittisiin valintoihin

CSP ja WordPressin todellisuus

WordPress ei ole CSP-ystävällinen oletuksena:

• inline-scriptit ovat yleisiä

• eval-tyyppisiä rakenteita esiintyy

• lisäosat lataavat resursseja eri domaineista

Täysin tiukka CSP (script-src 'self') rikkoo usein adminin ja editorin.

Käytännöllinen lähestymistapa

Tuotannossa CSP kannattaa:

• ottaa käyttöön ensin Content-Security-Policy-Report-Only -tilassa

• kerätä rikkomukset

• kiristää asteittain

• erottaa frontend ja wp-admin toisistaan

CSP ei ole “päälle ja valmis” -asetus, vaan jatkuva prosessi.

HTTP Strict Transport Security (HSTS)

Mitä HSTS tekee

HSTS kertoo selaimelle:

• käytä aina HTTPS-yhteyttä

• älä edes yritä HTTP:tä

• muista tämä tietyn ajan

Tämä estää:

• SSL strip -hyökkäykset

• vahingolliset uudelleenohjaukset

• käyttäjän virheet osoiterivillä

HSTS WordPressissä

HSTS on tehokas mutta armoton:

• virheellinen konfiguraatio voi lukita sivuston

• väärä sertifikaatti = sivusto nurin

WordPressissä HSTS:

• vaatii täysin toimivan HTTPS:n

• koskee myös wp-adminia ja REST API:a

• vaikuttaa kaikkiin alidomaineihin, jos includeSubDomains on käytössä

Preload-lista

HSTS preload:

• lisää domainin selainten sisäiseen listaan

• tekee HTTPS:stä pakollisen pitkäksi aikaa

• ei ole helposti peruttavissa

Tätä ei pidä tehdä kevyin perustein WordPress-sivustolla.

X-Frame-Options

Clickjackingin esto

X-Frame-Options määrittelee:

• saako sivun upottaa iframeen

• kenelle se on sallittua

Yleisimmät arvot:

• DENY

• SAMEORIGIN

WordPressissä tämä suojaa:

• wp-adminia

• kirjautumissivua

• lomakkeita

Haasteet WordPressissä

Jos sivusto:

• käyttää iframe-upotuksia

• on osa toista järjestelmää

• toimii SSO-portaalina

DENY voi rikkoa toiminnallisuuden. Tällöin CSP:n frame-ancestors on joustavampi ratkaisu.

Muut olennaiset secure headerit

Vaikka CSP, HSTS ja X-Frame-Options ovat tunnetuimmat, kokonaisuus on tärkeä:

• X-Content-Type-Options: nosniff
  Estää MIME-tyypin arvailun

• Referrer-Policy
  Kontrolloi, mitä tietoa välitetään eteenpäin

• Permissions-Policy
  Rajaa selaimen API-oikeuksia (kamera, mikrofoni, geolokaatio)

Yhdessä nämä muodostavat selaintason palomuurin.

Missä headerit kannattaa asettaa

Paras paikka:

• web server (Nginx / Apache)

• CDN tai reverse proxy

• edge layer (Cloudflare, Fastly)

WordPress-tasolla:

• headerit voi lisätä PHP:llä

• mutta tämä on myöhäinen vaihe

• ei koske kaikkia vastauksia

Secure headerit kuuluvat infrastruktuuriin, ei teemaan.

Secure headerit ja suorituskyky

Hyvä uutinen:

• headerit eivät hidasta sivua

• eivät lisää HTTP-pyyntöjä

• eivät kuormita PHP:tä

Huono uutinen:

• väärin asetettu CSP voi rikkoa JS:n

• virheellinen HSTS voi estää pääsyn kokonaan

Testaus on pakollista.

WordPress multisite ja headerit

Multisite-ympäristössä:

• yksi virhe vaikuttaa koko verkkoon

• eri sivustot voivat tarvita eri CSP:t

• domain mapping monimutkaistaa HSTS:ää

Yhtenäinen strategia on tärkeämpi kuin täydellinen tiukkuus.

Yleisimmät virheet

Tyypillisiä kompastuskiviä:

• CSP kopioidaan suoraan toisesta projektista

• HSTS otetaan käyttöön ennen HTTPS-auditointia

• headerit asetetaan vain frontendiin

• wp-admin unohdetaan

• raportointia ei hyödynnetä

Secure headerit eivät ole copy–paste-turvaa.

Lopuksi: halpa, tehokas ja usein unohtunut suoja

Secure headerit ovat:

• ilmaisia

• standardoituja

• tehokkaita

Ne eivät korvaa:

• päivityksiä

• turvallista koodia

• käyttäjähallintaa

Mutta ne rajaavat vahingot, kun jokin muu menee pieleen. WordPress-ympäristössä se on usein ratkaisevaa.