Praktik terbaik Perujuk dan Kebijakan Perujuk

Maud Nalpas

Halaman ini menguraikan beberapa praktik terbaik untuk menetapkan Kebijakan Perujuk dan menggunakan perujuk dalam permintaan masuk.

Ringkasan

• Kebocoran informasi lintas asal yang tidak terduga dapat merusak privasi pengguna web. Kebijakan perujuk perlindungan dapat membantu.
• Sebaiknya tetapkan kebijakan perujuk strict-origin-when-cross-origin. Solusi ini mempertahankan sebagian besar kegunaan perujuk, sekaligus mengurangi risiko kebocoran data lintas asal.
• Jangan gunakan perujuk untuk perlindungan Pemalsuan Permintaan Lintas Situs (CSRF). Sebagai gantinya, gunakan token CSRF, dan header lainnya sebagai lapisan keamanan ekstra.

Catatan:

• Jika Anda tidak yakin dengan perbedaan antara "situs" dan "origin", lihat Memahami "situs yang sama" dan "origin yang sama".
• Header Referer tidak memiliki R karena ada kesalahan ejaan dalam spesifikasi asli. Header Referrer-Policy dan referrer di JavaScript serta DOM dieja dengan benar.

101 Kebijakan Perujuk dan Perujuk

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

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

Permintaan HTTP dengan header Perujuk.

Header Referer mungkin ada di 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 belajar banyak 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 di seluruh origin, hal tersebut dapat membahayakan privasi pengguna dan menimbulkan risiko keamanan:

Menggunakan URL lengkap dapat memengaruhi privasi dan keamanan pengguna.

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

URL #6 adalah URL kemampuan. Jika ada orang selain pengguna yang dituju menerima pesan ini, pelaku kejahatan dapat mengambil kendali akun pengguna ini.

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

Kebijakan apa yang tersedia dan bagaimana perbedaannya?

Anda dapat memilih salah satu dari delapan kebijakan. Bergantung pada kebijakannya, 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 konteksnya: permintaan lintas origin atau origin yang sama, apakah tujuan permintaan sama amannya dengan asal, atau keduanya. Hal ini berguna untuk membatasi jumlah informasi yang dibagikan di seluruh origin atau ke origin yang kurang aman, sambil mempertahankan kekayaan perujuk dalam situs Anda sendiri.

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

Cakupan kebijakan	Nama kebijakan	Perujuk: Tidak ada data	Perujuk: Hanya origin	Perujuk: URL lengkap
Tidak mempertimbangkan konteks permintaan	no-referrer	centang
	origin		centang
	unsafe-url			centang
Berfokus pada keamanan	strict-origin	Meminta dari HTTPS ke HTTP	Meminta dari HTTPS ke HTTPS atau HTTP ke HTTP
	no-referrer-when-downgrade	Meminta dari HTTPS ke HTTP		Meminta 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	Meminta 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 diketahui 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 asal HTTP lainnya 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 downgrade keamanan dilakukan atau tidak; yaitu, jika permintaan dapat mengekspos data dari origin yang dienkripsi ke origin yang tidak dienkripsi, seperti di permintaan HTTPS → HTTP. Permintaan HTTP → HTTP sama sekali tidak dienkripsi, sehingga tidak ada downgrade.
• Jika permintaan adalah origin yang sama, ini berarti skemanya (HTTPS atau HTTP) sama, sehingga tidak ada downgrade 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 dari versi 93, bagi pengguna Strict Tracking Protection dan Private Browsing, 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 tertentu. Lihat Mencegah Pelacakan Pencegahan Pelacakan untuk detailnya.

Praktik terbaik untuk menetapkan kebijakan perujuk

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

Ada berbagai cara untuk menetapkan kebijakan perujuk untuk situs Anda:

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

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

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

1. Kebijakan level 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" />

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

Bagaimana cara melihat kebijakan perujuk?

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

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

Panel Jaringan di Chrome DevTools dengan permintaan dipilih.

Kebijakan mana yang harus ditetapkan untuk situs Anda?

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

Mengapa "secara eksplisit"?

Jika Anda tidak menetapkan kebijakan perujuk, kebijakan default browser akan digunakan—kenyataannya, situs sering kali menunda ke default browser. Namun, ini tidak ideal karena:

• Browser yang berbeda memiliki kebijakan default yang berbeda pula, jadi jika Anda mengandalkan default browser, situs Anda tidak akan dapat diprediksi di seluruh browser.
• Browser mengadopsi default yang lebih ketat seperti strict-origin-when-cross-origin dan mekanisme seperti pemangkasan perujuk untuk permintaan lintas origin. Memilih untuk menerapkan kebijakan peningkatan privasi secara eksplisit sebelum perubahan default browser memberi Anda kontrol dan membantu Anda menjalankan pengujian sesuai kebutuhan.

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

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

• Aman: jika situs Anda menggunakan HTTPS (jika tidak, jadikan prioritas), Anda tidak ingin URL situs Anda mengalami kebocoran dalam permintaan non-HTTPS. Karena siapa pun di jaringan dapat melihatnya, kebocoran akan memaparkan pengguna Anda pada serangan person-in-the-middle. Kebijakan no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, dan strict-origin mengatasi masalah ini.
• Peningkatan 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 berbagi origin, dan no-referrer tidak berbagi sama sekali. 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: 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 detailnya.

Contoh: kebijakan tingkat permintaan

script.js:

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

Hal apa lagi yang harus Anda pertimbangkan?

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

Peringatan: Data yang mungkin tidak tampak sensitif bagi Anda dapat dianggap sensitif bagi pengguna, atau bisa juga bukan data yang mereka inginkan atau harapkan untuk membocorkan lintas origin secara diam-diam.

Praktik terbaik untuk permintaan masuk

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

Melindungi data pengguna

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

Perujuk yang masuk dapat mengubah {referer-can-change}

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

• Jika tidak memiliki kontrol atas implementasi pengirim permintaan, Anda tidak dapat membuat asumsi tentang header Referer (dan document.referrer) yang diterima. Pemancar permintaan dapat memutuskan untuk beralih ke kebijakan no-referrer kapan saja , atau lebih umum ke kebijakan yang lebih ketat daripada yang mereka gunakan sebelumnya. Ini berarti Anda menerima lebih sedikit data dari Referer daripada sebelumnya.
• Makin banyak browser menggunakan Referrer-Policy strict-origin-when-cross-origin secara default. Artinya, sekarang Anda mungkin hanya menerima origin, bukan URL perujuk lengkap, dalam permintaan lintas origin yang masuk, jika situs pengirim belum menetapkan kebijakan.
• 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 butuhkan. Misalnya, permintaan tersebut mungkin memiliki URL lengkap ketika Anda hanya ingin mengetahui apakah permintaan tersebut lintas asal.

Alternatif untuk Referer

Anda mungkin perlu mempertimbangkan alternatifnya jika:

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

Untuk menentukan alternatif, pertama-tama analisis bagian mana dari perujuk yang Anda gunakan.

Jika Anda hanya memerlukan origin

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

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

• Parameter permintaan dapat menangani kasus penggunaan Anda, sehingga Anda tidak perlu lagi mengurai perujuk.
• Jika Anda menggunakan perujuk dalam skrip yang memiliki akses tingkat atas ke halaman, window.location.pathname dapat berfungsi sebagai alternatif. Hanya ekstrak bagian jalur URL dan teruskan sebagai argumen, sehingga informasi apa pun yang berpotensi sensitif dalam parameter URL tidak diteruskan.

Jika Anda tidak dapat menggunakan alternatif berikut:

• Periksa apakah Anda dapat mengubah sistem agar mengharapkan emitor permintaan (misalnya, site-one.example) untuk menetapkan informasi yang diperlukan secara eksplisit dalam beberapa jenis konfigurasi.
  • Pro: lebih eksplisit, lebih menjaga privasi bagi pengguna site-one.example, lebih siap menghadapi masa depan.
  • Kontra: berpotensi lebih banyak pekerjaan dari pihak Anda atau untuk pengguna sistem Anda.
• Periksa apakah situs yang memunculkan permintaan mungkin menyetujui untuk menetapkan Kebijakan Perujuk per elemen atau per permintaan no-referrer-when-downgrade.
  • Kontra: berpotensi kurang menjaga privasi untuk pengguna site-one.example, kemungkinan tidak didukung di semua browser.

Perlindungan Pemalsuan Permintaan Lintas Situs (CSRF)

Pengirim permintaan selalu dapat memutuskan untuk tidak mengirim perujuk dengan menetapkan kebijakan no-referrer, dan pelaku kejahatan bahkan dapat melakukan spoofing pada perujuk.

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

Membuat log dan melakukan 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 dapat memberi Anda informasi yang diperlukan untuk tujuan proses debug dengan cara yang lebih sederhana dan tanpa perlu mengurai perujuk.

Pembayaran

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

Contoh:

• Pengguna mengklik tombol Beli pada 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 tersebut. Jika cocok, pengguna dapat melanjutkan ke transaksi.

Praktik terbaik untuk pemeriksaan keamanan alur pembayaran

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

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

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

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

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

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

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

Kesimpulan

Kebijakan perujuk perlindungan adalah cara yang bagus untuk memberikan lebih banyak privasi kepada pengguna.

Untuk mempelajari lebih lanjut berbagai teknik untuk melindungi pengguna Anda, lihat kumpulan Aman dan Terlindungi kami

Referensi

• Memahami "situs yang sama" dan "origin yang sama"
• Header keamanan baru: Referrer Policy (2017)
• Referrer-Policy di MDN
• Header perujuk: masalah privasi dan keamanan di MDN
• Perubahan Chrome: Intent kedip untuk mengimplementasikan
• Perubahan Chrome: Niat berkedip untuk mengirimkan
• Perubahan Chrome: entri status
• Perubahan Chrome: Postingan blog versi 85 beta
• Pemangkasan thread GitHub perujuk: hal yang dilakukan berbagai browser
• Spesifikasi Perujuk-Kebijakan

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