Praktik terbaik Perujuk dan Kebijakan Perujuk

Maud Nalpas

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

Ringkasan

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

Referer dan Referrer-Policy 101

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

Dalam contoh berikut, header Referer menyertakan URL lengkap halaman di 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 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 dapat 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 dalam Referer lintas asal, hal ini dapat membahayakan privasi pengguna dan menimbulkan risiko keamanan:

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

URL #6 adalah URL kemampuan. Jika orang lain selain pengguna yang dituju menerima pesan ini, oknum yang berniat jahat dapat mengambil alih akun pengguna ini.

Untuk membatasi data perujuk yang tersedia 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 kebijakannya, data yang tersedia dari header Referer (dan document.referrer) dapat berupa:

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

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

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

MDN menyediakan daftar lengkap contoh kebijakan dan 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 kualitas keamanan; yaitu, apakah permintaan dapat mengekspos data dari asal terenkripsi ke asal yang tidak terenkripsi, seperti dalam permintaan HTTPS → HTTP. Permintaan HTTP → HTTP sepenuhnya tidak dienkripsi, sehingga tidak ada penurunan kualitas.
• Jika permintaan berasal dari origin yang sama, berarti skema (HTTPS atau HTTP) sama, sehingga tidak ada penurunan keamanan.

Kebijakan perujuk default di browser

Mulai Oktober 2021

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

Praktik terbaik untuk menyetel kebijakan perujuk

Ada berbagai cara untuk menetapkan kebijakan perujuk untuk situs Anda:

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

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

Header HTTP dan elemen meta keduanya 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 mana 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.

Kebijakan mana yang harus Anda tetapkan untuk situs Anda?

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

Mengapa "secara eksplisit"?

Jika Anda tidak menyetel kebijakan perujuk, kebijakan default browser akan digunakan. Bahkan, situs sering kali menggunakan kebijakan default browser. Namun, hal ini tidak ideal karena:

• Setiap browser memiliki kebijakan default yang berbeda, jadi jika Anda mengandalkan default browser, situs Anda tidak akan berperilaku secara terprediksi di berbagai browser.
• Browser mengadopsi setelan default yang lebih ketat seperti strict-origin-when-cross-origin dan mekanisme seperti pemangkasan perujuk untuk permintaan lintas asal. Memilih untuk mengaktifkan kebijakan yang meningkatkan privasi secara eksplisit sebelum setelan default browser berubah 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 bermanfaat. Arti "berguna" bergantung pada apa yang Anda inginkan dari perujuk:

• Aman: Jika situs Anda menggunakan HTTPS (jika tidak, jadikan ini sebagai 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 man-in-the-middle. Kebijakan no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, dan strict-origin memecahkan 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 asal, dan no-referrer tidak membagikan apa pun. Dengan demikian, Anda memiliki 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 dari 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 longgar 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 dapat membatasi document.referrer atau header Referer untuk permintaan lintas situs. Lihat detail.

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 Anda, sebagaimana ditentukan oleh Anda, tim Anda, dan perusahaan Anda. Jika beberapa URL berisi data sensitif atau identitas, tetapkan kebijakan perlindungan.

Praktik terbaik untuk permintaan masuk

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

Melindungi data pengguna

Referer dapat berisi data pribadi, rahasia, 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 tidak memiliki kontrol atas penerapan 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 digunakan sebelumnya. Artinya, Anda menerima lebih sedikit data dari Referer daripada sebelumnya.
• Browser semakin sering menggunakan Referrer-Policy strict-origin-when-cross-origin secara default. Artinya, Anda mungkin hanya menerima origin, bukan URL perujuk lengkap, dalam permintaan lintas origin yang masuk, jika situs pengirim tidak menyetel kebijakan.
• Browser dapat mengubah cara mereka mengelola Referer. Misalnya, beberapa developer browser mungkin memutuskan untuk selalu memangkas perujuk ke asal dalam permintaan subresource lintas origin, untuk melindungi privasi pengguna.
• Header Referer (dan document.referrer) mungkin berisi lebih banyak data daripada yang Anda butuhkan. Misalnya, mungkin memiliki URL lengkap saat Anda hanya ingin mengetahui apakah permintaan bersifat 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 asal. 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, pertama-tama analisis bagian perujuk yang Anda gunakan.

Jika Anda hanya memerlukan asal

• 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 bersifat lintas asal, yang mungkin persis seperti yang Anda butuhkan.

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

• Parameter permintaan dapat menangani 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 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 butuhkan dalam beberapa jenis konfigurasi.
  • Pro: lebih eksplisit, lebih menjaga privasi untuk pengguna site-one.example, lebih siap menghadapi masa depan.
  • Kontra: berpotensi menambah pekerjaan dari pihak Anda atau bagi pengguna sistem Anda.
• Periksa apakah situs yang mengirimkan permintaan mungkin setuju untuk menetapkan Referrer-Policy per elemen atau per permintaan no-referrer-when-downgrade.
  • Kontra: berpotensi kurang menjaga privasi pengguna site-one.example, berpotensi tidak didukung di semua browser.

Perlindungan dari Pemalsuan Permintaan Lintas Situs (CSRF)

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

Gunakan token CSRF sebagai perlindungan utama Anda. Untuk perlindungan ekstra, gunakan SameSite, dan alih-alih 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 asal, 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 mungkin mengandalkan header Referer dari permintaan masuk untuk pemeriksaan keamanan.

Contoh:

• Pengguna mengklik tombol Beli di online-shop.example/cart/checkout.
• online-shop.example akan dialihkan ke payment-provider.example untuk mengelola transaksi.
• payment-provider.example memeriksa Referer permintaan ini terhadap daftar nilai Referer yang diizinkan yang disiapkan oleh penjual. Jika tidak cocok dengan entri mana pun dalam daftar, payment-provider.example akan menolak permintaan. Jika cocok, pengguna dapat melanjutkan 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 bukanlah dasar yang andal untuk pemeriksaan. Situs yang meminta, baik penjual yang sah maupun tidak, dapat menetapkan kebijakan no-referrer yang membuat informasi Referer tidak tersedia bagi penyedia pembayaran.

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

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

Untuk memverifikasi pembayaran dengan lebih andal, izinkan pemohon meng-hash parameter permintaan bersama dengan kunci unik. Penyedia pembayaran kemudian dapat menghitung hash yang sama di sisi Anda dan hanya menerima permintaan jika cocok dengan perhitungan Anda.

Apa yang terjadi pada Referer saat situs penjual HTTP tanpa kebijakan perujuk dialihkan 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.

Kesimpulan

Kebijakan perujuk pelindung adalah cara yang efektif untuk memberikan lebih banyak privasi kepada pengguna Anda.

Untuk mempelajari lebih lanjut berbagai teknik untuk melindungi pengguna Anda, 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: Menerapkan maksud Blink
• Perubahan Chrome: Maksud Blink untuk meluncurkan
• Perubahan Chrome: entri status
• Perubahan Chrome: postingan blog versi beta 85
• Thread GitHub pemangkasan perujuk: apa yang dilakukan browser yang berbeda
• Spesifikasi Referrer-Policy

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.