Referrer-Policy Mengurangi Data Referrer pada Request Keluar

Browser dapat menyertakan header request Referer ketika sebuah dokumen membuka halaman lain atau mengambil subresource. Tanpa kebijakan yang sesuai, header tersebut dapat membawa bagian URL sumber yang sebenarnya tidak diperlukan oleh tujuan. Path dapat memuat nama objek internal, detail routing, parameter kampanye, atau konteks lain yang sebaiknya tidak melewati batas kepercayaan.

Referrer-Policy memberi situs kendali atas pengungkapan tersebut. Kebijakan ini menentukan informasi referrer yang boleh disertakan browser pada request yang tercakup. Mekanisme ini tidak mengautentikasi tujuan, tidak mengenkripsi trafik, dan tidak menggantikan rancangan URL yang aman. Fungsinya lebih sempit: mengurangi data URL sumber yang dilepas browser.

Kebijakan origin-only menghapus detail path

Origin terdiri dari scheme URL, host, dan port. Kebijakan yang hanya mengirim origin menghilangkan path, query string, serta konteks lain di luar origin dari nilai referrer.

Sebagai contoh, halaman:

https://portal.example/account/invoices?view=recent

dapat menghasilkan referrer yang dipangkas menjadi:

https://portal.example/

ketika kebijakan origin-only berlaku dan referrer memang dikirim.

Pengurangan ini penting karena path dan query URL sering menampung konteks aplikasi. Walaupun data tersebut bukan kredensial, pengirimannya ke tujuan yang tidak terkait dapat membuka informasi yang tidak memiliki fungsi pada request penerima.

Header response dapat menetapkan kebijakan dokumen

Server dapat mendeklarasikan kebijakan melalui response HTTP:

Referrer-Policy: strict-origin-when-cross-origin

strict-origin-when-cross-origin mempertahankan detail lebih banyak untuk request same-origin, hanya mengirim origin untuk request HTTPS cross-origin, dan tidak mengirim referrer saat terjadi downgrade dari HTTPS ke HTTP.

Pemisahan trafik same-origin dan cross-origin cocok untuk aplikasi yang masih memerlukan konteks request lokal tetapi ingin membatasi data ke origin lain. Perilaku downgrade juga lebih konservatif karena URL HTTPS tidak diteruskan sebagai referrer melalui request HTTP yang tidak aman.

no-referrer menghilangkan nilai referrer

Deployment yang lebih ketat dapat memakai:

Referrer-Policy: no-referrer

Dengan no-referrer, browser tidak mengirim informasi referrer untuk request yang diatur oleh kebijakan tersebut. Pilihan ini sesuai untuk halaman yang tidak memperoleh manfaat operasional dari pengungkapan lokasi sumber.

Konsekuensinya bersifat fungsional, bukan kriptografis. Analytics, diagnostik, sistem anti-abuse, atau logika aplikasi mungkin memakai data referrer sebagai salah satu sinyal. Menghapusnya dapat mengurangi sinyal itu. Sistem tersebut sejak awal tidak semestinya memperlakukan header Referer sebagai bukti identitas atau otorisasi, karena metadata request bukan kredensial autentikasi.

same-origin menahan data referrer di dalam origin

Kebijakan same-origin mengirim informasi referrer untuk request same-origin dan menghilangkannya untuk request cross-origin:

Referrer-Policy: same-origin

Batas ini cocok bagi aplikasi yang membutuhkan konteks navigasi internal tetapi tidak ingin data referrer keluar dari origin. Antarmuka administratif, area akun, atau aplikasi dengan tautan eksternal yang tidak memerlukan konteks sumber dapat memakai pola tersebut.

Batasnya berbasis origin, bukan organisasi. Dua subdomain seperti app.example.com dan docs.example.com tetap merupakan origin berbeda walaupun dikelola operator yang sama.

Kebijakan juga dapat dipasang pada elemen tertentu

HTML menyediakan atribut referrerpolicy pada sejumlah elemen yang memulai request. Sebuah tautan dapat memakai kebijakan yang lebih sempit daripada default dokumen:

<a href="https://external.example/report"
   referrerpolicy="no-referrer">
  Laporan eksternal
</a>

Gambar juga dapat memiliki kebijakan sendiri:

<img src="https://cdn.example/image.png"
     referrerpolicy="no-referrer"
     alt="Diagram">

Kebijakan per elemen berguna ketika satu request memiliki batas pengungkapan yang berbeda. Header tingkat dokumen tetap lebih mudah diaudit sebagai baseline karena cakupannya tidak bergantung pada setiap pembuat template untuk memasang atribut lokal.

Redirect membuat jalur pengungkapan akhir kurang terlihat

Navigasi keluar dapat melewati beberapa redirect sebelum mencapai tujuan akhir. Pemrosesan referrer mengikuti aturan browser pada transisi tersebut, sehingga pemilihan kebijakan perlu mempertimbangkan seluruh jalur request, bukan hanya URL pertama yang terlihat pada markup.

Hal ini relevan untuk link tracker, alur identitas, dan layanan eksternal yang melakukan redirect lanjutan. Kebijakan sumber yang restriktif membatasi data yang tersedia sejak request awal dan mengurangi detail URL sumber yang dapat terbawa ke tahap berikutnya.

Perilaku redirect tidak menjadikan referrer policy sebagai pengganti aturan untuk menjauhkan rahasia dari URL. Token sensitif dalam query string masih dapat muncul pada log, riwayat browser, screenshot, tautan yang disalin, dan kanal lain yang tidak bergantung pada header Referer.

Desain URL tetap menjadi kontrol keamanan terpisah

Kebijakan ini mengurangi satu mekanisme pengungkapan. Kebijakan tersebut tidak dapat mengubah URL sensitif menjadi aman.

Identifier sesi, kredensial reset password, API key, dan rahasia sejenis tidak seharusnya ditempatkan dalam URL biasa hanya karena referrer policy yang ketat sudah aktif. Kebijakan dapat berubah, tidak terpasang pada route lain, dipengaruhi konteks embedding, atau tidak relevan terhadap kanal pengungkapan di luar pemrosesan referrer.

Desain yang lebih aman meminimalkan material sensitif di URL, kemudian memakai Referrer-Policy sebagai defense in depth. Kedua kontrol menangani kelas kegagalan yang berbeda.

Uji perilaku browser yang benar-benar berlaku

Header konfigurasi hanya berguna jika sampai ke response yang dituju dengan nilai yang tepat. Reverse proxy, framework aplikasi, aturan static hosting, dan middleware khusus route dapat menghasilkan header berbeda di berbagai bagian situs.

Pengujian sebaiknya mencakup request same-origin, request cross-origin, kasus downgrade HTTPS ke HTTP bila tujuan seperti itu ada, redirect, serta override pada elemen. Developer tools browser atau endpoint penerima yang dikendalikan dapat menunjukkan nilai Referer yang benar-benar diterima.

Kondisi akhirnya adalah batas pengungkapan yang disengaja: konteks referrer cukup untuk kebutuhan aplikasi yang sah, tanpa mengirim detail URL sumber melebihi kebutuhan tujuan.