Praktik terbaik Perujuk dan Kebijakan Perujuk

Maud Nalpas

Halaman ini menguraikan beberapa praktik terbaik untuk menetapkan Referrer-Policy dan menggunakan perujuk dalam permintaan masuk.

Ringkasan

• Kebocoran informasi lintas origin yang tidak terduga akan merusak privasi pengguna web. Kebijakan perujuk yang protektif dapat membantu.
• Pertimbangkan untuk menetapkan kebijakan perujuk strict-origin-when-cross-origin. Kebijakan ini mempertahankan sebagian besar kegunaan perujuk, sekaligus mengurangi risiko kebocoran data lintas origin.
• Jangan gunakan perujuk untuk perlindungan Pemalsuan Permintaan Lintas Situs (CSRF). Gunakan token CSRF sebagai gantinya, dan header lain sebagai lapisan keamanan tambahan.

Catatan:

• Jika Anda tidak yakin dengan perbedaan antara "situs" dan "origin", lihat Memahami "same-site" dan "same-origin".
• Header Referer tidak memiliki huruf R karena salah eja dalam spesifikasi aslinya. Header Referrer-Policy dan referrer di JavaScript dan DOM dieja dengan benar.

Dasar-Dasar Referer dan Referrer-Policy

Permintaan HTTP dapat menyertakan header Referer opsional, yang menunjukkan asal atau URL halaman web tempat permintaan dibuat. Header Referrer-Policy menentukan data yang disediakan di header Referer.

Dalam contoh berikut, header Referer menyertakan URL lengkap halaman di site-one tempat permintaan dibuat.

Permintaan HTTP dengan header Referer.

Header Referer mungkin ada dalam berbagai jenis permintaan:

• Permintaan navigasi, saat pengguna mengklik link.
• Permintaan subresource, saat browser meminta gambar, iframe, skrip, dan resource lain yang diperlukan halaman.

Untuk navigasi dan iframe, Anda juga dapat mengakses data ini dengan JavaScript menggunakan document.referrer.

Anda dapat mempelajari banyak hal dari nilai Referer. Misalnya, layanan analisis mungkin menggunakannya untuk menentukan bahwa 50% pengunjung di site-two.example berasal dari social-network.example. Namun, jika URL lengkap, termasuk jalur dan string kueri, dikirim di Referer lintas origin, hal ini dapat membahayakan privasi pengguna dan menimbulkan risiko keamanan:

Menggunakan URL lengkap dapat memengaruhi privasi dan keamanan pengguna.

URL #1 hingga #5 berisi informasi pribadi, dan terkadang informasi sensitif atau informasi identitas pribadi. Membocorkan informasi ini secara diam-diam di berbagai origin dapat membahayakan privasi pengguna web.

URL #6 adalah URL kemampuan. Jika ada orang selain pengguna yang dituju menerima ini, pihak berniat jahat dapat mengambil kendali akun pengguna ini.

Untuk membatasi data perujuk yang disediakan untuk permintaan dari situs Anda, Anda dapat menetapkan kebijakan perujuk.

Kebijakan apa yang tersedia dan apa perbedaannya?

Anda dapat memilih salah satu dari delapan kebijakan. Bergantung pada kebijakan, data yang tersedia dari header Referer (dan document.referrer) dapat berupa:

• Tidak ada data (tidak ada header Referer)
• Hanya origin
• URL lengkap: origin, jalur, dan string kueri

Contoh data Perujuk.

Beberapa kebijakan dirancang untuk berperilaku berbeda bergantung pada konteks: permintaan lintas origin atau origin yang sama, apakah tujuan permintaan sama amannya dengan origin, atau keduanya. Hal ini berguna untuk membatasi jumlah informasi yang dibagikan di seluruh origin atau ke origin yang kurang aman, sekaligus mempertahankan kekayaan perujuk dalam situs Anda sendiri.

Tabel berikut menunjukkan cara kebijakan perujuk membatasi data URL yang tersedia dari header Referer dan document.referrer:

Cakupan kebijakan	Nama kebijakan	Perujuk: Tidak ada data	Perujuk: Hanya origin	Perujuk: URL Lengkap
Tidak mempertimbangkan konteks permintaan	no-referrer	check
	origin		check
	unsafe-url			check
Berfokus pada keamanan	strict-origin	Permintaan dari HTTPS ke HTTP	Permintaan dari HTTPS ke HTTPS atau HTTP ke HTTP
	no-referrer-when-downgrade	Permintaan dari HTTPS ke HTTP		Permintaan dari HTTPS ke HTTPS atau HTTP ke HTTP
Berfokus pada privasi	origin-when-cross-origin		Permintaan lintas origin	Permintaan dari origin yang sama
	same-origin	Permintaan lintas origin		Permintaan dari origin yang sama
Berfokus pada privasi dan keamanan	strict-origin-when-cross-origin	Permintaan dari HTTPS ke HTTP	Permintaan lintas origin dari HTTPS ke HTTPS atau HTTP ke HTTP	Permintaan dari origin yang sama

MDN menyediakan daftar lengkap kebijakan dan contoh perilaku.

Berikut beberapa hal yang perlu diperhatikan saat menetapkan kebijakan perujuk:

• Semua kebijakan yang mempertimbangkan skema (HTTPS versus HTTP) (strict-origin, no-referrer-when-downgrade, dan strict-origin-when-cross-origin) memperlakukan permintaan dari satu origin HTTP ke origin HTTP lain dengan cara yang sama seperti permintaan dari origin HTTPS ke origin HTTPS lain, meskipun HTTP kurang aman. Hal ini karena untuk kebijakan ini, yang penting adalah apakah terjadi penurunan keamanan; yaitu, jika permintaan dapat mengekspos data dari origin terenkripsi ke origin yang tidak terenkripsi, seperti dalam permintaan HTTPS → HTTP. Permintaan HTTP → HTTP sepenuhnya tidak dienkripsi, sehingga tidak ada downgrade.
• Jika permintaan adalah origin yang sama, artinya skema (HTTPS atau HTTP) sama, sehingga tidak ada penurunan keamanan.

Kebijakan perujuk default di browser

Per Oktober 2021

Jika tidak ada kebijakan perujuk yang ditetapkan, browser akan menggunakan kebijakan defaultnya.

Browser	Referrer-Policy/Perilaku Default
Chrome	Defaultnya adalah strict-origin-when-cross-origin.
Firefox	Defaultnya adalah strict-origin-when-cross-origin. Mulai versi 93, bagi pengguna Fitur Anti-Pelacakan Ketat dan penjelajahan rahasia, kebijakan perujuk yang kurang ketat no-referrer-when-downgrade, origin-when-cross-origin, dan unsafe-url diabaikan untuk permintaan lintas situs, yang berarti perujuk selalu dipangkas untuk permintaan lintas situs, terlepas dari kebijakan situs.
Edge	Defaultnya adalah strict-origin-when-cross-origin.
Safari	Defaultnya mirip dengan strict-origin-when-cross-origin, dengan beberapa perbedaan spesifik. Lihat Mencegah Pelacakan Pencegahan Pelacakan untuk mengetahui detailnya.

Praktik terbaik untuk menetapkan kebijakan perujuk

Tujuan: Tetapkan kebijakan peningkatan privasi secara eksplisit, seperti strict-origin-when-cross-origin(atau yang lebih ketat).

Ada berbagai cara untuk menetapkan kebijakan perujuk untuk situs Anda:

• Sebagai header HTTP
• Dalam HTML Anda
• Dari JavaScript per permintaan

Anda dapat menetapkan kebijakan yang berbeda untuk halaman, permintaan, atau elemen yang berbeda.

Header HTTP dan elemen meta sama-sama berada di tingkat halaman. Urutan prioritas untuk menentukan kebijakan efektif elemen adalah sebagai berikut:

1. Kebijakan tingkat elemen
2. Kebijakan tingkat halaman
3. Default browser

Contoh:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Gambar diminta dengan kebijakan no-referrer-when-downgrade, dan semua permintaan subresource lainnya dari halaman ini mengikuti kebijakan strict-origin-when-cross-origin.

Bagaimana cara melihat kebijakan perujuk?

securityheaders.com berguna untuk menentukan kebijakan yang digunakan situs atau halaman tertentu.

Anda juga dapat menggunakan alat developer di Chrome, Edge, atau Firefox untuk melihat kebijakan perujuk yang digunakan untuk permintaan tertentu. Saat artikel ini ditulis, Safari tidak menampilkan header Referrer-Policy, tetapi menampilkan Referer yang dikirim.

Panel Jaringan Chrome DevTools dengan permintaan yang dipilih.

Kebijakan mana yang harus Anda tetapkan untuk situs Anda?

Sebaiknya tetapkan kebijakan peningkatan privasi secara eksplisit seperti strict-origin-when-cross-origin (atau yang lebih ketat).

Mengapa "secara eksplisit"?

Jika Anda tidak menetapkan kebijakan perujuk, kebijakan default browser akan digunakan—bahkan, situs sering kali mengikuti setelan default browser. Namun, hal ini tidak ideal karena:

• Browser yang berbeda memiliki kebijakan default yang berbeda, jadi jika Anda mengandalkan default browser, situs Anda tidak akan berperilaku seperti yang diharapkan di berbagai browser.
• Browser menerapkan default yang lebih ketat seperti strict-origin-when-cross-origin dan mekanisme seperti pemangkasan perujuk untuk permintaan lintas origin. Memilih ikut serta secara eksplisit dalam kebijakan peningkatan privasi sebelum setelan default browser berubah akan memberi Anda kontrol dan membantu Anda menjalankan pengujian sesuai keinginan Anda.

Mengapa strict-origin-when-cross-origin (atau lebih ketat)?

Anda memerlukan kebijakan yang aman, meningkatkan privasi, dan berguna. Arti "berguna" bergantung pada apa yang Anda inginkan dari perujuk:

• Secure: jika situs Anda menggunakan HTTPS (jika tidak, jadikan ini prioritas), Anda tidak ingin URL situs Anda bocor dalam permintaan non-HTTPS. Karena siapa pun di jaringan dapat melihatnya, kebocoran akan mengekspos pengguna Anda ke serangan person-in-the-middle. Kebijakan no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, dan strict-origin menyelesaikan masalah ini.
• Meningkatkan privasi: untuk permintaan lintas origin, no-referrer-when-downgrade membagikan URL lengkap, yang dapat menyebabkan masalah privasi. strict-origin-when-cross-origin dan strict-origin hanya membagikan origin, dan no-referrer tidak membagikan apa pun. Dengan demikian, Anda memiliki strict-origin-when-cross-origin, strict-origin, dan no-referrer sebagai opsi peningkatan privasi.
• Berguna: no-referrer dan strict-origin tidak pernah membagikan URL lengkap, bahkan untuk permintaan origin yang sama. Jika Anda memerlukan URL lengkap, strict-origin-when-cross-origin adalah opsi yang lebih baik.

Semua ini berarti bahwa strict-origin-when-cross-origin umumnya merupakan pilihan yang masuk akal.

Contoh: Menetapkan kebijakan strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Atau sisi server, misalnya di Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Bagaimana jika strict-origin-when-cross-origin (atau yang lebih ketat) tidak mengakomodasi semua kasus penggunaan Anda?

Dalam hal ini, lakukan pendekatan progresif: tetapkan kebijakan perlindungan seperti strict-origin-when-cross-origin untuk situs Anda dan, jika perlu, kebijakan yang lebih permisif untuk permintaan atau elemen HTML tertentu.

Contoh: Contoh: kebijakan tingkat elemen

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit mungkin membatasi document.referrer atau header Referer untuk permintaan lintas situs. Lihat detail.

Contoh: Contoh: kebijakan tingkat permintaan

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Apa lagi yang harus Anda pertimbangkan?

Kebijakan Anda harus bergantung pada situs dan kasus penggunaan, sebagaimana ditentukan oleh Anda, tim, dan perusahaan Anda. Jika beberapa URL berisi data identitas atau data sensitif, tetapkan kebijakan perlindungan.

Peringatan: Data yang mungkin tidak terlihat sensitif bagi Anda dapat bersifat sensitif bagi pengguna, atau mungkin bukan data yang mereka inginkan atau harapkan untuk bocor secara diam-diam di lintas origin.

Praktik terbaik untuk permintaan masuk

Berikut beberapa panduan tentang hal yang harus dilakukan jika situs Anda menggunakan URL perujuk dari permintaan masuk.

Melindungi data pengguna

Referer dapat berisi data pribadi, personal, atau identitas, jadi pastikan Anda memperlakukannya sebagaimana mestinya.

Perujuk masuk dapat berubah {referer-can-change}

Penggunaan perujuk dari permintaan lintas origin yang masuk memiliki beberapa batasan:

• Jika Anda tidak memiliki kontrol atas implementasi pemancar permintaan, Anda tidak dapat membuat asumsi tentang header Referer (dan document.referrer) yang Anda terima. Pemancar permintaan dapat memutuskan untuk beralih ke kebijakan no-referrer kapan saja , atau secara umum ke kebijakan yang lebih ketat daripada yang mereka gunakan sebelumnya. Artinya, Anda menerima lebih sedikit data dari Referer dibandingkan sebelumnya.
• Browser makin sering menggunakan Referrer-Policy strict-origin-when-cross-origin secara default. Artinya, Anda mungkin sekarang hanya menerima origin, bukan URL perujuk lengkap, dalam permintaan lintas origin yang masuk, jika situs pengirim tidak memiliki kebijakan yang ditetapkan.
• Browser mungkin mengubah cara mengelola Referer. Misalnya, beberapa developer browser mungkin memutuskan untuk selalu memangkas perujuk ke origin dalam permintaan subresource lintas origin, untuk melindungi privasi pengguna.
• Header Referer (dan document.referrer) mungkin berisi lebih banyak data daripada yang Anda perlukan. Misalnya, header ini mungkin memiliki URL lengkap saat Anda hanya ingin mengetahui apakah permintaan tersebut lintas origin.

Alternatif untuk Referer

Anda mungkin perlu mempertimbangkan alternatif jika:

• Fitur penting situs Anda menggunakan URL perujuk dari permintaan lintas origin yang masuk.
• Situs Anda tidak lagi menerima bagian URL perujuk yang diperlukan dalam permintaan lintas origin. Hal ini terjadi saat pemancar permintaan mengubah kebijakannya atau saat mereka tidak menetapkan kebijakan dan kebijakan default browser berubah (seperti di Chrome 85).

Untuk menentukan alternatif, analisis terlebih dahulu bagian perujuk yang Anda gunakan.

Jika Anda hanya memerlukan origin

• Jika Anda menggunakan perujuk dalam skrip yang memiliki akses tingkat teratas ke halaman, window.location.origin adalah alternatifnya.
• Jika tersedia, header seperti Origin dan Sec-Fetch-Site memberi Anda Origin atau menjelaskan apakah permintaan tersebut lintas origin, yang mungkin merupakan hal yang Anda butuhkan.

Jika Anda memerlukan elemen URL lainnya (jalur, parameter kueri…)

• Parameter permintaan mungkin mengatasi kasus penggunaan Anda, sehingga Anda tidak perlu mengurai perujuk.
• Jika Anda menggunakan perujuk dalam skrip yang memiliki akses tingkat teratas ke halaman, window.location.pathname mungkin dapat berfungsi sebagai alternatif. Ekstrak hanya bagian jalur URL dan teruskan sebagai argumen, sehingga informasi yang berpotensi sensitif dalam parameter URL tidak diteruskan.

Jika Anda tidak dapat menggunakan alternatif ini:

• Periksa apakah Anda dapat mengubah sistem untuk mengharapkan pemancar permintaan (misalnya, site-one.example) untuk secara eksplisit menetapkan informasi yang Anda perlukan dalam beberapa jenis konfigurasi.
  • Kelebihan: lebih eksplisit, lebih menjaga privasi untuk pengguna site-one.example, lebih siap menghadapi masa depan.
  • Kekurangan: berpotensi memerlukan lebih banyak pekerjaan dari pihak Anda atau untuk pengguna sistem Anda.
• Periksa apakah situs yang mengirimkan permintaan mungkin setuju untuk menetapkan Referrer-Policy per elemen atau per permintaan sebesar no-referrer-when-downgrade.
  • Kekurangan: berpotensi kurang menjaga privasi bagi pengguna site-one.example, berpotensi tidak didukung di semua browser.

Perlindungan terhadap pemalsuan permintaan lintas situs (CSRF)

Pemancar permintaan selalu dapat memutuskan untuk tidak mengirim perujuk dengan menetapkan kebijakan no-referrer, dan pihak berniat jahat bahkan dapat memalsukan perujuk.

Gunakan token CSRF sebagai perlindungan utama Anda. Untuk perlindungan ekstra, gunakan SameSite, dan bukan Referer, gunakan header seperti Origin (tersedia di permintaan POST dan CORS) dan Sec-Fetch-Site jika tersedia.

Mencatat dan men-debug

Pastikan untuk melindungi data pribadi atau sensitif pengguna yang mungkin ada di Referer.

Jika Anda hanya menggunakan origin, periksa apakah Anda dapat menggunakan header Origin sebagai alternatif. Hal ini mungkin memberi Anda informasi yang diperlukan untuk tujuan proses debug dengan cara yang lebih sederhana dan tanpa perlu mengurai perujuk.

Pembayaran

Penyedia jasa pembayaran mungkin mengandalkan header Referer dari permintaan masuk untuk pemeriksaan keamanan.

Contoh:

• Pengguna mengklik tombol Beli di online-shop.example/cart/checkout.
• online-shop.example mengalihkan ke payment-provider.example untuk mengelola transaksi.
• payment-provider.example memeriksa Referer permintaan ini berdasarkan daftar nilai Referer yang diizinkan yang disiapkan oleh penjual. Jika tidak cocok dengan entri apa pun dalam daftar, payment-provider.example akan menolak permintaan. Jika cocok, pengguna dapat melanjutkan ke transaksi.

Praktik terbaik untuk pemeriksaan keamanan alur pembayaran

Sebagai penyedia jasa pembayaran, Anda dapat menggunakan Referer sebagai pemeriksaan dasar terhadap beberapa serangan. Namun, header Referer saja bukan dasar yang dapat diandalkan untuk pemeriksaan. Situs yang meminta, baik penjual yang sah maupun tidak, dapat menetapkan kebijakan no-referrer yang membuat informasi Referer tidak tersedia bagi penyedia jasa pembayaran.

Melihat Referer mungkin dapat membantu penyedia jasa pembayaran menangkap penyerang amatir yang tidak menetapkan kebijakan no-referrer. Jika Anda menggunakan Referer sebagai pemeriksaan pertama:

• Jangan berharap Referer akan selalu ada. Jika ada, periksa header tersebut hanya berdasarkan data minimum yang dapat disertakan, yaitu origin.
  • Saat menetapkan daftar nilai Referer yang diizinkan, pastikan untuk hanya menyertakan origin dan bukan jalur.
  • Misalnya, nilai Referer yang diizinkan untuk online-shop.example harus berupa online-shop.example, bukan online-shop.example/cart/checkout. Dengan mengharapkan tidak ada Referer sama sekali atau nilai Referer yang hanya merupakan origin situs yang meminta, Anda mencegah error yang mungkin berasal dari membuat asumsi tentang Referrer-Policy penjual.
• Jika Referer tidak ada, atau jika ada dan pemeriksaan origin Referer dasar Anda berhasil, Anda dapat beralih ke metode verifikasi lain yang lebih andal.

Untuk memverifikasi pembayaran dengan lebih andal, biarkan pemohon melakukan hashing pada parameter permintaan bersama dengan kunci unik. Penyedia jasa pembayaran kemudian dapat menghitung hash yang sama di pihak Anda dan hanya menerima permintaan jika cocok dengan penghitungan Anda.

Apa yang terjadi pada Referer saat situs penjual HTTP tanpa kebijakan perujuk mengalihkan ke penyedia jasa pembayaran HTTPS?

Tidak ada Referer yang terlihat dalam permintaan ke penyedia jasa pembayaran HTTPS, karena sebagian besar browser menggunakan strict-origin-when-cross-origin atau no-referrer-when-downgrade secara default jika situs tidak memiliki kebijakan yang ditetapkan. Perubahan Chrome ke kebijakan default baru tidak akan mengubah perilaku ini.

Catatan: Jika situs Anda menggunakan HTTP, migrasikan ke HTTPS.

Kesimpulan

Kebijakan perujuk yang protektif adalah cara yang bagus untuk memberi pengguna Anda lebih banyak privasi.

Untuk mempelajari lebih lanjut berbagai teknik untuk melindungi pengguna, lihat koleksi Aman dan terlindungi kami

Resource

• Memahami "same-site" dan "same-origin"
• Header keamanan baru: Referrer Policy (2017)
• Referrer-Policy di MDN
• Header perujuk: masalah privasi dan keamanan di MDN
• Perubahan Chrome: Blink intent to implement
• Perubahan Chrome: Blink intent to ship
• Perubahan Chrome: entri status
• Perubahan Chrome: postingan blog beta 85
• Thread GitHub pemangkasan perujuk: tindakan yang dilakukan berbagai browser
• Spesifikasi Referrer-Policy

Terima kasih banyak atas kontribusi dan masukan dari semua peninjau, terutama Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck, dan Kayce Basques.