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 origin yang tidak terduga dapat merusak pengalaman pengguna web privasi. J kebijakan perujuk {i>protektif<i} dapat membantu.
• Sebaiknya tetapkan kebijakan perujuk strict-origin-when-cross-origin. Ini mempertahankan sebagian besar kegunaan perujuk, sekaligus mengurangi risiko membocorkan data lintas origin.
• Jangan gunakan perujuk untuk perlindungan Pemalsuan Permintaan Lintas Situs (CSRF). Gunakan Token CSRF dan {i>header <i}lainnya sebagai lapisan keamanan ekstra.

Kebijakan Perujuk dan Perujuk 101

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

Pada contoh berikut, header Referer menyertakan URL lengkap dari halaman pada site-one tempat permintaan dibuat.

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 dibutuhkan oleh sebuah 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 dapat menggunakannya untuk mengetahui bahwa 50% pengunjung di site-two.example berasal dari social-network.example. Tetapi ketika URL lengkap, termasuk jalur dan string kueri yang dikirim dalam Referer di seluruh asal, dapat membahayakan pengguna privasi dan menimbulkan risiko keamanan:

URL #1 sampai #5 berisi informasi pribadi, dan terkadang sensitif atau informasi identitas. Membocorkan data ini secara diam-diam ke berbagai sumber dapat menyusupi pengguna web privasi.

URL #6 adalah URL kapabilitas. Jika ada selain pengguna yang dituju akan menerimanya, pelaku kejahatan dapat mengambil alih akun pengguna ini.

Guna 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. Tergantung pada kebijakannya, data 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

Beberapa kebijakan dirancang untuk berperilaku lain bergantung pada konteksnya: permintaan lintas origin atau origin yang sama, aman sebagai asalnya, atau pun keduanya. Hal ini berguna untuk membatasi jumlah informasi dibagikan ke seluruh origin atau ke origin yang kurang aman, sekaligus menjaga kekayaan perujuk dalam situs Anda sendiri.

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

MDN menyediakan daftar lengkap kebijakan dan perilaku contoh.

Berikut beberapa hal yang harus diperhatikan saat menetapkan kebijakan perujuk:

• Semua kebijakan yang mempertimbangkan skema tersebut (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 lain HTTPS, meskipun HTTP kurang aman. Karena untuk program ini, kebijakan kami, yang penting adalah apakah downgrade keamanan dilakukan; sehingga adalah, jika permintaan dapat mengekspos data dari origin yang dienkripsi ke satu, seperti dalam HTTPS → permintaan HTTP. Permintaan HTTP → HTTP sepenuhnya tidak dienkripsi, sehingga tidak ada penurunan versi.
• Jika permintaan adalah origin yang sama, ini berarti skema (HTTPS atau HTTP) tersebut hal yang sama, jadi tidak ada penurunan keamanan.

Kebijakan perujuk default di browser

Per Oktober 2021

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

Praktik terbaik untuk menetapkan kebijakan perujuk

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 pada 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 dari halaman ini mengikuti strict-origin-when-cross-origin lebih lanjut.

Bagaimana cara melihat kebijakan perujuk?

securityheaders.com berguna untuk menentukan 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 menunjukkan Referer yang terkirim.

Kebijakan manakah yang sebaiknya ditetapkan untuk situs Anda?

Kami sangat menyarankan agar secara eksplisit menetapkan kebijakan yang meningkatkan privasi seperti strict-origin-when-cross-origin (atau lebih ketat).

Mengapa "secara eksplisit"?

Jika Anda tidak menetapkan kebijakan perujuk, kebijakan default browser akan digunakan—bahkan, situs web sering mengalihkan ke setelan {i>default<i} browser. Namun, ini tidak ideal, karena:

• Browser yang berbeda memiliki kebijakan default yang berbeda, jadi jika Anda mengandalkan browser default, perilaku situs Anda tidak dapat diprediksi di seluruh browser.
• Browser mengadopsi setelan default yang lebih ketat seperti strict-origin-when-cross-origin dan mekanisme seperti pemangkasan perujuk untuk permintaan lintas origin. Secara eksplisit memilih ikut serta dalam kebijakan peningkatan privasi sebelum perubahan default browser memberi Anda kontrol dan membantu menjalankan pengujian yang Anda inginkan.

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

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

• Aman: jika situs Anda menggunakan HTTPS (jika tidak, jadikan prioritas Anda), jangan sampai URL situs Anda bocor permintaan non-HTTPS. Karena siapa pun di jaringan dapat melihat ini, kebocoran akan membuat pengguna Anda rentan terkena serangan {i> person-in-the-middle<i}. Kebijakan tersebut no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, dan strict-origin untuk 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 tempat asal, dan no-referrer tidak berbagi sama sekali. Ini memberi Anda strict-origin-when-cross-origin, strict-origin, dan no-referrer sebagai opsi yang meningkatkan 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 pilihan yang lebih baik.

Semua ini berarti bahwa strict-origin-when-cross-origin secara umum adalah pilihan yang logis.

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

index.html:

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

Atau sisi server, misalnya dalam 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, ambil pendekatan progresif: tetapkan kebijakan perlindungan seperti strict-origin-when-cross-origin untuk situs Anda, dan jika perlu, kebijakan 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 dan permintaan lintas situs. Lihat detail.

Contoh: kebijakan tingkat permintaan

script.js:

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

Apa lagi yang perlu Anda pertimbangkan?

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

Praktik terbaik untuk permintaan masuk

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

Melindungi pengguna data

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

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

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

• Jika Anda tidak memiliki kontrol atas penerapan penghasil permintaan, Anda tidak dapat membuat asumsi tentang header Referer (dan document.referrer) yang Anda terima. Pemancar permintaan mungkin memutuskan untuk beralih ke kebijakan no-referrer kapan saja , atau yang lebih umum pada kebijakan yang lebih ketat dari apa yang digunakan sebelumnya. Artinya, Anda akan menerima lebih sedikit data dari Referer daripada sebelumnya.
• Browser semakin banyak menggunakan Referrer-Policy strict-origin-when-cross-origin secara {i>default<i}. Ini berarti bahwa sekarang Anda mungkin hanya menerima sumber asal, bukan URL perujuk lengkap, dalam permintaan lintas asal yang masuk, jika situs pengirim tidak memiliki kebijakan yang disetel.
• Browser mungkin mengubah cara mengelola Referer. Misalnya, beberapa browser developer mungkin memutuskan untuk selalu memangkas perujuk ke origin di cross-origin permintaan subresource, untuk melindungi privasi pengguna.
• Header Referer (dan document.referrer) mungkin berisi lebih banyak data dari yang dibutuhkan. Misalnya, aplikasi itu mungkin memiliki URL lengkap ketika Anda hanya ingin tahu apakah permintaannya bersifat lintas origin.

Alternatif untuk Referer

Anda mungkin perlu mempertimbangkan alternatif jika:

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

Untuk menetapkan alternatif, pertama-tama analisis bagian perujuk yang Anda gunakan.

Jika Anda hanya memerlukan origin

• Jika Anda menggunakan perujuk dalam skrip yang memiliki akses tingkat atas ke laman, window.location.origin adalah alternatif.
• Jika tersedia, {i>header<i} seperti Origin dan Sec-Fetch-Site memberi Anda Origin atau menjelaskan apakah permintaan tersebut lintas origin, yang mungkin sudah sesuai dengan yang Anda butuhkan.

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

• Parameter permintaan mungkin menangani kasus penggunaan Anda, sehingga Anda tidak perlu menguraikan perujuk.
• Jika Anda menggunakan perujuk dalam skrip yang memiliki akses tingkat atas ke laman, window.location.pathname mungkin berfungsi sebagai alternatif. Hanya mengekstrak jalur di URL dan meneruskannya sebagai argumen, sehingga setiap pesan yang informasi di parameter URL tidak diteruskan.

Jika Anda tidak dapat menggunakan alternatif berikut:

• Memeriksa apakah Anda dapat mengubah sistem untuk memperkirakan pengirim permintaan (misalnya, site-one.example) untuk menetapkan informasi yang diperlukan secara eksplisit dalam beberapa jenis konfigurasi.
  • Kelebihan: lebih eksplisit dan 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 mengeluarkan permintaan mungkin setuju untuk menyetel Kebijakan Perujuk per elemen atau per permintaan dari no-referrer-when-downgrade.
  • Kontra: mungkin kurang menjaga privasi bagi pengguna site-one.example, mungkin tidak didukung di semua browser.

Perlindungan Pemalsuan Permintaan Lintas Situs (CSRF)

Pemancar permintaan selalu bisa memutuskan untuk tidak mengirim perujuk dengan menetapkan no-referrer, dan pelaku kejahatan bahkan dapat melakukan spoofing terhadap perujuk.

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

Catat dan debug

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

Jika Anda hanya menggunakan origin, periksa apakah Anda dapat menggunakan Origin sebagai sebuah alternatif. Langkah ini mungkin memberi Anda informasi yang diperlukan untuk {i>debugging<i} tujuan dengan cara yang lebih sederhana dan tanpa perlu mengurai perujuk.

Pembayaran

Penyedia pembayaran mungkin 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 terhadap daftar dari nilai Referer yang diizinkan yang disiapkan oleh penjual. Jika tidak sesuai dengan dalam daftar, payment-provider.example akan menolak permintaan tersebut. Jika ya 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 itu sendiri bukan dasar yang dapat diandalkan untuk memeriksa. Situs yang meminta, apakah mereka pedagang yang sah atau bukan, dapat menetapkan Kebijakan no-referrer yang membuat informasi Referer tidak tersedia bagi penyedia layanan pembayaran.

Melihat Referer dapat membantu penyedia jasa 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 terhadap data minimum yang dapat dimasukkan, yang merupakan asalnya.
  • Saat menetapkan daftar nilai Referer yang diizinkan, pastikan untuk hanya menyertakan tempat 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 permintaan asal situs, Anda dapat mencegah kesalahan yang mungkin muncul saat membuat asumsi tentang Referrer-Policy penjual.
• Jika Referer tidak ada, atau jika ada dan asal Referer dasar Anda berhasil, Anda dapat beralih ke verifikasi lain yang lebih dapat diandalkan .

Untuk memverifikasi pembayaran secara lebih andal, izinkan pemohon melakukan hashing pada parameter permintaan dengan kunci unik. Penyedia pembayaran kemudian dapat menghitung hash yang sama di pihak Anda dan hanya terima permintaan jika cocok dengan perhitungan Anda.

Yang terjadi pada Referer saat situs penjual HTTP tanpa perujuk pengalihan kebijakan 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 menyetel kebijakan. Perubahan Chrome ke kebijakan default baru tidak akan mengubah perilaku ini.

Kesimpulan

Kebijakan perujuk yang melindungi adalah cara terbaik untuk memberikan lebih banyak privasi kepada pengguna Anda.

Untuk mempelajari lebih lanjut berbagai teknik untuk melindungi pengguna Anda, lihat Koleksi Aman dan terlindungi

Resource

• Memahami "same-site" dan "origin yang sama"
• Header keamanan baru: Kebijakan Perujuk (2017)
• Kebijakan Perujuk aktif MDN
• Header perujuk: masalah privasi dan keamanan di MDN
• Perubahan Chrome: Intent berkedip ke terapkan
• Perubahan Chrome: Intent berkedip ke kapal
• Perubahan Chrome: entri status
• Perubahan Chrome: 85 beta blogpost
• Perujuk yang memangkas thread GitHub: browser apa saja Anda
• Spesifikasi Kebijakan Perujuk

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