Cara Menguji Redirect WordPress Berbasis Referrer dengan Aman

Homepage terlihat normal dan membuka halaman yang benar jika alamat diketik langsung. Namun setelah seseorang mengeklik hasil Google atau tautan dari jejaring sosial, browser tiba-tiba berpindah ke situs obat, kasino, unduhan, atau halaman phishing. Perbedaan itu bukan bukti bahwa browser “salah”; kondisi permintaan dapat memicu aturan redirect yang tidak berjalan pada kunjungan langsung.

Jawaban singkat: jangan mereproduksi masalah dengan mengarahkan pengunjung ke tujuan berbahaya. Simpan bukti, buat salinan staging yang tidak dapat diakses publik, lalu bandingkan respons URL yang sama dengan header Referer terkendali dan tanpa header tersebut. Catat status HTTP serta header Location tanpa otomatis membuka tujuan. Setelah itu telusuri aturan pada CDN, server, WordPress, database, dan JavaScript sampai sumber serta persistence-nya ditemukan.

Mengapa redirect hanya muncul dari referrer tertentu?

Header Referer memberi server petunjuk halaman yang mengirim permintaan. Implementasi yang sah dapat memakai asal ini untuk analitik atau alur kampanye, tetapi kode berbahaya juga dapat memakai referrer, user-agent, perangkat, cookie, atau kombinasi kondisi untuk menyembunyikan redirect. Google menjelaskan bahwa redirect dari situs yang diretas dapat hanya terjadi pada sebagian pengguna—misalnya berdasarkan referrer, user-agent, atau perangkat—sehingga pemilik yang membuka URL secara langsung mungkin tidak melihat perilaku yang sama (Google Search spam policies).

Karena itu, tes satu kali dari browser administrator tidak cukup untuk menyatakan situs bersih. Cache, sesi login, geolokasi, plugin, CDN, dan JavaScript dapat mengubah hasil. Sebaliknya, satu pengalihan yang tidak biasa juga belum otomatis membuktikan ada peretasan; plugin marketing, shortlink, atau aturan bisnis yang disetujui bisa memang membuat alur tertentu. Anda harus membuktikan asal aturan, bukan menebak dari tampilannya.

Amankan pengujian sebelum mereproduksi masalah

1. Jangan memakai komputer kerja utama atau akun administrator yang sedang login. Catat URL awal, waktu, jaringan, browser, dan apa yang dilaporkan pengunjung. Jangan memasukkan kredensial atau data pembayaran ke halaman tujuan.
2. Jangan mengklik ulang tautan dari hasil pencarian secara terbuka. Simpan URL sebagai teks. Matikan otomatisasi yang mengikuti redirect; jangan gunakan opsi -L pada curl untuk permintaan pertama.
3. Hubungi hosting atau tim keamanan bila situs melayani transaksi atau data sensitif. Minta salinan snapshot dan log sebelum pembersihan, aturan isolasi, serta persetujuan untuk melakukan pengujian. Jika tujuan akhir berbahaya, minta provider membantu menahan traffic tanpa menghapus bukti.
4. Gunakan staging privat atau salinan lokal yang tidak dapat mengirim email, menerima pembayaran, atau menghubungi integrasi produksi. Batasi aksesnya dan pastikan konfigurasi DNS/host tidak mengarahkan pengunjung umum ke salinan itu.
5. Simpan bukti secara aman. Catat hash file, nama file, waktu modifikasi, response code, Location, request ID CDN, dan potongan log yang relevan. Jangan mengunggah log berisi token, cookie, alamat IP, atau data pelanggan ke forum publik.

Jika tujuan akhirnya adalah domain asing, tidak perlu membuka halaman tersebut untuk membuktikan redirect. Status 3xx dan nilai Location dari respons awal sudah membantu menunjukkan alur. Untuk keamanan, gunakan domain uji milik Anda sendiri pada staging, bukan alamat tujuan penyerang.

Buat matriks uji yang terkendali

Tentukan satu halaman dan satu waktu uji, lalu ubah hanya satu variabel setiap kali. Pada staging, bandingkan permintaan tanpa referrer, referrer dari domain internal yang Anda kendalikan, dan satu referrer aman lain milik organisasi. Gunakan pola seperti berikut dengan host staging sendiri:

curl --max-redirs 0 -sS -D - -o /dev/null \
  -H 'Referer: https://staging.example.test/source/' \
  'https://staging.example.test/landing-page/'

Perintah tersebut meminta header respons tanpa mengikuti tujuan redirect. Jalankan juga tanpa opsi -H sebagai pembanding. Jangan mengganti contoh dengan URL pengunjung atau mengarahkan tes ke situs yang dicurigai sebagai pelaku. Jika pemeriksaan memerlukan browser, gunakan profil sementara tanpa sesi login, matikan ekstensi yang tidak perlu, buka DevTools Network, dan aktifkan “Preserve log”; hentikan navigasi jika browser akan menuju domain yang tidak dikenal.

Buat tabel sederhana berisi: URL yang diuji, apakah ada Referer, kelas perangkat/browser, status, nilai Location yang sudah disamarkan bila perlu, dan sumber log. Uji satu variabel per baris—misalnya path dengan dan tanpa garis miring akhir, query string, cookie anonim, mobile versus desktop, atau cache hit versus bypass cache yang disetujui. Jangan meniru user-agent crawler Google untuk mengelabui sistem atau menguji domain pihak lain. Jika kasus tampak khusus mesin pencari, gunakan laporan dan sampel yang tersedia di Search Console serta koordinasikan pengujian aman dengan hosting.

Pastikan waktu antarpermintaan cukup dekat agar perubahan cache atau deploy tidak membingungkan perbandingan. Ulangi setiap pasangan minimal dua kali di salinan yang sama. Jika hasil berbeda tanpa variabel yang jelas, simpan log dan periksa cache/CDN sebelum menambah lebih banyak variasi.

Telusuri lapisan yang benar-benar menghasilkan respons

1. Bedakan redirect HTTP dari perubahan di browser

Pada respons pertama, periksa apakah server mengirim status 301, 302, 303, 307, atau 308 beserta header Location. Jika tidak ada, tetapi browser tetap berpindah, periksa HTML, JavaScript, service worker, tag manager, dan skrip pihak ketiga. Jangan langsung mengubah aturan .htaccess: masalah dapat berada di CDN, Nginx, plugin, theme, database, atau kode frontend.

Bandingkan log edge/CDN dengan access log origin untuk request ID dan waktu yang sama. Jika redirect hanya terlihat di edge, periksa Worker, page rule, cache, atau konfigurasi transformasi pada layanan tersebut. Jika origin mengembalikan redirect, identifikasi route dan komponen WordPress yang menerima request. Simpan salinan aturan .htaccess, konfigurasi virtual host, dan file konfigurasi PHP sebelum mengeditnya.

2. Periksa kode WordPress tanpa menjalankan penghapusan massal

Tinjau plugin aktif, must-use plugins, theme aktif, file drop-in seperti advanced-cache.php, serta perubahan yang baru saja dilakukan. Cari hook dan pemanggilan redirect yang berkaitan dengan template_redirect, wp_redirect, wp_safe_redirect, HTTP_REFERER, HTTP_USER_AGENT, $_SERVER, atau domain tujuan. Pemeriksaan teks bukan bukti tunggal: string bisa dikodekan, dibangun dari database, atau dibentuk oleh file lain.

Gunakan wp core verify-checksums untuk membandingkan file inti WordPress yang sesuai versi dengan checksum resmi; verifikasi checksum tidak memeriksa semua plugin, theme, uploads, atau database. Untuk plugin dari direktori WordPress.org, wp plugin verify-checksums --all dapat membantu menemukan perubahan pada file plugin, tetapi plugin premium atau custom mungkin tidak memiliki checksum publik. Simpan output dan verifikasi versi sebelum mengganti file. Lihat dokumentasi WP-CLI core checksums dan plugin checksums.

Untuk WordPress, redirect aman ke URL lokal sebaiknya menggunakan wp_safe_redirect() lalu menghentikan eksekusi dengan exit; fungsi ini memvalidasi host tujuan terhadap host yang diizinkan (referensi wp_safe_redirect dan wp_validate_redirect). Ini adalah panduan bagi pemilik dan pengembang saat memperbaiki kode, bukan izin untuk menyalin potongan kode yang tidak dipahami ke situs produksi. Jika bisnis memang harus mengarahkan ke host eksternal, gunakan allowlist yang dikelola, validasi input, dan review kode; jangan mempercayai nilai Referer atau parameter redirect dari request.

3. Periksa data, cron, akun, dan akses

Pada salinan yang telah diisolasi, tinjau opsi, widget, custom HTML, konten halaman, skrip tema, jadwal cron, akun administrator, application password, serta pengaturan integrasi. Cari domain yang tidak dikenal, perubahan redirect baru, dan task yang memanggil fungsi yang tidak disetujui. Catat siapa yang memiliki akses hosting, CDN, DNS, akun registrar, dan Search Console. Menghapus plugin atau file tanpa mengetahui jalur masuk dapat membuat aturan kembali dibuat oleh akun, task, atau komponen persistence lain.

Jangan memasukkan string seperti HTTP_REFERER ke query publik yang merusak serialisasi data. Buat backup database, gunakan alat pembaca/backup resmi, dan minta bantuan bila belum nyaman memeriksa opsi serialized. Perubahan di database produksi harus mengikuti prosedur perubahan yang dapat dibalik dan diuji.

Perbaiki sumber, kemudian verifikasi dari beberapa sudut

Setelah bukti disimpan, tutup jalur masuk dan persistence. Cabut akun, token, application password, sesi, atau akses pihak ketiga yang tidak dikenal setelah memastikan akun pemilik sah tetap bisa masuk. Perbarui WordPress, plugin, theme, server runtime, dan integrasi dari sumber resmi; ganti komponen yang sudah tidak didukung. Pulihkan file/database dari backup yang diketahui bersih atau bersihkan perubahan dengan pemeriksaan menyeluruh. Jangan sekadar menghapus baris Location jika kode yang menyisipkannya masih berjalan.

Setelah perbaikan di staging, ulangi matriks yang sama. Pastikan respons tidak lagi berubah hanya karena referrer, tidak mengirim header ke host asing, dan halaman tetap berfungsi untuk sumber trafik yang sah. Purge cache hanya setelah aturan berbahaya diperbaiki; kalau menghapus cache lebih dulu, gejalanya bisa hilang sementara tanpa menghilangkan penyebab.

Pada produksi, uji menggunakan tautan internal yang aman dan browser privat, dengan persetujuan tim. Pantau log edge serta origin untuk kemunculan ulang, cek URL sampel Search Console, dan pastikan tidak ada halaman spam tersembunyi. Google menyarankan pemilik memantau log; pola URL atau traffic yang terkait redirect dapat menjadi petunjuk penyalahgunaan (pencegahan malware untuk pemilik situs). Jika terdapat notifikasi keamanan, minta review hanya setelah seluruh masalah dan penyebabnya diperbaiki. Panduan pemulihan hacked content juga dibahas di artikel website WordPress kena hack dan tanda website terkena malware.

Kesalahan yang membuat tes berbahaya atau tidak meyakinkan

• Menguji hanya dari browser administrator yang login, lalu menyimpulkan masalah selesai karena halaman terlihat normal.
• Membiarkan curl -L atau browser membuka tujuan asing; bukti redirect cukup dari respons pertama.
• Menghapus .htaccess, plugin, atau file yang tampak mencurigakan sebelum menyalin bukti dan memeriksa kepemilikannya.
• Menganggap Google atau media sosial sebagai satu-satunya referrer. Penyerang dapat memilih kondisi lain, sementara cache atau layanan proxy dapat mengubah request.
• Memasang scanner lalu langsung percaya laporan “bersih”; scanner tidak selalu melihat kode database, akun, aturan edge, atau persistence.
• Mengajukan review Search Console sebelum akar masalah selesai, atau mengirim permintaan berulang sebagai cara debugging.
• Menempel konfigurasi Apache ke server Nginx atau sebaliknya tanpa memahami lingkungan host.

Checklist penutupan insiden

Sebelum mengembalikan trafik penuh, pastikan ada pemilik tugas dan bukti untuk setiap butir: snapshot awal tersimpan; host/CDN/DNS dan plugin yang diperiksa tercatat; kondisi pemicu redirect diketahui; aturan berbahaya dihapus atau komponen diganti; celah awal diperbaiki; kredensial dan sesi berisiko dicabut; cache diperbarui dengan aman; URL sampel dan halaman terkait lolos uji terkendali; monitor log serta pemilik eskalasi ditetapkan. Bila salah satu syarat belum jelas, minta bantuan hosting atau profesional keamanan sebelum membuka kembali halaman berisiko.

Apakah saya perlu mengirim referrer Google untuk membuktikan redirect? Tidak di situs produksi. Google menjelaskan bahwa redirect berbahaya dapat bergantung pada referrer, tetapi membuka tujuan asing berisiko. Gunakan staging terisolasi, sampel laporan resmi, dan koordinasi dengan provider.

Apakah header Referer saja bisa membuktikan malware? Tidak. Header itu hanya satu variabel. Bukti perlu dikaitkan dengan log, aturan kode, data, dan konfigurasi yang tidak disetujui.

Bolehkah menghapus semua redirect di WordPress? Jangan. Redirect bisnis dan login bisa sah. Identifikasi owner dan tujuan aturan, simpan konfigurasi awal, lalu ubah hanya aturan yang terbukti salah atau berbahaya.

Kapan harus eskalasi? Eskalasi segera jika pelanggan terpapar phishing, redirect terjadi di pembayaran/login, akses pemilik hilang, ada indikasi pencurian data, atau Anda tidak dapat mempertahankan situs uji agar terisolasi.

Jika redirect mencurigakan memengaruhi pengunjung atau transaksi, jangan menebak-nebak aturan server. Minta bantuan pemulihan WordPress darurat untuk menahan risiko, mengumpulkan bukti, dan memetakan sumber sebelum perubahan produksi dilakukan.