@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

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

Tilaa uutiskirje

Kuinka rakentaa turvallinen REST API integraatio WordPressiinWordPress REST API on tehokas tapa yhdistää ulkoisia järjestelmiä sivustoon, mutta samalla se avaa merkittävän hyökkäyspinnan, jos autentikointi, validointi ja rajoitukset eivät ole kunnossa.

Tiivistelmä
REST API:n perusajatus WordPressissä

Endpointit rekisteröidään näin:...

1. Autentikointi (kriittisin osa)

Ilman autentikointia API on avoin....

2. Permission check (älä koskaan luota vain autentikointiin)

function my_endpoint_permission() { return current_user_can('manage_options'); } Endpoint:...

3. Input validation ja sanitointi

Älä koskaan käytä raakaa inputtia....

4. REST Request -objektin käyttö

Käytä aina $request:...

5. Rate limiting (usein unohdettu)

Ilman rajoituksia API on brute force -kohde....

7. Error handling oikein

Älä palauta raakaa PHP-erroria....

8. Nonce ei riitä yksinään

Nonce suojaa lähinnä browser-pohjaisia requesteja....

9. HTTPS on pakollinen

Ilman HTTPS:...

10. CORS hallinta

Jos frontend erillisessä domainissa:...

12. Cache API-vastauksille

Suorituskyky ja turvallisuus:...

13. Audit logging

Tärkeä enterprise-tasoilla:...

14. Versionointi API:ssa

Älä muuta endpointteja rikki:...

17. Payload size rajoitus

Estä massiiviset requestit:...

18. Yleisimmät virheet

Turvallinen WordPress REST API sisältää:...

19. Paras arkkitehtuuri

Turvallinen WordPress REST API sisältää:...

Yhteenveto

Turvallinen REST API WordPressissä ei synny pelkästä endpointin luomisesta, vaan kerroksellisesta arkkitehtuurista, jossa autentikointi, valtuutus, validointi ja rajoitukset on suunniteltu alusta asti....

Turvallinen integraatio ei ole vain “endpointin tekemistä”, vaan kokonaisuus, jossa hallitaan:

  • autentikointi ja valtuutus
  • input validation ja sanitointi
  • rate limiting
  • data exposure
  • permission checks
  • error handling
  • auditointi

REST API:n perusajatus WordPressissä

Endpointit rekisteröidään näin:

add_action('rest_api_init', function () {

    register_rest_route('myplugin/v1', '/data', [
        'methods'  => 'GET',
        'callback' => 'my_endpoint',
    ]);
});

Tämä on lähtökohta, mutta ei vielä turvallinen.

1. Autentikointi (kriittisin osa)

Ilman autentikointia API on avoin.

Vaihtoehdot WordPressissä:

  • Application Passwords (suositeltu perusratkaisu)
  • OAuth (enterprise-taso)
  • JWT (headless-sovellukset)
  • Cookie-auth (vain sisäinen käyttö)

Application Password esimerkki

WordPress tukee natiivisti:

Authorization: Basic base64(username:application_password)

2. Permission check (älä koskaan luota vain autentikointiin)

function my_endpoint_permission() {

    return current_user_can('manage_options');
}

Endpoint:

register_rest_route('myplugin/v1', '/data', [
    'methods'  => 'POST',
    'callback' => 'my_endpoint',
    'permission_callback' => 'my_endpoint_permission'
]);

Ilman permission_callbackia endpoint on vaarallinen.

3. Input validation ja sanitointi

Älä koskaan käytä raakaa inputtia.

Huono:

$data = $_POST['email'];

Parempi:

$email = sanitize_email($request->get_param('email'));

Tai:

$name = sanitize_text_field($request->get_param('name'));

4. REST Request -objektin käyttö

Käytä aina $request:

function my_endpoint(WP_REST_Request $request) {

    $param = $request->get_param('id');
}

Tämä mahdollistaa paremman kontrollin.

5. Rate limiting (usein unohdettu)

Ilman rajoituksia API on brute force -kohde.

Yksinkertainen Redis-pohjainen malli:

$key = 'rate_' . $_SERVER['REMOTE_ADDR'];

$count = (int) get_transient($key);

if ($count > 100) {
    return new WP_Error('rate_limited', 'Too many requests', 429);
}

set_transient($key, $count + 1, MINUTE_IN_SECONDS);

6. Älä paljasta liikaa dataa

Huono:

return get_users();

Parempi:

return array_map(function($user) {

    return [
        'id' => $user->ID,
        'name' => $user->display_name
    ];
}, get_users());

7. Error handling oikein

Älä palauta raakaa PHP-erroria.

return new WP_Error(
    'invalid_request',
    'Invalid ID provided',
    ['status' => 400]
);

8. Nonce ei riitä yksinään

Nonce suojaa lähinnä browser-pohjaisia requesteja.

API-integraatioissa:

  • käytä Application Passwords tai OAuth
  • nonce vain lisäsuojana

9. HTTPS on pakollinen

Ilman HTTPS:

  • credentials voidaan siepata
  • API liikenne ei ole turvallista

10. CORS hallinta

Jos frontend erillisessä domainissa:

add_action('rest_api_init', function () {
    remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
});

Ja lisää hallittu CORS:

header("Access-Control-Allow-Origin: https://example.com");

11. Query injection riskit

Huono:

$wpdb->get_results("SELECT * FROM wp_posts WHERE ID = $id");

Parempi:

$wpdb->prepare(
    "SELECT * FROM wp_posts WHERE ID = %d",
    $id
);

12. Cache API-vastauksille

Suorituskyky ja turvallisuus:

$key = 'api_response_' . md5(json_encode($request->get_params()));

$data = get_transient($key);

if (!$data) {

    $data = heavy_query();

    set_transient($key, $data, 300);
}

13. Audit logging

Tärkeä enterprise-tasoilla:

error_log('API call by user ' . get_current_user_id());

Tai oma logging-taulu.

14. Versionointi API:ssa

Älä muuta endpointteja rikki:

myplugin/v1/
myplugin/v2/

15. Least privilege -periaate

Älä käytä:

  • admin capabilityä kaikkialla

Parempi:

  • custom capabilityt
current_user_can('myplugin_api_access');

16. JSON response kontrolli

Käytä aina:

return rest_ensure_response($data);

17. Payload size rajoitus

Estä massiiviset requestit:

if (strlen($request->get_body()) > 100000) {
    return new WP_Error('too_large', 'Payload too large', 413);
}

18. Yleisimmät virheet

  • ei permission_callbackia
  • raw SQL queryt
  • liian laajat user/data endpointit
  • ei rate limitingia
  • liiallinen data exposure
  • nonce luullaan riittäväksi API-suojaksi
  • ei HTTPS

19. Paras arkkitehtuuri

Turvallinen WordPress REST API sisältää:

  • authentication layer (Application Passwords / OAuth)
  • permission callbacks jokaisessa endpointissa
  • input sanitization + validation
  • rate limiting (Redis tai transient)
  • cache layer
  • versionointi
  • audit logging
  • minimaalinen data exposure
  • HTTPS pakollisena

Yhteenveto

Turvallinen REST API WordPressissä ei synny pelkästä endpointin luomisesta, vaan kerroksellisesta arkkitehtuurista, jossa autentikointi, valtuutus, validointi ja rajoitukset on suunniteltu alusta asti.

Kun nämä asiat tehdään oikein, WordPressistä voi rakentaa erittäin skaalautuvan ja turvallisen API-backendin, joka toimii luotettavasti myös suurissa integraatioissa ja headless-ympäristöissä.

🍪