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.
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.
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:
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
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
, danstrict-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
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:
- Kebijakan level elemen
- Kebijakan tingkat halaman
- 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.
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
, danstrict-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
danstrict-origin
hanya berbagi origin, danno-referrer
tidak berbagi sama sekali. Dengan demikian, Anda memilikistrict-origin-when-cross-origin
,strict-origin
, danno-referrer
sebagai opsi peningkatan privasi. - Berguna:
no-referrer
danstrict-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.
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
(dandocument.referrer
) yang diterima. Pemancar permintaan dapat memutuskan untuk beralih ke kebijakanno-referrer
kapan saja , atau lebih umum ke kebijakan yang lebih ketat daripada yang mereka gunakan sebelumnya. Ini berarti Anda menerima lebih sedikit data dariReferer
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
(dandocument.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
danSec-Fetch-Site
akan memberi AndaOrigin
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.
- Pro: lebih eksplisit, lebih menjaga privasi bagi pengguna
- 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.
- Kontra: berpotensi kurang menjaga privasi untuk pengguna
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 kepayment-provider.example
untuk mengelola transaksi.payment-provider.example
memeriksaReferer
permintaan ini berdasarkan daftar nilaiReferer
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 untukonline-shop.example
harusonline-shop.example
, bukanonline-shop.example/cart/checkout
. Dengan mengharapkan tidak adaReferer
sama sekali atau nilaiReferer
yang hanya merupakan asal situs yang meminta, Anda mencegah error yang mungkin muncul saat membuat asumsi tentangReferrer-Policy
penjual.
- Saat menetapkan daftar nilai
- Jika
Referer
tidak ada, atau jika ada dan pemeriksaanReferer
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.
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.