Referrer-Policy Membatasi Data URL yang Dikirim Antar-Request

Sebuah URL dapat membawa lebih banyak informasi daripada yang dibutuhkan tujuan. Path dan query string dapat memuat identifier dokumen, istilah pencarian, state alur kerja, atau konteks lain. Ketika browser mengikuti link atau mengambil resource, aturan referrer menentukan seberapa banyak URL sumber yang dapat ikut dikirim melalui header HTTP Referer.

Referrer-Policy memberi respons aturan eksplisit untuk pengungkapan tersebut. Header ini tidak mengenkripsi URL dan tidak menghapus data yang sudah dikirim melalui jalur lain. Tugasnya lebih sempit: membatasi informasi referrer yang dikeluarkan browser untuk request berikutnya.

Policy mengatur tingkat detail yang diungkapkan

Sebuah respons dapat menetapkan:

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

Policy ini mengirim URL referrer yang lebih lengkap untuk request same-origin, hanya mengirim origin untuk request cross-origin ketika tingkat keamanan transport tidak menurun, dan menghilangkan referrer saat terjadi downgrade seperti HTTPS ke HTTP.

Untuk halaman:

https://app.example/account/orders/482?view=detail

request same-origin dapat membawa URL sumber yang lebih lengkap, sedangkan request ke origin HTTPS lain dibatasi menjadi:

Referer: https://app.example/

Tujuan masih dapat melihat origin yang memulai request, tetapi tidak menerima path dan query sumber.

Pengungkapan cross-origin perlu dibatasi secara sengaja

Data referrer sering berguna secara operasional. Analytics, deteksi abuse, dan atribusi traffic dapat bergantung padanya. Namun, mengirim URL lengkap ke setiap tujuan eksternal dapat mengungkap detail yang tidak diperlukan untuk melayani request.

Sebuah halaman dapat memuat image, font, script, endpoint analytics, widget dukungan, dan link keluar dari beberapa origin. Setiap request cross-origin merupakan batas pengungkapan potensial.

Policy yang mengurangi referrer cross-origin menjadi origin mempertahankan atribusi kasar sambil membatasi detail path. Aplikasi yang memerlukan privasi lebih kuat dapat memilih policy yang mengirim lebih sedikit informasi.

Pengaturan yang tepat mengikuti aliran data nyata, bukan sekadar memaksimalkan atau menghilangkan header pada semua kasus.

no-referrer menghilangkan header

Pilihan sederhana yang paling ketat adalah:

Referrer-Policy: no-referrer

Browser menghilangkan informasi referrer dari request yang berada di bawah policy tersebut.

Pilihan ini cocok untuk halaman yang bahkan tidak ingin mengungkap origin sumber. Dampaknya dapat memutus sistem yang secara sah memakai data referrer untuk analytics atau konteks navigasi, sehingga perubahan tetap perlu diuji pada aplikasi.

Informasi referrer tidak layak dijadikan faktor autentikasi. Header Referer yang hilang atau dipalsukan tidak boleh menghasilkan bypass keamanan. Otorisasi server tetap memerlukan kredensial dan pemeriksaan policy yang memang dirancang untuk tujuan tersebut.

same-origin mempertahankan detail di dalam satu origin

Policy lain yang berguna adalah:

Referrer-Policy: same-origin

Request same-origin dapat menerima informasi referrer, sedangkan request cross-origin tidak menerimanya.

Pola ini membuat batas pengungkapan yang jelas pada origin. Ia cocok untuk aplikasi yang memakai konteks referrer detail secara internal tetapi tidak memiliki alasan untuk mengungkap origin-nya kepada tujuan eksternal melalui header ini.

Trade-off-nya adalah atribusi cross-origin berkurang. Layanan eksternal yang mengharapkan referrer dapat melihat request tanpa informasi sumber.

origin menghapus detail path dan query

Policy origin hanya mengirim informasi scheme, host, dan port:

Referrer-Policy: origin

Untuk sumber seperti:

https://portal.example/private/report?id=739

referrer menjadi:

https://portal.example/

Pilihan ini sesuai ketika atribusi pada tingkat origin sudah cukup. Tujuan tidak menerima path dan query sumber melalui mekanisme referrer.

Namun, pengaturan ini tidak membuat data sensitif di URL menjadi aman. URL dapat muncul di browser history, log, screenshot, link yang disalin, sistem monitoring, dan kanal lain. Secret dan kredensial berumur panjang tidak seharusnya ditempatkan di URL hanya karena pengungkapan referrer sudah dibatasi.

Perilaku downgrade merupakan dimensi terpisah

Policy dengan awalan strict- mempertimbangkan downgrade transport. Request dari HTTPS ke HTTP berpindah dari transport terenkripsi dan terautentikasi ke transport yang tidak aman.

Sebagai contoh, strict-origin mengirim origin referrer ketika tingkat keamanan dipertahankan dan menghilangkannya ketika terjadi downgrade. strict-origin-when-cross-origin menggabungkan aturan downgrade tersebut dengan pengungkapan same-origin yang lebih lengkap.

Perbedaan ini penting pada situs yang masih memiliki link atau resource menuju tujuan HTTP lama. Policy dapat mencegah referrer diteruskan ke request downgrade meskipun tetap mengizinkannya pada kasus lain.

Keamanan transport dan referrer policy tetap merupakan kontrol terpisah. Menghilangkan referrer tidak membuat request HTTP menjadi rahasia.

Policy per elemen dapat mempersempit request tertentu

HTML juga menyediakan kontrol referrer pada elemen tertentu. Contohnya:

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

Satu elemen dapat memakai policy yang sesuai untuk tujuan tersebut.

Pengaturan per elemen berguna untuk alur khusus, tetapi Referrer-Policy pada tingkat respons membentuk baseline. Mengandalkan developer untuk memberi anotasi pada setiap link atau resource eksternal satu per satu membuka ruang bagi kelalaian ketika template berubah.

Rancangan praktis menetapkan default respons yang aman dan memakai pengecualian yang lebih sempit hanya ketika integrasi terdokumentasi benar-benar membutuhkannya.

Query string tetap memerlukan disiplin tersendiri

Referrer policy mengurangi satu jalur keluarnya data URL dari halaman. Hal ini tidak membenarkan penempatan access token, secret reset password, session identifier, atau data pribadi di query string.

Query sensitif masih dapat tersimpan di server, reverse proxy, browser history, sistem observability, atau URL yang disalin. Nilainya juga dapat mencapai kode aplikasi dan script pihak ketiga yang berjalan di halaman.

Ketika alur memang harus memakai one-time token di URL, aplikasi perlu meminimalkan umur dan paparannya, segera mengonsumsinya, serta tidak meneruskannya ke URL berikutnya. Referrer policy menjadi defense in depth di sekitar rancangan tersebut, bukan mekanisme utama untuk menyimpan secret.

Redirect dan resource tertanam perlu diuji

Rantai navigasi nyata jarang hanya terdiri dari satu request. Sebuah link dapat melewati beberapa redirect lintas origin sebelum mencapai tujuan akhir. Halaman juga dapat mengambil resource dari origin yang tidak terlihat dari antarmuka.

Pengujian sebaiknya mencakup redirect, link eksternal, image, script, stylesheet, iframe, alur form, dan navigasi sisi klien. Developer tools browser dapat memperlihatkan header request yang benar-benar dihasilkan policy pada deployment.

Tes server yang hanya memeriksa keberadaan header respons tidak dapat memvalidasi setiap jalur request browser. Assertion yang berguna bersifat perilaku: tujuan tidak menerima informasi referrer melebihi yang diizinkan policy.

Policy perlu konsisten pada route sensitif

Policy ketat pada halaman akun dapat kehilangan manfaat jika navigasi lebih dulu masuk ke route lain dengan policy lebih longgar sebelum menghubungi origin eksternal.

Aplikasi perlu memetakan policy terhadap sensitivitas dokumen dan perilaku navigasi. Middleware bersama dapat menyediakan baseline konsisten, sementara override khusus route tetap eksplisit dan ditinjau.

Error page memerlukan perhatian yang sama. Halaman tersebut dapat memuat path request atau konteks diagnostik dan tetap mengambil resource eksternal seperti halaman sukses.

Batasnya adalah informasi yang dibawa browser

Referrer-Policy berguna karena mengendalikan satu kanal pengungkapan browser yang spesifik. Policy dapat mempertahankan konteks same-origin yang lengkap, mengurangi data cross-origin menjadi origin, atau menghilangkan informasi referrer seluruhnya.

Header ini tidak menyaring URL, mengotorisasi request, melindungi transport HTTP, atau menghapus data dari log. Properti tersebut berada pada kontrol lain.

Deployment yang baik dimulai dari detail referrer minimum yang benar-benar diperlukan integrasi, menjaga nilai sensitif keluar dari URL jika memungkinkan, lalu menguji alur navigasi dan resource yang nyata. Hasilnya adalah permukaan pengungkapan yang lebih kecil tanpa memberi header ini tanggung jawab yang bukan miliknya.