@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

Saat tuoreimmat 10 uusinta artikkelia kerran viikossa sähköpostiisi.

Tilaa uutiskirje

REST API rate limiting WordPressissä – toteutus ja suojausWordPress REST API mahdollistaa tehokkaat integraatiot, headless-ratkaisut ja AJAX-pohjaiset sovellukset, mutta ilman rajoituksia siitä voi tulla myös merkittävä suorituskyky- ja tietoturvariski. Rate limiting tarkoittaa käytännössä sitä, että yksittäisen käyttäjän, IP-osoitteen tai API-avaimen pyyntömäärää rajoitetaan tietyn ajan sisällä.

Tiivistelmä
Rate limiting -strategiat

Yleisin malli:...

Rate limiting WordPressissä käytännössä

Paras paikka rate limitingille: → ennen PHP:tä...

Turvallisuusnäkökulma

Kun limit ylittyy:...

Paras käytännön arkkitehtuuri

Tuotantoympäristössä tehokkain malli on:...

Yhteenveto

REST API rate limiting WordPressissä ei ole vain turvallisuusominaisuus, vaan myös suorituskyvyn suojauskerros....

 

Ilman rate limitingiä:

  • botti voi floodata API:a tuhansilla requesteilla
  • brute force -hyökkäykset helpottuvat
  • REST endpointit voivat ylikuormittaa PHP:n ja tietokannan
  • WooCommerce API voi kaataa palvelimen liikennepiikissä

Hyvin toteutettu rate limiting suojaa sekä suorituskykyä että infrastruktuuria.

Miksi REST API tarvitsee rate limitingin

REST API on usein raskas:

WordPress REST request:

  • lataa WordPressin ytimen
  • suorittaa hookit ja filterit
  • tekee capability checkit
  • käynnistää WP_Queryn
  • serialisoi vastauksen JSONiksi

Kun tätä tapahtuu satoja kertoja sekunnissa:
→ CPU ja MySQL kuormittuvat nopeasti.

Yleisimmät hyökkäystyypit

Brute force login API:n kautta:

Esimerkki:

  • /wp-json/jwt-auth/...
  • /wp-json/wp/v2/users

Hyökkääjä voi:

  • yrittää tuhansia kirjautumisia minuutissa

REST scraping:

Botit:

  • indeksoivat koko sivuston API:n kautta
  • tekevät massiivisia GET-pyyntöjä

WooCommerce API abuse:

Raskaat endpointit:

  • products
  • orders
  • search endpointit

Voivat:

  • tehdä raskaita meta_queryjä
  • kasvattaa SQL-kuormaa rajusti

Rate limiting -strategiat

IP-pohjainen rajoitus:

Yleisin malli:

  • X requestia / minuutti / IP

Esimerkki:

  • 100 requestia / 60 sekuntia

Hyödyt:

  • yksinkertainen
  • tehokas bottihyökkäyksiä vastaan

Heikkous:

  • shared IP:t voivat osua limittiin

API key / käyttäjäkohtainen limiting:

Parempi authenticated API:ssa:

  • jokaisella käyttäjällä oma quota

Esimerkki:

  • free tier = 60 req/min
  • premium = 600 req/min

Endpoint-kohtainen limiting:

Kaikkia endpointteja ei tarvitse rajoittaa samalla tavalla.

Esimerkki:

  • /posts → kevyt
  • /orders → raskas

Voidaan:

  • antaa eri limitit eri endpointille

Sliding window vs fixed window:

Fixed window:

  • esim. 100 req/min

Ongelma:

  • burst requestit mahdollisia ikkunan rajalla

Sliding window:

  • tarkempi ja tasaisempi
  • tuotantoympäristöissä parempi

Rate limiting WordPressissä käytännössä

Nginx rate limiting (suositeltu):

Paras paikka rate limitingille:
→ ennen PHP:tä

Esimerkki:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

REST API:

location /wp-json/ {
    limit_req zone=api_limit burst=20 nodelay;
}

Hyödyt:

  • estää kuorman ennen PHP:tä
  • erittäin kevyt
  • suojaa koko palvelinta

Cloudflare / CDN limiting:

Cloudflare voi:

  • blokata bottiverkkoja
  • tehdä rate limitingin edge-tasolla

Hyödyt:

  • liikenne pysähtyy ennen originia
  • vähentää bandwidth-kuormaa

WordPress plugin -toteutus:

Plugin voi:

  • tallentaa request countin transienttiin tai Redis-cacheen

Esimerkki logiikasta:

  • IP → request count
  • ylitys → 429 Too Many Requests

Mutta:
→ PHP-tason limiting ei ole yhtä tehokas kuin Nginx/CDN

Redis-pohjainen distributed limiting:

Suuremmissa ympäristöissä:

  • useita webnodeja
  • load balancer

Redis:

  • toimii keskitettynä counter-varastona

Hyöty:

  • kaikki serverit jakavat saman limitin

Suorituskykyvaikutukset

Ilman limitingiä:

  • REST flood → PHP-FPM exhaustion
  • MySQL connection spike
  • CPU saturation

Hyvällä limitingillä:

  • bottiliikenne pysähtyy nopeasti
  • backend pysyy vakaana
  • cache layer toimii tehokkaammin

Rate limiting ja WooCommerce

WooCommerce API:

  • erittäin raskas meta_queryjen takia
  • voi triggeröidä inventory syncin

Suositukset:

  • tiukempi limiting order endpointteihin
  • pidempi cooldown authenticated API:lle
  • Redis object cache pakollinen

Turvallisuusnäkökulma

429 response:

Kun limit ylittyy:

  • palauta HTTP 429

Tärkeää:

  • älä käytä 403 tai 500 virheitä tähän

Whitelistit:

Esim:

  • maksupalvelut
  • integraatiot
  • trusted webhookit

Näitä ei yleensä pidä limitoida samalla tavalla.

Bot tunnistus:

Yhdistä:

  • User-Agent analyysi
  • IP reputation
  • WAF (Web Application Firewall)

Yleisimmät virheet

Liian aggressiivinen limiting:

Ongelma:

  • oikeat käyttäjät blokataan

Esimerkki:

  • mobiiliverkkojen shared IP:t

Limiting vain PHP-tasolla:

Tämä:

  • ei suojaa palvelinta oikeasti
  • PHP ehtii kuormittua ennen blokkia

Ei endpoint-kohtaisia sääntöjä:

Kaikki endpointit eivät ole yhtä raskaita.

Paras käytännön arkkitehtuuri

Tuotantoympäristössä tehokkain malli on:

  • Cloudflare / CDN limiting
  • Nginx limit_req
  • Redis object cache
  • kevyt PHP fallback limiting
  • endpoint-kohtaiset säännöt

Yhteenveto

REST API rate limiting WordPressissä ei ole vain turvallisuusominaisuus, vaan myös suorituskyvyn suojauskerros.

Hyvin toteutettu limiting:

  • estää bottifloodit
  • suojaa PHP-FPM:ää
  • vähentää MySQL-kuormaa
  • stabiloi vasteajat liikennepiikeissä

Parhaat ratkaisut tapahtuvat ennen WordPressiä:

WordPress-tason limiting toimii lähinnä lisäsuojana, ei ensisijaisena puolustuskerroksena.

🍪