Aturan Keamanan .htaccess WordPress yang Benar-Benar Berguna

Kebanyakan yang dijual sebagai “keamanan .htaccess WordPress” itu cuma pemanis. Aturan yang benar-benar mengubah attack surface Anda sebenarnya pendek: blokir eksekusi PHP di dalam wp-content/uploads, tolak akses langsung ke wp-config.php, dan matikan directory indexing. Yang populer — memblokir xmlrpc.php “untuk menghentikan brute force”, menyembunyikan versi WordPress Anda, menempelkan daftar user-agent bad-bot sepanjang 200 baris — berkisar dari nyaris tak berguna sampai murni pura-pura. Di bawah ini mana yang mana, dan alasannya.

Satu hal yang perlu diluruskan dulu: .htaccess hanya berfungsi di Apache (dan LiteSpeed, yang juga membacanya). Di nginx file ini diabaikan sepenuhnya — file-nya cuma nangkring di sana sementara Anda merasa sudah terlindungi. Kalau hosting Anda menjalankan nginx, semua ini tidak berlaku dan Anda butuh blok server/location sebagai gantinya. Cek dengan curl -I https://yoursite.com dan lihat header Server: sebelum Anda menghabiskan satu jam mengedit file yang tidak pernah dibaca server.

Aturan yang benar-benar penting: tidak ada PHP di /uploads

Ini yang layak dikerjakan. wp-content/uploads memang dibuat world-writable — setiap upload media, setiap plugin yang menyimpan file, menulis ke sana. Kalau penyerang berhasil menaruh file .php ke direktori itu (lewat upload handler yang rentan, field gambar yang tidak memvalidasi MIME type, plugin yang sudah disusupi), beda antara sekadar gangguan dan kompromi remote-code-execution penuh terletak pada apakah server akan mengeksekusi file itu saat diminta. Tolak eksekusinya dan payload yang diupload cuma jadi file mati yang tergeletak di disk.

Taruh ini ke dalam wp-content/uploads/.htaccess (buat file-nya kalau belum ada):

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

Itu sintaks Apache 2.4. Di versi 2.2 yang lebih lama, padanannya adalah Order Deny,Allow / Deny from all. Mencampur dua dialek dalam satu file adalah penyebab paling umum 500 Internal Server Error yang tiba-tiba muncul setelah “hardening” — kalau seluruh situs mati begitu Anda menyimpan, hampir pasti itu penyebabnya. Cek versi Anda dengan apachectl -v.

Lindungi wp-config.php

wp-config.php menyimpan kredensial database dan auth salts Anda. Selama PHP berjalan, permintaan langsung ke file itu mengembalikan halaman kosong — PHP mengeksekusi file-nya, bukan mencetaknya. Risikonya ada di kasus gagal: kalau PHP crash, salah konfigurasi saat migrasi, atau handler-nya dinonaktifkan, Apache menyajikan file itu sebagai plaintext dan menumpahkan password DB Anda ke siapa pun yang minta. Menolak akses adalah asuransi murah untuk lima menit buruk:

<Files wp-config.php>
    Require all denied
</Files>

Matikan directory indexing

Kalau seseorang mengunjungi folder yang tidak ada index.php-nya dan Apache punya Options +Indexes aktif, ia akan menampilkan isinya — setiap file backup, setiap dump SQL nyasar yang Anda lupa. Matikan untuk seluruh situs:

Options -Indexes

Tingkat keparahannya rendah, tapi nyata, dan gratis.

Itu daftar inti yang jujur. Anda bisa menyusun semua ini — plus sintaks 2.4-vs-2.2 yang benar supaya situs Anda tidak 500 — dengan WordPress .htaccess generator alih-alih copy-paste dari postingan forum yang ditulis untuk versi Apache yang salah.

Yang JANGAN dilakukan

Memblokir xmlrpc.php “untuk proteksi brute-force”. Ini yang paling sering diulang semua orang dan salah seperti yang dinyatakan. Ya, metode system.multicall di XML-RPC dulunya memang memungkinkan penyerang membundel banyak tebakan login dalam satu permintaan — amplifikasi nyata. Tapi vektor brute-force yang paling umum adalah permintaan POST biasa ke wp-login.php, dan memblokir xmlrpc.php sama sekali tidak berpengaruh untuk itu. Brute force dikalahkan dengan rate limiting, password kuat, dan 2FA — bukan dengan mematikan satu endpoint. Ada alasan sah untuk menonaktifkan XML-RPC: fitur pingback-nya bisa disalahgunakan untuk refleksi DDoS, jadi kalau Anda tidak memakai Jetpack, aplikasi mobile, atau pingback, menutupnya memperkecil attack surface Anda. Cuma jangan membohongi diri sendiri bahwa itu pertahanan brute-force Anda, karena bukan.

Menyembunyikan versi WordPress Anda / menghapus tag generator. Membuang readme.html dan tag <meta name="generator"> terasa seperti hardening. Penyerang bisa memfingerprint versi Anda dari query string aset yang di-enqueue, markup block-editor, dan selusin petunjuk lain dalam hitungan detik. Anda tidak menyembunyikan apa pun; Anda cuma membuat diri sendiri terlihat sibuk.

Blocklist user-agent dan referrer bad-bot raksasa. User agent cuma satu header HTTP yang bisa dipalsukan. Daftar ini sudah basi di hari Anda menempelkannya, tidak memblokir apa pun yang kompeten, dan Apache mengevaluasi setiap regex di setiap permintaan — Anda membayar pajak performa nyata demi nol keamanan. Lewati saja.

Mengunci wp-login.php berdasarkan IP. Bagus sampai ISP Anda merotasi alamat Anda dan Anda mengunci diri sendiri dari admin Anda sendiri. Cuma layak dipakai dengan IP yang benar-benar statis.

Redirect anti author-enumeration (?author=1). Rewrite .htaccess yang orang tempelkan untuk ini tidak lengkap kalau berdiri sendiri — endpoint REST /wp-json/wp/v2/users tetap menampilkan username. Memblokir satu jalur sementara jalur lain tetap terbuka itu cuma pura-pura.

Masih mentok?

Kalau sebuah aturan membuat situs 500, itu masalah sintaks — cabut blok terakhir yang Anda tambahkan lalu reload; itu langsung mengisolasinya. Kalau sebuah aturan sepertinya tidak berpengaruh, pastikan Anda memang di Apache dan AllowOverride diaktifkan untuk direktori itu (banyak managed host membatasinya). Bangun file-nya dari template yang sudah pasti benar dengan .htaccess generator, pertahankan tiga aturan yang penting, dan buang sisanya.