WordPressin nonce on kevyt turvallisuusmekanismi, jonka päätarkoitus on estää CSRF-hyökkäyksiä (Cross-Site Request Forgery). Se on yksi WordPressin väärinymmärretyimmistä osista, koska nimi viittaa kertakäyttöiseen kryptografiseen nonceen, mutta toteutus on käytännössä aikaperusteinen ja käyttäjäsidonnainen token.
Nonce ei ole satunnainen kertakäyttöavain vaan:...
Tämä on tärkein väärinkäsityksen korjaus:...
Nonce luodaan action-kohtaisesti:...
Perinteinen lomake:...
AJAX-kutsuissa nonce tarkistetaan näin:...
REST API:ssa nonce integroidaan suoraan WordPressin auth layeriin....
Nonce ei ole pysyvä:...
CSRF-hyökkäys toimii näin:...
Noncea ei pidä käyttää:...
Oikea turvallisuusmalli:...
Esimerkiksi delete-linkit:...
WordPress admin käyttää noncea laajasti:...
WordPress REST API tarkistaa noncea sisäisesti:...
Nonce on erittäin kevyt:...
Nonce ja caching pitää erottaa:...
Single Page App -ympäristöissä:...
WordPress nonce on kevyt ja tehokas CSRF-suojamekanismi, joka toimii parhaiten käyttöliittymälähtöisissä toiminnoissa kuten lomakkeissa, AJAX-kutsuissa ja REST API -requesteissa. Sen oikea käyttö perustuu siihen, että...
WordPress nonce on kevyt ja tehokas CSRF-suojamekanismi, joka toimii parhaiten käyttöliittymälähtöisissä toiminnoissa kuten lomakkeissa, AJAX-kutsuissa ja REST API -requesteissa. Sen oikea käyttö perustuu siihen, että...
WordPress nonce on kevyt ja tehokas CSRF-suojamekanismi, joka toimii parhaiten käyttöliittymälähtöisissä toiminnoissa kuten lomakkeissa, AJAX-kutsuissa ja REST API -requesteissa. Sen oikea käyttö perustuu siihen, että...
Kun noncea käyttää oikein, se suojaa lomakkeet, AJAX-kutsut ja REST API -pyynnöt ilman raskasta autentikointia. Kun sitä käytetään väärin, se voi antaa väärän turvallisuuden tunteen tai sotkea arkkitehtuuria.
Mikä WordPress nonce oikeasti on
Nonce ei ole satunnainen kertakäyttöavain vaan:
- käyttäjään sidottu
- action-kohtainen
- aikarajoitettu (tyypillisesti 24h ikkuna)
Karkeasti:
nonce = hash(user_session + action + time_window)
Tämä tekee siitä sopivan CSRF-suojaksi, mutta ei autentikointiin.
Nonce ei ole autentikointi
Tämä on tärkein väärinkäsityksen korjaus:
Nonce ei kerro kuka käyttäjä on. Se kertoo vain, että request on tullut odotetusta käyttöliittymästä ja oikeasta sessiosta.
Siksi oikea järjestys on aina:
- capability check (kuka saa tehdä)
- nonce check (tuleeko pyyntö oikeasta kontekstista)
Noncen generointi
Nonce luodaan action-kohtaisesti:
$nonce = wp_create_nonce('save_post');
Action-nimi on tärkeä, koska se sitoo tokenin tiettyyn käyttötapaukseen.
Nonce lomakkeissa
Perinteinen lomake:
<input type="hidden" name="_wpnonce" value="<?php echo wp_create_nonce('save_data'); ?>">
WordPress tarjoaa myös helperin:
wp_nonce_field('save_data');
AJAX ja nonce
AJAX-kutsuissa nonce tarkistetaan näin:
check_ajax_referer('my_action');
Frontendissä nonce lähetetään yleensä headerissa:
headers: {
'X-WP-Nonce': wpApiSettings.nonce
}
REST API ja nonce
REST API:ssa nonce integroidaan suoraan WordPressin auth layeriin.
Frontend:
fetch('/wp-json/my/v1/data', {
method: 'POST',
headers: {
'X-WP-Nonce': nonce
}
});
Backend permission callback:
'permission_callback' => function () {
return is_user_logged_in();
}
WordPress tarkistaa automaattisesti nonce-validiteetin REST stackissa.
Noncen elinkaari
Nonce ei ole pysyvä:
0–12h valid
12–24h fallback-valid
>24h invalid
Tämä tekee siitä “aikakytketyn CSRF-tokenin”.
Nonce ja CSRF-suoja
CSRF-hyökkäys toimii näin:
- käyttäjä on kirjautunut WordPressiin
- hyökkääjän sivu tekee requestin taustalla
- selain lähettää session automaattisesti
Nonce estää tämän, koska hyökkääjä ei voi arvata validia tokenia.
Yleinen väärinkäyttö
Noncea ei pidä käyttää:
- API-autentikointina
- access tokenina
- ainoana tietoturvakerroksena
Se on lisäsuoja, ei identiteettijärjestelmä.
Permission + nonce yhdessä
Oikea turvallisuusmalli:
1. current_user_can()
2. nonce check
3. input validation
4. business logic
Nonce ei koskaan korvaa capability checkiä.
URL-pohjainen nonce
Esimerkiksi delete-linkit:
wp_nonce_url($url, 'delete_post');
Tuottaa:
?_wpnonce=abc123
Admin-ympäristön käyttö
WordPress admin käyttää noncea laajasti:
wp_nonce_field('update_options', 'option_nonce');
Ja validointi:
check_admin_referer('update_options', 'option_nonce');
REST API nonce syvemmällä tasolla
WordPress REST API tarkistaa noncea sisäisesti:
X-WP-Nonce
↓
wp_verify_nonce
↓
rest_cookie_check_errors
Jos epäonnistuu → 403 Forbidden.
Suorituskyky
Nonce on erittäin kevyt:
- ei tietokantakyselyjä
- pelkkä hash-vertailu
- O(1)-operaatio
Eli se ei ole suorituskyvyn pullonkaula.
Caching ja nonce
Nonce ja caching pitää erottaa:
- nonce on user/session-spesifi
- cache on yleensä shared
Siksi noncea ei saa upottaa shared cache -HTML:ään ilman variaatiota.
SPA- ja headless-ongelmat
Single Page App -ympäristöissä:
- nonce voi vanhentua kesken session
- API-kutsut alkavat failata
Ratkaisuja:
- nonce refresh endpoint
- JWT autentikointi
- hybrid-malli
Hyvät käytännöt
- käytä action-kohtaista noncea
- älä käytä sitä yksin turvallisuuteen
- yhdistä capability checkiin
- käytä REST API:ssa X-WP-Nonce headeria
- vältä noncea pitkäikäisissä API-sessioissa
- pidä se UI-tason suojana
Yleisimmät virheet
- nonce = authentication
- sama nonce kaikille toiminnoille
- puuttuva capability check
- vanhentuneet noncet SPA:ssa
- väärä action-nimi validoinnissa
Yhteenveto
WordPress nonce on kevyt ja tehokas CSRF-suojamekanismi, joka toimii parhaiten käyttöliittymälähtöisissä toiminnoissa kuten lomakkeissa, AJAX-kutsuissa ja REST API -requesteissa. Sen oikea käyttö perustuu siihen, että se nähdään lisäsuojakerroksena, ei autentikointiratkaisuna.
Kun nonce yhdistetään capability-checkeihin ja selkeään request-arkkitehtuuriin, se tarjoaa erittäin tehokkaan ja kevyen tavan suojata WordPressin käyttöliittymätoimintoja ilman suorituskykyhaittoja.