Dua Fitur Bawaan WordPress Ini Jadi Celah Favorit Penyerang, Ini Cara Nambalnya Tanpa Ngerusak Situs

Server-mu tiba-tiba melambat jam 2 pagi. Kamu cek log server, dan kamu lihat ribuan request POST ke /xmlrpc.php atau /wp-json/wp/v2/users. CPU server menembus 100%. Situsmu… dijebol? Belum. Tapi ini lebih buruk dari DDoS biasa. Ini adalah serangan brute force massal lewat REST API dan XML-RPC yang nggak kamu sadari udah berjalan berminggu-minggu.

Banyak developer WordPress malah ambil jalan pintas: blokir total xmlrpc.php dan disable REST API. Hasilnya? Jetpack berhenti bekerja, aplikasi mobile nyangkut, dan integrasi pihak ketiga hancur. Artikel ini akan menunjukkan cara yang lebih presisi: mengamankan tanpa menghancurkan.

Kenapa REST API dan XML-RPC Itu Penting (Spoiler: Kamu Pakai, Entah Sadar atau Nggak)

Kedua fitur ini adalah jembatan komunikasi antara WordPress-mu dengan dunia luar. Tanpa mereka, banyak fitur modern yang kamu andalkan sehari-hari akan langsung mati.

XML-RPC sudah ada sejak WordPress 1.5. Dulu, ini satu-satunya cara aplikasi eksternal “berbicara” dengan WordPress. Sekarang, XML-RPC masih dipakai oleh:

• Jetpack (koneksi ke WordPress.com)
• Aplikasi desktop WordPress (sebelum REST API)
• Beberapa plugin backup jarak jauh
• Pingbacks dan trackbacks

REST API diperkenalkan di WordPress 4.7. Lebih modern, lebih cepat, berbasis JSON. Dipakai oleh:

• Gutenberg block editor
• Aplikasi mobile WordPress terbaru
• WooCommerce mobile apps
• Custom frontend (React, Vue, headless WordPress)
• Integrasi pihak ketiga seperti Zapier, IFTTT, dan automation tools

Kalau kamu pake WooCommerce dan aplikasi mobile-nya, REST API wajib menyala. Kalau kamu pake Jetpack buat stats dan proteksi brute force, XML-RPC wajib menyala. Blokir salah satunya, dan fitur-fitur ini langsung tumbang.

Cara Penyerang Mengeksploitasi XML-RPC dan REST API

Penyerang nggak cuma nebak password via /wp-login.php. Mereka sekarang pakai metode yang jauh lebih canggih dan efisien.

1. XML-RPC Amplification Attack

Satu request ke system.multicall bisa memvalidasi ratusan password dalam satu panggilan HTTP. Ini jauh lebih efisien buat penyerang dibanding brute force tradisional. Satu request = 1000 percobaan login. Bandingkan dengan /wp-login.php yang hanya 1 percobaan per request. Amplifikasi inilah yang bikin XML-RPC jadi senjata favorit.

2. REST API User Enumeration

Endpoint /wp-json/wp/v2/users membeberkan daftar user, termasuk admin, tanpa perlu autentikasi. Penyerang tinggal kirim GET request, dan mereka dapat username valid buat target brute force berikutnya. Coba sendiri: buka situsmu di incognito dan akses endpoint itu. Kalau muncul data, berarti informasi user-mu terbuka lebar.

3. Unauthenticated Content Injection via Custom Endpoints

Beberapa plugin mengekspos custom endpoints yang nggak diproteksi. Endpoint ini bisa dipakai upload file sembarangan atau injeksi konten tanpa login. Ini bukan bug WordPress core, tapi efek samping dari plugin yang tidak mengikuti standar keamanan REST API.

Menurut OWASP API Security Top 10, tiga serangan paling umum pada API WordPress adalah broken authentication, excessive data exposure, dan lack of rate limiting. Persis apa yang terjadi pada endpoint WordPress default. Data internal tim keamanan Wordfence menunjukkan bahwa 62% serangan brute force pada situs WordPress kini memanfaatkan XML-RPC atau REST API, bukan lagi form login utama. Lihat juga: 7 Jalur yang Dipakai Penyerang Menjebol Situs WordPress.

Teknik Membatasi Akses Tanpa Merusak Integrasi

Ini bagian yang membedakan admin biasa dari developer berpengalaman: selective restriction. Kamu nggak blokir semuanya, kamu cuma nutup lubang yang terbuka lebar.

1. Rate Limiting di Level Server (Bukan Plugin)

Pendekatan paling efektif adalah membatasi request di tingkat web server. Plugin PHP datang belakangan, setelah request masuk dan membebani CPU. Untuk Nginx, kamu bisa memasang konfigurasi seperti ini:

# Rate limit untuk xmlrpc.php
location = /xmlrpc.php {
    limit_req zone=xmlrpc burst=5 nodelay;
    limit_req_status 429;
}

# Rate limit untuk REST API
location ~ ^/wp-json/ {
    limit_req zone=restapi burst=10 nodelay;
    limit_req_status 429;
}

Untuk Apache, gunakan mod_evasive atau mod_security. Konfigurasi ini menghentikan brute force sebelum mencapai WordPress, menghemat CPU dan database. Pelajari lebih lanjut di dokumentasi resmi Nginx rate limiting.

2. Selective Endpoint Filtering via functions.php

Jangan blokir seluruh REST API. Blokir hanya endpoint yang berbahaya. Tambahkan kode ini ke functions.php theme-mu:

// Blokir user enumeration via REST API
add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    return $endpoints;
});

Atau, jika situsmu tidak butuh REST API publik sama sekali, batasi hanya untuk user yang sudah login:

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! is_user_logged_in() ) {
        return new WP_Error( 'rest_not_logged_in', 
            'REST API hanya untuk user terautentikasi', 
            array( 'status' => 401 ) );
    }
    return $result;
});

3. Application Password untuk Autentikasi yang Aman

Sejak WordPress 5.6, kamu bisa menggunakan Application Passwords untuk memberi akses API tanpa membocorkan password utama. Ini solusi ideal untuk integrasi pihak ketiga. Setiap aplikasi mendapat password unik yang bisa dicabut kapan saja tanpa mengubah password admin. Pendekatan ini juga diadopsi oleh WordPress REST API Handbook sebagai best practice autentikasi.

Framework Praktis: Audit Endpoint API-mu Hari Ini Juga

Coba jalankan tiga audit ini sekarang, nggak perlu tools mahal:

1. Buka /wp-json/wp/v2/users di browser incognito. Kalau muncul daftar username, REST API-mu bocor. Tutup endpoint ini segera pakai kode di atas.
2. Cek akses log /xmlrpc.php. Jalankan perintah grep xmlrpc.php /var/log/nginx/access.log | wc -l. Kalau angkanya ribuan per hari padahal kamu nggak pakai Jetpack, saatnya rate limit.
3. Audit custom endpoints. Jalankan wp rest-api list via WP-CLI (kalau tersedia). Periksa endpoint mana yang terbuka tanpa autentikasi.

Framework sederhana yang saya pakai untuk klien: setiap endpoint API harus melewati tiga pertanyaan. Apakah endpoint ini butuh autentikasi? Apakah endpoint ini butuh rate limit? Apakah data yang diekspos cukup minimal? Kalau jawabannya “tidak” untuk dua pertanyaan pertama, endpoint itu harus dikunci. Baca juga: 9 Lapis Keamanan WooCommerce yang Wajib Kamu Pasang.

Kesimpulan

REST API dan XML-RPC bukan musuh. Mereka adalah tools yang tidak dikunci dengan benar. Penyerang akan selalu mencari jalur yang paling sedikit resistensinya, dan saat ini, API endpoints adalah target favorit mereka karena banyak admin mengabaikannya.

Kamu tidak perlu memblokir semuanya. Kamu hanya perlu: rate limit di server, selective endpoint filtering, application password untuk integrasi eksternal, dan audit berkala. Ambil satu langkah sekarang: buka browser incognito, akses /wp-json/wp/v2/users di situsmu, dan lihat apa yang terbuka. Temuanmu mungkin mengejutkan, dan itulah langkah pertama menuju pertahanan yang lebih solid.

Pertanyaan yang Sering Diajukan (FAQ)

Apakah aman memblokir total xmlrpc.php?

Hanya jika kamu yakin tidak menggunakan Jetpack, WordPress mobile app versi lama, dan plugin yang bergantung pada XML-RPC. Cek dulu dengan menonaktifkan sementara selama 24 jam dan pantau apakah ada fitur yang rusak. Alternatif yang lebih aman adalah rate limiting alih-alih blokir total.

Bagaimana cara tahu REST API saya sedang diserang?

Periksa access log server untuk lonjakan request ke /wp-json/ dalam waktu singkat, terutama dari IP tunggal. Tools seperti Fail2Ban bisa mendeteksi ini otomatis. Plugin keamanan seperti Wordfence juga mencatat percobaan brute force via REST API di dashboard-nya.

Apakah Gutenberg masih berfungsi kalau REST API dibatasi?

Ya, selama user sudah login. Gutenberg menggunakan REST API dengan cookie autentikasi yang sama dengan session WordPress. Pembatasan REST API untuk user yang sudah login (seperti contoh kode di atas) tidak akan merusak Gutenberg. Yang berbahaya adalah memblokir seluruh REST API, termasuk untuk user login.

XML-RPC vs REST API: mana yang lebih aman?

Dari sisi arsitektur, REST API lebih modern dan lebih granular dalam permission control. XML-RPC punya kelemahan fundamental: method system.multicall memungkinkan amplifikasi serangan. Namun keduanya tetap aman jika dikonfigurasi dengan benar. Fokuslah pada rate limiting dan authentication hardening, bukan memilih salah satu.