Apa Itu xmlrpc.php di WordPress dan Cara Menonaktifkannya (Panduan Lengkap 2024)

WordPress menguasai lebih dari 43% dari semua situs web di internet — dan dengan dominasi tersebut datang permukaan serangan yang signifikan. Salah satu titik masuk yang paling sering dieksploitasi adalah file yang disebut xmlrpc.php. Baik Anda seorang pengembang berpengalaman atau pemilik situs yang mengelola instalasi WordPress pertama Anda, memahami apa yang dilakukan file ini, mengapa file ini berbahaya, dan cara menonaktifkannya sangat penting untuk menjaga keamanan situs Anda.

Panduan ini mencakup semua yang perlu Anda ketahui tentang xmlrpc.php: tujuannya, ancaman dunia nyata yang diperkenalkannya, dan tiga metode terbukti untuk menonaktifkannya — tidak diperlukan gelar teknis.

Apa Itu xmlrpc.php di WordPress?

xmlrpc.php adalah file inti WordPress yang mengimplementasikan protokol XML-RPC — sistem remote procedure call (RPC) yang menggunakan XML untuk mengenkode panggilan dan HTTP sebagai mekanisme transportasi. Dalam bahasa sederhana, ini memungkinkan aplikasi dan layanan eksternal untuk berkomunikasi dengan situs WordPress Anda tanpa menggunakan antarmuka browser web standar.

Diperkenalkan jauh sebelum REST API WordPress ada, xmlrpc.php adalah jembatan utama antara WordPress dan dunia luar. Ini memungkinkan:

• Penerbitan konten jarak jauh — Klien blog seperti Windows Live Writer atau MarsEdit dapat memposting artikel langsung ke situs Anda.
• Manajemen aplikasi mobile — Aplikasi mobile WordPress resmi secara historis mengandalkan XML-RPC untuk mengelola postingan, halaman, dan komentar.
• Trackback dan pingback — Protokol menangani notifikasi antar situs, memberitahu blog lain ketika Anda menautkan ke konten mereka.
• Integrasi pihak ketiga — Layanan seperti IFTTT, Zapier (dalam konfigurasi yang lebih lama), dan berbagai plugin menggunakan XML-RPC untuk berinteraksi dengan WordPress secara terprogram.

Meskipun fitur-fitur ini benar-benar berguna pada awal tahun 2010-an, WordPress telah memperkenalkan REST API, yang menyediakan cara yang lebih aman, modern, dan fleksibel untuk mencapai hasil yang sama. Akibatnya, xmlrpc.php sekarang sebagian besar sudah usang — tetapi tetap aktif secara default di setiap instalasi WordPress.

Mengapa xmlrpc.php Merupakan Risiko Keamanan?

Masalah dengan xmlrpc.php bukan pada protokolnya sendiri — melainkan file tersebut tetap diaktifkan meskipun Anda tidak menggunakannya, menciptakan vektor serangan yang tidak perlu. Peneliti keamanan dan penyedia hosting secara konsisten menandainya sebagai salah satu kerentanan WordPress teratas. Berikut alasannya:

1. Serangan Amplifikasi Brute-Force

Ini adalah ancaman paling berbahaya dan paling banyak dieksploitasi. Serangan brute-force standar terhadap halaman login WordPress (wp-login.php) terbatas pada satu upaya kredensial per permintaan HTTP. XML-RPC mengubah ini secara dramatis.

Metode system.multicall dalam XML-RPC memungkinkan penyerang untuk menggabungkan ratusan atau bahkan ribuan kombinasi nama pengguna/kata sandi ke dalam satu permintaan HTTP. Ini berarti:

• Pembatasan laju tradisional dan plugin percobaan login dilewati.
• Penyerang dapat menguji daftar kredensial besar dengan bandwidth minimal.
• Log server menunjukkan jauh lebih sedikit permintaan, membuat deteksi lebih sulit.

Satu botnet dapat mengompromikan situs WordPress dengan kata sandi lemah dalam hitungan menit menggunakan teknik ini.

2. Amplifikasi DDoS melalui Pingback

Penyerang dapat memanfaatkan fungsionalitas pingback dalam xmlrpc.php untuk mengubah situs WordPress Anda menjadi peserta yang tidak disadari dalam serangan Distributed Denial of Service (DDoS). Dengan mengirimkan permintaan pingback yang dirancang khusus, aktor jahat dapat menginstruksikan server Anda untuk mengirim permintaan HTTP ke URL target — secara efektif menggunakan sumber daya server Anda dan reputasi IP terhadap pihak ketiga.

Ini tidak hanya merugikan target serangan tetapi juga dapat menyebabkan IP server Anda masuk daftar hitam, mempengaruhi kemampuan pengiriman dan reputasi situs Anda.

3. Kelelahan Sumber Daya Server

Bahkan tanpa serangan terkoordinasi, xmlrpc.php adalah target umum untuk bot pemindaian otomatis yang mencari kerentanan. Pemeriksaan konstan ini mengonsumsi siklus CPU, memori, dan bandwidth — sumber daya yang seharusnya melayani pengunjung sah Anda. Terutama di lingkungan hosting bersama, ini dapat secara nyata menurunkan kinerja situs.

4. Paparan yang Tidak Perlu

Jika Anda tidak menggunakan alat penerbitan jarak jauh, aplikasi seluler yang memerlukan XML-RPC, atau integrasi pihak ketiga warisan, maka xmlrpc.php memberikan manfaat nol untuk situs Anda sambil mempertahankan permukaan serangan yang sepenuhnya aktif. Prinsip privilege minimal dalam keamanan menyatakan: jika Anda tidak membutuhkannya, nonaktifkan.

Apakah Anda Benar-benar Membutuhkan xmlrpc.php?

Sebelum menonaktifkannya, tanyakan pada diri sendiri:

Bagi sebagian besar pemilik situs WordPress, jawabannya adalah: Anda tidak membutuhkannya. Nonaktifkan saja.

Cara Menonaktifkan xmlrpc.php di WordPress: 3 Metode

Ada tiga metode yang dapat diandalkan untuk menonaktifkan xmlrpc.php, mulai dari yang ramah pemula hingga tingkat server. Pilih yang paling sesuai dengan tingkat kenyamanan teknis dan lingkungan hosting Anda.

Metode 1: Gunakan Plugin Keamanan WordPress (Paling Mudah)

Jika Anda menginginkan solusi tanpa kode dengan risiko minimal untuk merusak apa pun, plugin keamanan adalah titik awal terbaik Anda.

Plugin yang direkomendasikan:

• Wordfence Security — Firewall komprehensif dan pemindai malware dengan pemblokiran XML-RPC.
• iThemes Security (sekarang Solid Security) — Toggle khusus untuk menonaktifkan XML-RPC.
• Disable XML-RPC — Plugin ringan dengan tujuan tunggal yang melakukan persis apa yang dikatakannya.

Langkah demi langkah:

1. Masuk ke dasbor admin WordPress Anda.
2. Navigasikan ke Plugin → Tambah Baru.
3. Cari plugin pilihan Anda (misalnya, “Disable XML-RPC”) dan klik Instal Sekarang, kemudian Aktifkan.
4. Buka halaman pengaturan plugin. Untuk plugin keamanan khusus seperti Wordfence atau iThemes Security, cari bagian berlabel XML-RPC atau WordPress Tweaks.
5. Aktifkan opsi untuk menonaktifkan XML-RPC atau memblokir permintaan XML-RPC.
6. Simpan perubahan Anda.

Kelebihan: Sederhana, dapat dibalikkan, tidak perlu pengeditan file.

Kekurangan: Menambah ketergantungan plugin; file masih ada di server (permintaan diblokir di tingkat aplikasi, bukan tingkat server).

Metode 2: Blokir xmlrpc.php melalui .htaccess (Direkomendasikan untuk Server Apache)

Untuk lingkungan hosting berbasis Apache, mengedit file .htaccess memblokir permintaan di tingkat web server — sebelum WordPress bahkan dimuat. Ini lebih efisien dan memberikan perlindungan yang lebih kuat daripada plugin saja.

Langkah demi langkah:

1. Akses file situs Anda melalui FTP (menggunakan FileZilla atau serupa) atau melalui File Manager panel kontrol hosting Anda.
2. Navigasikan ke direktori root WordPress Anda — ini biasanya public_html atau www.
3. Temukan file .htaccess. Jika Anda tidak dapat melihatnya, aktifkan file tersembunyi di klien FTP Anda (di FileZilla: Server → Force Showing Hidden Files) atau di pengaturan file manager Anda.
4. Buka .htaccess untuk diedit dan tambahkan blok berikut di akhir file:

# Block WordPress xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

1. Simpan file dan tutup editor Anda.

Untuk memverifikasi bahwa ini berfungsi, kunjungi https://yourdomain.com/xmlrpc.php di browser Anda. Anda harus menerima kesalahan 403 Forbidden alih-alih respons XML-RPC default.

Kelebihan: Pemblokiran tingkat server lebih efisien; mengurangi beban server; tidak memerlukan plugin.

Kekurangan: Memerlukan akses file; pengeditan .htaccess yang salah dapat sementara merusak situs Anda (selalu simpan cadangan).

> Pro tip: Jika hosting Anda menggunakan Nginx alih-alih Apache, tambahkan berikut ini ke konfigurasi blok server Nginx Anda:

>

> “`nginx

> location = /xmlrpc.php {

> deny all;

> access_log off;

> log_not_found off;

> }

> “`

Metode 3: Nonaktifkan melalui functions.php (WordPress Filter Hook)

Metode ini menggunakan filter WordPress untuk menonaktifkan fungsionalitas XML-RPC secara terprogram dari dalam tema atau plugin kustom. Ini adalah solusi berbasis kode yang bersih yang bekerja di lapisan aplikasi WordPress.

Langkah demi langkah:

Opsi A — Melalui Theme Editor (cepat tetapi tidak direkomendasikan untuk produksi):

1. Di dasbor WordPress Anda, buka Penampilan → Theme Editor.
2. Pilih functions.php dari daftar file di sisi kanan.
3. Tambahkan kode berikut di akhir file:

// Disable XML-RPC
add_filter( 'xmlrpc_enabled', '__return_false' );

1. Klik Update File untuk menyimpan.

Opsi B — Melalui Plugin Kustom (direkomendasikan):

Daripada mengedit functions.php tema Anda (yang akan ditimpa pada pembaruan tema), buat plugin kustom sederhana:

1. Menggunakan FTP atau File Manager, navigasikan ke wp-content/plugins/.
2. Buat folder baru bernama disable-xmlrpc.
3. Di dalam folder itu, buat file bernama disable-xmlrpc.php dengan konten berikut:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Disables XML-RPC functionality for improved security.
 * Version: 1.0
 * Author: Your Name
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

1. Buka Plugin → Plugin Terinstal di dasbor Anda dan aktifkan Disable XML-RPC.

Kelebihan: Bersih, independen tema (saat menggunakan metode plugin kustom); mudah untuk dibalikkan.

Kekurangan: Tingkat aplikasi saja — file masih ada dan dapat menerima permintaan (meskipun akan ditolak); tidak mengurangi beban server seefektif pemblokiran .htaccess.

Menggabungkan Metode untuk Keamanan Maksimal

Untuk perlindungan terkuat, gabungkan Metode 2 (.htaccess) dengan Metode 3 (filter hook):

• Aturan .htaccess memblokir permintaan di tingkat server, mengurangi beban.
• Filter hook memastikan XML-RPC dinonaktifkan bahkan jika aturan .htaccess pernah dilewati atau ditimpa.

Pendekatan berlapis ini mengikuti prinsip keamanan defense in depth — kontrol independen ganda yang melindungi aset yang sama.

Cara Memverifikasi xmlrpc.php Berhasil Dinonaktifkan

Setelah menerapkan metode pilihan Anda, konfirmasi bahwa itu berfungsi:

1. Tes browser: Kunjungi https://yourdomain.com/xmlrpc.php. Blokir yang berhasil menunjukkan kesalahan 403 Forbidden atau 404 Not Found.
2. Pemeriksa XML-RPC online: Gunakan alat seperti xmlrpc.eritreo.it untuk menguji apakah endpoint XML-RPC situs Anda merespons.
3. Log server: Periksa log akses Anda untuk permintaan yang tersisa ke xmlrpc.php — penurunan mendadak mengkonfirmasi blokir berfungsi.

Memilih Hosting yang Tepat untuk Keamanan WordPress

Menonaktifkan xmlrpc.php hanyalah satu lapisan keamanan WordPress. Fondasi situs WordPress yang aman dimulai dengan memilih penyedia hosting yang tepat — yang menawarkan kontrol keamanan tingkat server, backup rutin, dan infrastruktur yang dirancang untuk menahan serangan.

Di AlexHost, keamanan WordPress dibangun ke dalam stack hosting. Baik Anda menjalankan blog pribadi atau situs bisnis dengan traffic tinggi, paket yang tepat membuat perbedaan signifikan:

• VPS Hosting — Akses root penuh memungkinkan Anda menerapkan konfigurasi keamanan tingkat server, termasuk aturan Nginx atau Apache khusus untuk memblokir xmlrpc.php di tingkat infrastruktur. Ideal untuk pengembang dan situs yang berkembang yang membutuhkan kontrol granular.

• Shared Web Hosting — Titik masuk yang hemat biaya untuk situs WordPress, dengan konfigurasi keamanan terkelola dan akses mudah ke .htaccess editing melalui panel kontrol.

• VPS dengan cPanel — Menggabungkan kekuatan server pribadi virtual dengan antarmuka cPanel yang familiar, memudahkan pengelolaan file .htaccess, sertifikat SSL, dan pengaturan keamanan tanpa keahlian command-line.

• Sertifikat SSL — Mengenkripsi situs Anda dengan HTTPS adalah baseline keamanan yang tidak dapat ditawar. Sertifikat SSL memastikan bahwa bahkan jika permintaan XML-RPC dibuat, kredensial dan data yang ditransmisikan dienkripsi dalam transit.

• Pendaftaran Domain — Simpan domain dan hosting Anda di bawah satu atap untuk manajemen DNS yang disederhanakan dan permukaan serangan yang berkurang dari kerentanan registrar pihak ketiga.

Menggabungkan infrastruktur hosting yang kuat dengan pengerasan tingkat aplikasi seperti menonaktifkan xmlrpc.php memberikan situs WordPress Anda postur keamanan multi-lapisan yang kokoh.

Pertanyaan yang Sering Diajukan

Apakah menonaktifkan xmlrpc.php akan merusak situs WordPress saya?

Untuk sebagian besar pengguna, tidak. Jika Anda tidak menggunakan klien blogging desktop warisan, aplikasi WordPress resmi (versi modern menggunakan REST API), atau integrasi pihak ketiga spesifik yang secara eksplisit memerlukan XML-RPC, menonaktifkannya tidak akan memiliki efek yang terlihat pada fungsionalitas.

Apakah Jetpack memerlukan xmlrpc.php?

Versi Jetpack yang lebih lama mengandalkan XML-RPC. Versi Jetpack modern terutama menggunakan WordPress.com REST API. Periksa dokumentasi versi Jetpack spesifik Anda sebelum menonaktifkan XML-RPC.

Bisakah saya hanya menonaktifkan pingback daripada semua XML-RPC?

Ya. Jika Anda ingin membuat XML-RPC tetap aktif untuk tujuan lain tetapi menghilangkan penyalahgunaan pingback, tambahkan ini ke functions.php:

// Disable pingbacks only
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Apakah xmlrpc.php dihapus di versi WordPress yang lebih baru?

Tidak. Sejak rilis WordPress terbaru, xmlrpc.php masih disertakan dan diaktifkan secara default. Tim inti WordPress telah membahas masa depannya, tetapi tetap ada untuk kompatibilitas mundur.

Kesimpulan

xmlrpc.php adalah file WordPress warisan yang dulunya melayani tujuan yang sah tetapi hari ini mewakili salah satu kerentanan yang paling sering dieksploitasi dalam instalasi WordPress di seluruh dunia. Kecuali Anda memiliki kebutuhan spesifik dan terdokumentasi untuk fungsionalitas XML-RPC, menonaktifkannya adalah peningkatan keamanan yang mudah dan berdampak tinggi yang membutuhkan waktu kurang dari lima menit untuk diimplementasikan.

Untuk merangkum pilihan Anda:

Terapkan metode yang sesuai dengan lingkungan Anda, verifikasi bahwa blokir berfungsi, dan gabungkan dengan fondasi hosting yang solid. Keamanan bukan tindakan tunggal — ini adalah praktik berkelanjutan. Jaga WordPress core, tema, dan plugin Anda tetap diperbarui, pantau log akses Anda secara teratur, dan pilih infrastruktur hosting yang mendukung tujuan keamanan Anda sejak awal.