Clouder

Keamanan Website WordPress: Panduan Hardening dan Backup

Oleh Tim Clouder ·

Sebagian besar situs WordPress yang diretas tidak dibobol lewat celah canggih. Pintu masuknya biasanya hal sepele: plugin yang tidak diperbarui selama berbulan-bulan, kata sandi admin yang dipakai juga di tempat lain, atau tema bajakan yang sudah disisipi kode jahat sejak awal. Kabar baiknya, menjaga keamanan website WordPress sebagian besar soal disiplin, bukan soal alat mahal.

Panduan ini membahas lapisan pertahanan yang benar-benar berpengaruh, diurutkan dari yang paling penting: pembaruan, autentikasi, hak akses, konfigurasi server, firewall, lalu strategi backup yang bisa diandalkan saat semua lapisan lain gagal. Di bagian akhir ada langkah konkret jika situs Anda sudah terlanjur terinfeksi.

Satu prinsip yang perlu dipegang sejak awal: keamanan tidak pernah 100%. Karena itu backup bukan pelengkap, melainkan bagian inti dari strategi keamanan. Situs yang bisa dipulihkan dalam satu jam jauh lebih aman secara bisnis daripada situs yang "belum pernah diretas" tetapi tidak punya salinan yang bisa dipakai.

Mengapa situs WordPress sering menjadi sasaran

WordPress dipakai oleh sangat banyak situs, sehingga penyerang cukup menulis satu skrip untuk memindai jutaan alamat sekaligus. Serangan hampir selalu otomatis: bot mencari versi plugin tertentu yang punya celah diketahui, mencoba kombinasi username dan kata sandi umum di wp-login.php, atau mengirim ribuan permintaan ke xmlrpc.php. Situs Anda tidak perlu "terkenal" untuk diserang; cukup online.

Tujuan penyerang pun jarang berupa sabotase terang-terangan. Yang lebih sering terjadi:

  • SEO spam — halaman tersembunyi berisi tautan judi atau obat ditanam di situs Anda untuk mendongkrak situs lain.
  • Redirect jahat — pengunjung dari Google dialihkan ke situs penipuan, sementara admin yang login melihat situs normal.
  • Pengiriman spam email — skrip PHP disisipkan untuk mengirim email massal, sehingga IP server masuk daftar hitam dan email bisnis Anda ikut masuk folder spam.
  • Pencurian data — data pelanggan WooCommerce, kartu, atau akun pengguna.
  • Batu loncatan — situs dipakai untuk menyerang situs lain atau menyimpan file phishing.

Karena itu, keamanan website WordPress harus dilihat sebagai pengurangan permukaan serangan dan percepatan pemulihan, bukan sekadar memasang satu plugin keamanan lalu lupa.

Pembaruan: lapisan pertahanan paling efektif

Mayoritas celah yang dieksploitasi pada situs WordPress berada di plugin dan tema, bukan di inti WordPress. Celah yang sudah diumumkan dan diperbaiki pengembangnya tetap berbahaya bagi situs yang belum memperbarui, karena detail celahnya kini diketahui publik dan bot segera memindainya.

Atur pembaruan otomatis dengan bijak

WordPress sudah memiliki pembaruan otomatis sejak versi 3.7, dan secara default rilis minor (perbaikan keamanan, misalnya 6.x.1 ke 6.x.2) dipasang otomatis. Sejak WordPress 5.5, Anda juga bisa mengaktifkan pembaruan otomatis per plugin dan tema dari menu Plugin dan Tampilan → Tema.

Rekomendasi praktis:

  • Aktifkan auto-update untuk plugin kecil yang jarang bermasalah dan plugin keamanan.
  • Untuk plugin besar yang memengaruhi transaksi (WooCommerce, page builder, plugin membership), perbarui manual setelah mengecek changelog, idealnya di situs staging terlebih dahulu.
  • Pastikan versi PHP juga didukung. PHP versi lama yang sudah tidak menerima patch keamanan adalah risiko tersendiri; gunakan PHP 8 yang masih didukung.

Buang yang tidak dipakai

Plugin dan tema yang dinonaktifkan tetap berupa file PHP di server dan tetap bisa dieksploitasi jika dipanggil langsung. Hapus, jangan hanya nonaktifkan. Sisakan satu tema default sebagai cadangan. Lakukan audit berkala dengan pertanyaan sederhana: apakah plugin ini masih diperbarui pengembangnya dalam 12 bulan terakhir? Jika tidak, cari pengganti.

Hindari tema dan plugin "nulled" (versi premium bajakan). File semacam ini sering sudah berisi backdoor sejak diunduh, sehingga semua langkah keamanan lain menjadi sia-sia.

Autentikasi kuat dan prinsip hak akses minimum

Kata sandi dan 2FA

Gunakan kata sandi unik yang dibuat password manager untuk setiap akun admin, lalu aktifkan autentikasi dua faktor (2FA) berbasis aplikasi authenticator (TOTP) melalui plugin 2FA yang terpercaya. Dokumentasi resmi hardening WordPress juga menyarankan two-step authentication sebagai lapisan tambahan. Dengan 2FA, kata sandi yang bocor dari situs lain tidak cukup untuk masuk ke dashboard Anda.

Beberapa hal lain yang sering terlewat:

  • Jangan memakai username admin, administrator, atau nama domain Anda.
  • Batasi percobaan login (rate limiting) untuk menghentikan brute force di wp-login.php.
  • Pastikan halaman login dan dashboard selalu diakses lewat HTTPS. Jika belum, baca panduan SSL gratis Let's Encrypt.

Least privilege: beri peran seminimal mungkin

WordPress punya peran bawaan: Administrator, Editor, Author, Contributor, dan Subscriber. Penulis artikel cukup diberi peran Author atau Editor, bukan Administrator. Akun freelancer yang sudah selesai bekerja harus dihapus atau diturunkan perannya. Semakin sedikit akun Administrator, semakin kecil dampak satu akun yang bocor.

Prinsip yang sama berlaku untuk database. Dokumentasi WordPress menyebutkan operasi normal hanya butuh hak SELECT, INSERT, UPDATE, dan DELETE, tetapi juga mengingatkan bahwa update besar dan sebagian plugin memerlukan perubahan skema. Jadi, jika Anda mencabut hak ALTER atau DROP, lakukan hanya bila Anda punya backup database yang teruji dan siap memberi hak sementara saat update.

Hardening di level file dan server

Permission file yang benar

Rekomendasi dokumentasi resmi WordPress: direktori 755, file 644, dan wp-config.php dibatasi menjadi 440 atau 400 agar hanya pemilik (dan web server, bila perlu) yang bisa membacanya. Jangan pernah memberi 777 untuk "memperbaiki" error upload; itu membuat folder bisa ditulis oleh proses mana pun.

Jika Anda punya akses SSH, perintahnya:

cd /home/tokoanda/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Sesuaikan path dengan direktori situs Anda. Jika setelah 440 WordPress tidak bisa membaca konfigurasi (tergantung bagaimana PHP dijalankan), gunakan 640.

Isolasi akun juga penting. Di shared hosting, pastikan setiap situs berjalan di bawah user Linux masing-masing. Dengan begitu, jika satu situs di akun yang sama atau di server yang sama terinfeksi, penyerang tidak otomatis bisa menulis ke file situs lain. Inilah salah satu poin yang perlu dicek saat memilih hosting untuk website bisnis.

Matikan editor file di dashboard

Tambahkan baris berikut di wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Baris ini menghapus menu editor tema dan plugin, sehingga penyerang yang berhasil masuk sebagai admin tidak bisa langsung menyisipkan kode PHP lewat dashboard. Jika Anda ingin mengunci lebih ketat (termasuk instalasi plugin dari dashboard), ada DISALLOW_FILE_MODS, tetapi konsekuensinya update juga harus dilakukan lewat cara lain.

Blokir eksekusi PHP di folder uploads

Folder wp-content/uploads hanya berisi gambar dan dokumen, tidak perlu menjalankan PHP. Banyak backdoor disimpan di sana karena folder ini bisa ditulis. Di server Nginx, contohnya:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

XML-RPC: matikan jika tidak dipakai

xmlrpc.php adalah antarmuka lama untuk aplikasi pihak ketiga. Masalahnya, fungsi system.multicall memungkinkan ratusan percobaan kata sandi dalam satu permintaan, sehingga sering dipakai untuk brute force dan serangan pingback. Sebagian besar situs modern tidak membutuhkannya karena aplikasi mobile WordPress dan integrasi baru umumnya memakai REST API. Jika Anda tidak memakai Jetpack atau aplikasi yang bergantung pada XML-RPC, blokir di Nginx:

location = /xmlrpc.php {
    deny all;
}

Firewall (WAF) dan pemantauan

Web Application Firewall menyaring permintaan berbahaya sebelum mencapai WordPress, misalnya pola SQL injection, upload file berbahaya, atau lonjakan percobaan login. Ada dua pendekatan:

  • WAF di level DNS/proxy — seperti Cloudflare. Lalu lintas melewati jaringan mereka sebelum sampai ke server, sehingga serangan volume besar tidak membebani hosting Anda. Pastikan IP asli server tidak bocor lewat record DNS lain, misalnya record A untuk subdomain mail atau ftp yang langsung mengarah ke server.
  • WAF di level aplikasi — plugin keamanan yang memeriksa permintaan di dalam WordPress. Lebih paham konteks WordPress, tetapi tetap memakai resource server.

Kombinasi keduanya umum dipakai. Selain itu, aktifkan pemantauan: notifikasi saat ada login admin baru, pemindaian integritas file inti (membandingkan file dengan versi resmi), dan uptime monitoring.

Tanda-tanda website WordPress terkena malware

Infeksi modern sengaja dibuat tidak terlihat oleh pemilik situs. Waspadai gejala berikut:

  • Pengunjung dari Google atau perangkat mobile dialihkan ke situs lain, sementara Anda yang login melihat situs normal.
  • Hasil pencarian site:tokoanda.id di Google menampilkan judul berbahasa asing, judi, atau obat yang tidak pernah Anda buat.
  • Peringatan "situs ini mungkin diretas" di Google atau peringatan Safe Browsing di browser.
  • Muncul akun Administrator yang tidak Anda kenal.
  • File PHP asing di wp-content/uploads, file dengan nama mirip file inti (misalnya wp-confg.php), atau kode panjang berisi eval(base64_decode( di file tema.
  • Penggunaan CPU, inode, atau email keluar naik drastis tanpa alasan. Lonjakan jumlah file juga terlihat dari kuota inode; lihat penjelasan kapasitas dan inode hosting.
  • Email bisnis tiba-tiba ditolak atau masuk spam karena IP server masuk daftar hitam.

Strategi backup 3-2-1 untuk WordPress

Backup adalah jaring pengaman terakhir. Aturan 3-2-1 yang banyak dipakai:

  1. 3 salinan data — data asli ditambah dua backup.
  2. 2 media atau lokasi penyimpanan berbeda — misalnya backup otomatis di hosting dan salinan di penyimpanan cloud.
  3. 1 salinan di luar lokasi utama (off-site) — tidak berada di server yang sama dengan situs.

Backup yang hanya disimpan di folder public_html situs itu sendiri tidak memenuhi syarat: jika server bermasalah atau akun diretas, backup ikut hilang atau ikut terinfeksi.

Apa saja yang harus di-backup

Situs WordPress terdiri dari dua bagian yang sama pentingnya:

  • Database — semua artikel, halaman, pengaturan, pengguna, dan pesanan WooCommerce.
  • File — terutama wp-content (tema, plugin, uploads) dan wp-config.php. File inti WordPress bisa diunduh ulang, tetapi menyertakannya membuat restore lebih cepat.

Contoh backup manual dengan WP-CLI dan tar melalui SSH:

cd /home/tokoanda/public_html
wp db export ~/backup/db-$(date +%F).sql
tar -czf ~/backup/files-$(date +%F).tar.gz wp-content wp-config.php

Berapa sering dan berapa lama disimpan

Frekuensi backup ditentukan oleh seberapa banyak data yang rela Anda hilangkan. Blog yang terbit seminggu sekali cukup backup harian. Toko online dengan pesanan setiap jam butuh backup database lebih sering. Simpan beberapa generasi (misalnya harian selama 7 hari dan mingguan selama sebulan), karena infeksi sering baru ketahuan berminggu-minggu kemudian; backup kemarin bisa jadi sudah ikut terinfeksi.

Dokumentasi WordPress juga menyarankan menyimpan backup terenkripsi dan mencatat hash file agar integritasnya bisa diverifikasi.

Uji restore secara berkala

Backup yang tidak pernah diuji hanyalah asumsi. Minimal setiap beberapa bulan, pulihkan backup ke subdomain staging (misalnya staging.tokoanda.id) dan cek: apakah halaman tampil, login berhasil, gambar muncul, dan pesanan terbaru ada? Catat berapa lama prosesnya. Angka inilah yang menentukan berapa lama situs Anda bisa offline saat insiden nyata.

Langkah saat website WordPress diretas

Jika situs sudah terinfeksi, jangan panik dan jangan langsung menghapus file secara acak. Ikuti urutan ini:

  1. Dokumentasikan — catat gejala, waktu pertama terlihat, dan ambil backup kondisi terinfeksi untuk analisis (simpan terpisah, jangan dipakai untuk restore).
  2. Isolasi — aktifkan mode maintenance atau batasi akses agar pengunjung tidak menjadi korban redirect.
  3. Ganti semua kredensial — kata sandi admin WordPress, akun hosting, FTP/SFTP, database (lalu perbarui wp-config.php), dan email. Ganti juga salt keys di wp-config.php agar semua sesi login yang aktif terputus.
  4. Hapus akun asing — periksa daftar pengguna dan hapus Administrator yang tidak dikenal.
  5. Pulihkan atau bersihkan — cara paling bersih adalah restore dari backup sebelum tanggal infeksi, lalu segera perbarui semua plugin. Jika tidak ada backup bersih, unduh ulang WordPress inti, instal ulang plugin dan tema dari sumber resmi, lalu periksa wp-content/uploads dan database (opsi siteurl, home, widget, dan konten artikel) dari skrip asing.
  6. Tutup celahnya — cari tahu pintu masuknya (plugin usang, kata sandi lemah). Tanpa langkah ini, situs akan terinfeksi lagi dalam hitungan hari.
  7. Minta peninjauan — jika Google menandai situs, ajukan peninjauan ulang di Google Search Console setelah bersih. Cek juga reputasi email Anda dengan SPF checker dan rapikan konfigurasi SPF, DKIM, dan DMARC.

Checklist keamanan website WordPress

  • WordPress inti, plugin, dan tema selalu versi terbaru; plugin tak terpakai dihapus.
  • Tidak ada tema atau plugin bajakan.
  • Kata sandi unik dan 2FA aktif untuk semua Administrator.
  • Jumlah akun Administrator seminimal mungkin.
  • Permission direktori 755, file 644, wp-config.php 440/400.
  • DISALLOW_FILE_EDIT aktif.
  • Eksekusi PHP di uploads diblokir; xmlrpc.php diblokir jika tidak dipakai.
  • HTTPS aktif di seluruh situs.
  • WAF dan pemantauan login/integritas file aktif.
  • Backup otomatis harian, salinan off-site, beberapa generasi disimpan.
  • Restore diuji di staging minimal tiap beberapa bulan.

Pertanyaan yang sering diajukan

Apakah plugin keamanan saja sudah cukup untuk mengamankan WordPress?

Tidak. Plugin keamanan membantu memblokir serangan dan memindai malware, tetapi tidak bisa menggantikan pembaruan rutin, kata sandi kuat dengan 2FA, dan backup yang teruji. Jika plugin lain di situs Anda punya celah yang belum ditambal, risiko tetap ada.

Apakah mengganti URL wp-login.php membuat situs aman?

Mengganti URL login mengurangi kebisingan bot brute force, tetapi itu hanya menyembunyikan pintu, bukan menguncinya. Tetap gunakan pembatasan percobaan login dan 2FA, karena celah plugin tidak membutuhkan halaman login sama sekali.

Seberapa sering saya harus backup website WordPress?

Sesuaikan dengan frekuensi perubahan data. Situs yang jarang diperbarui cukup backup harian, sedangkan toko online aktif sebaiknya mem-backup database lebih sering. Yang tidak kalah penting adalah menyimpan beberapa generasi dan menyimpan satu salinan di luar server.

Apakah backup otomatis dari hosting sudah cukup?

Backup otomatis dari hosting sangat membantu, terutama untuk pemulihan cepat. Namun, untuk memenuhi aturan 3-2-1, simpan juga salinan berkala di lokasi lain yang Anda kendalikan, misalnya penyimpanan cloud atau komputer kantor.

Haruskah saya menonaktifkan xmlrpc.php?

Jika Anda tidak memakai aplikasi atau plugin yang membutuhkan XML-RPC, memblokirnya aman dan mengurangi permukaan serangan. Uji fitur yang Anda pakai setelah memblokir, karena beberapa integrasi lama masih bergantung padanya.

Langkah berikutnya

Mulailah dari tiga hal yang paling berdampak hari ini: perbarui semua plugin, aktifkan 2FA untuk setiap Administrator, dan pastikan ada backup yang tersimpan di luar server. Setelah itu, kerjakan checklist di atas satu per satu.

Jika Anda sedang mencari tempat yang lebih aman untuk situs WordPress, paket hosting kami sudah dilengkapi isolasi tiap website di bawah user Linux masing-masing, backup otomatis, SSL Let's Encrypt otomatis, dan integrasi Cloudflare. Untuk referensi teknis lebih lanjut, baca juga panduan hardening resmi WordPress.