Satu Baris di wp-config.php yang Bikin Situsmu Tahan Bobol Meski Password Bocor

Kenapa Hardening Manual Masih Penting di 2026?

Kamu mungkin mikir: “Kan udah ada plugin keamanan, ngapain ribet-ribet oprek file config?” Jawabannya simpel. Plugin keamanan berjalan di level aplikasi, setelah WordPress fully loaded. Penyerang yang udah nemu celah di plugin kadaluarsa atau tema nulled bisa bypass plugin keamananmu sebelum plugin itu sempat ngeload. Hardening di level file system adalah tameng terakhir yang bekerja bahkan sebelum WordPress sempat booting.

Di artikel ini kamu bakal belajar langkah praktis hardening yang nggak butuh plugin tambahan. Semua perubahan terjadi di file config, .htaccess, dan permission Linux langsung. Ini lapisan pertahanan yang sering diabaikan bahkan oleh developer berpengalaman.

1. Pindahkan wp-config.php Satu Level di Atas Public_html

WordPress secara default menyimpan wp-config.php di root direktori instalasi. Ini lokasi yang bisa dibaca oleh PHP include() dari file manapun. Kabar baiknya: WordPress mendukung loading wp-config.php dari satu level di atas public_html. Kalau WordPressmu terinstall di /home/user/public_html/, letakkan wp-config.php di /home/user/. WordPress akan otomatis membacanya dari parent directory.

• Server Apache atau Nginx tidak bisa mengakses file di luar document root
• Bahkan jika server salah konfigurasi dan meng-output raw PHP, credentials-mu tetap aman
• Fallback: kalau WordPress nggak menemukan file di root, dia akan mencari di parent directory

Ini teknik sederhana tapi dampaknya luar biasa. Kalau situsmu pernah kena symlink attack atau path traversal, memindahkan config file satu level ke atas bisa jadi penyelamat.

2. Matikan File Editor di Dashboard WordPress

Fitur “Theme File Editor” dan “Plugin File Editor” di dashboard WordPress adalah backdoor legal. Penyerang yang berhasil login sebagai admin bisa menyisipkan kode PHP jahat langsung dari browser tanpa perlu akses FTP atau SSH. Solusinya? Satu baris di wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Taruh baris ini sebelum komentar /* That's all, stop editing! */. Setelah itu, menu editor di Appearance dan Plugins akan hilang total. Admin yang sah masih bisa mengelola file lewat SSH atau FTP, tapi penyerang yang cuma punya akses dashboard kehilangan satu vektor serangan besar.

3. Amankan Authentication Keys dan Salts

Banyak developer asal copy-paste salts dari tutorial lama. Ini kesalahan serius. Salts itu seperti garam di masakan, kalau semua orang pakai garam yang sama, rasanya mudah ditebak. Generate salts baru dari WordPress.org secret-key generator dan masukkan ke wp-config.php-mu. Jangan pakai salts yang sama lebih dari setahun. Rotasi salts secara berkala memaksa semua cookie login kadaluarsa dan membersihkan sesi yang mungkin sudah dibajak.

4. Batasi Akses wp-includes dan Direktori Sensitif

Direktori /wp-includes/ berisi file library inti WordPress. File-file ini nggak pernah diakses langsung oleh pengunjung. Tapi penyerang bisa saja mencoba me-load file di dalamnya lewat URL untuk eksploitasi. Proteksi dengan .htaccess:

# Di /wp-includes/.htaccess
<FilesMatch "\.(?i:php)$">
  Require all denied
</FilesMatch>

# Di /wp-content/uploads/.htaccess
<FilesMatch "\.(?i:php|php5|phtml|pl|py|jsp|asp|sh|cgi)$">
  Require all denied
</FilesMatch>

Blokir PHP execution di direktori uploads adalah salah satu hardening paling krusial. Penyerang sering mengunggah backdoor PHP yang disamarkan sebagai gambar. Tanpa proteksi ini, file backdoor.php yang di-rename jadi gambar.jpg.php bisa dieksekusi langsung lewat browser.

5. Set File Permissions yang Benar (Bukan 777)

Ini kesalahan paling umum di kalangan developer junior: men-set semua folder ke 777 karena “biar nggak ribet.” Permission 777 artinya siapa saja bisa membaca, menulis, dan mengeksekusi. Ini undangan terbuka untuk penyerang di shared hosting. Standar yang benar:

File / Direktori	Permission	Keterangan
Folder umum	755	Owner bisa tulis, lainnya cuma baca dan eksekusi
File PHP / statis	644	Owner bisa tulis, group & publik cuma baca
wp-config.php	600 / 440	Hanya readable oleh owner (atau owner+group)

Di server Nginx dengan PHP-FPM, pastikan PHP pool user berbeda dari user pemilik file. Ini mencegah skrip PHP yang terinfeksi dari menulis ke file WordPress lainnya. Teknik ini disebut privilege separation dan jadi salah satu lapisan pertahanan paling powerful yang jarang dibahas tutorial pemula.

6. Blokir Eksekusi PHP di wp-content

Direktori /wp-content/ seharusnya cuma berisi aset statis: gambar, CSS, JS, dan file media. Tapi struktur ini juga tempat plugin dan tema menyimpan file PHP mereka. Penyerang yang berhasil mengunggah file ke wp-content bisa mengeksekusi kode sesuka hati. Solusinya: pisahkan eksekusi PHP dari direktori uploads dan cache:

# Di /wp-content/.htaccess
<FilesMatch "\.(?i:php|php5|phtml)$">
  Require all denied
</FilesMatch>

# Kecualikan direktori plugin dan tema yang sah
# File uploads sudah dicover aturan di atas

Untuk proteksi lebih canggih, kamu bisa mengarahkan semua request ke file PHP yang tidak dikenal ke 404. Ini menjegal penyerang yang mencoba brute-force path backdoor.

7. Disable XML-RPC yang Nggak Diperlukan

XML-RPC adalah API lawas yang memungkinkan remote publishing. Tapi di tangan penyerang, XML-RPC jadi alat brute-force amplifikasi. Satu request ke xmlrpc.php bisa mencoba ratusan password sekaligus lewat metode system.multicall. Kalau kamu nggak pakai aplikasi remote publishing atau Jetpack yang bergantung penuh pada XML-RPC, matikan:

// Di wp-config.php, atau filter hook
add_filter('xmlrpc_enabled', '__return_false');

Bisa juga blokir langsung di level server Nginx atau Apache. Satu baris di konfigurasi server bisa menghentikan ribuan brute-force attempt per hari.

8. Proteksi wp-login.php dengan Rate Limiting

File wp-login.php adalah pintu masuk paling sering diserang. Bot networks bisa mencoba ribuan kombinasi username-password dalam hitungan menit. Tanpa rate limiting, password yang cukup kuat pun bisa jebol lewat brute-force yang sabar. Tools seperti fail2ban atau modul Nginx limit_req memberi perlindungan di level server yang tidak bisa di-bypass plugin manapun.

# Nginx rate limiting untuk wp-login.php
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=3r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=2 nodelay;
    # sisanya normal
}

Konfigurasi di atas membatasi maksimal 3 request per menit per IP ke halaman login. Kalau ada yang mencoba melebihi itu, Nginx langsung return 429 (Too Many Requests) tanpa menyentuh PHP sama sekali.

9. Nonaktifkan PHP Error Reporting di Production

Error messages yang muncul di layar adalah tambang informasi buat penyerang. Path absolut, versi plugin, struktur database; semua bocor dalam satu warning PHP. Matikan display errors:

// Di wp-config.php, sebelum /* That's all, stop editing! */
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true); // Log ke file, jangan ditampilkan

Dengan konfigurasi di atas, error tetap dicatat ke /wp-content/debug.log untuk kebutuhan debugging developer, tapi tidak pernah muncul di layar pengunjung. File log ini juga harus kamu proteksi dengan .htaccess atau permission ketat.

10. Verifikasi Integritas Core File Secara Berkala

Penyerang yang sudah masuk sering mengganti file core WordPress dengan versi yang sudah di-patch berisi backdoor. WordPress punya built-in mechanism untuk verifikasi integritas ini. Jalankan perintah berikut via SSH:

wp core verify-checksums

Atau bisa juga via cek manual dengan membandingkan hash file lokal terhadap checksum resmi dari WordPress.org. Kalau ada file core yang termodifikasi, segera ganti dengan versi asli dari rilis WordPress yang sama. Jangan lupa cek timestamp file juga; file core yang tanggal modifikasinya lebih baru dari file lain bisa jadi tanda backdoor.

Checklist Hardening Cepat

1. ✅ Pindahkan wp-config.php satu level di atas public_html
2. ✅ Tambahkan define('DISALLOW_FILE_EDIT', true);
3. ✅ Generate salts baru dari api.wordpress.org
4. ✅ Blokir PHP execution di /uploads/ dan /wp-includes/
5. ✅ Set folder ke 755, file ke 644, wp-config ke 600
6. ✅ Matikan XML-RPC jika tidak digunakan
7. ✅ Pasang rate limiting di wp-login.php
8. ✅ Matikan WP_DEBUG dan WP_DEBUG_DISPLAY
9. ✅ Jadwalkan cron untuk wp core verify-checksums

Baca juga artikel terkait: Situs WordPress-mu Bisa Dijebol dalam 7 Detik, Ini 7 Jalur yang Dipakai Penyerang dan Sudah Ganti URL Login WordPress? Masih Bolong Kalau 7 Lapis Ini Kamu Abaikan.

Referensi & Sumber

• WordPress.org Official Hardening Guide
• WordPress Developer Documentation: wp-config.php
• NGINX Blog: WordPress Security Tips

Kesimpulan

Hardening WordPress bukan sekadar checklist teknis, ini adalah pola pikir. Setiap baris konfigurasi, setiap permission file, setiap aturan .htaccess adalah lapisan pertahanan yang bekerja 24/7 tanpa peduli plugin keamananmu up-to-date atau tidak. Penyerang selalu mencari celah termudah. Jangan biarkan situsmu jadi target empuk karena permission 777 atau salts hasil copy-paste dari blog tahun 2018.

Kalau kamu serius mengamankan situs WordPressmu, mulailah dari fondasi. Hardening file system dan core configuration adalah langkah yang tidak bisa di-substitusi plugin apapun.

Pertanyaan yang Sering Diajukan (FAQ)

Apakah hardening wp-config.php bisa dilakukan tanpa akses SSH?

Bisa. Kamu tetap bisa melakukan sebagian besar hardening lewat FTP atau File Manager di control panel hosting. Pindahkan wp-config.php, tambahkan define('DISALLOW_FILE_EDIT', true), dan edit file .htaccess semuanya bisa dilakukan tanpa SSH. Namun untuk set permission yang tepat (terutama 600 untuk wp-config.php), akses SSH atau terminal sangat direkomendasikan.

Berapa kali salts di wp-config.php harus diperbarui?

Idealnya setiap 3-6 bulan. Rotasi salts membuat semua cookie login kadaluarsa secara paksa, menghentikan sesi yang mungkin sudah diambil alih penyerang tanpa sepengetahuanmu. Efek sampingnya: semua user termasuk kamu akan logout dan harus login ulang. Gunakan salts generator resmi dari api.wordpress.org, jangan buat manual.

Apakah mematikan XML-RPC akan merusak fitur WordPress?

Tergantung plugin yang kamu pakai. Jetpack, aplikasi WordPress mobile, dan beberapa plugin remote management bergantung pada XML-RPC. Kalau kamu tidak pakai fitur-fitur itu, XML-RPC aman dimatikan. Alternatifnya: batasi akses XML-RPC hanya ke IP tertentu lewat .htaccess atau Nginx config, daripada mematikannya total.

Kenapa permission 777 berbahaya padahal hosting-ku dedicated?

Meski di dedicated server, permission 777 tetap berbahaya karena kalau satu akun user di server yang sama terinfeksi malware, malware itu bisa membaca dan menulis ke direktori dengan permission 777. Prinsip keamanan minimal (least privilege): beri akses seminimal mungkin yang diperlukan. Tidak ada alasan valid untuk menggunakan 777 di production environment.