WordPress 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.
Endpointit rekisteröidään näin:...
Ilman autentikointia API on avoin....
function my_endpoint_permission() { return current_user_can('manage_options'); } Endpoint:...
Älä koskaan käytä raakaa inputtia....
Käytä aina $request:...
Ilman rajoituksia API on brute force -kohde....
Huono:...
Älä palauta raakaa PHP-erroria....
Nonce suojaa lähinnä browser-pohjaisia requesteja....
Ilman HTTPS:...
Jos frontend erillisessä domainissa:...
Huono:...
Suorituskyky ja turvallisuus:...
Tärkeä enterprise-tasoilla:...
Älä muuta endpointteja rikki:...
Älä käytä:...
Käytä aina:...
Estä massiiviset requestit:...
Turvallinen WordPress REST API sisältää:...
Turvallinen WordPress REST API sisältää:...
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ä.