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
:
Cakupan kebijakan | Nama kebijakan | Perujuk: Tidak ada data | Perujuk: Hanya asal | Perujuk: URL Lengkap |
---|---|---|---|---|
Tidak mempertimbangkan konteks permintaan | no-referrer |
centang | ||
origin |
centang | |||
unsafe-url |
centang | |||
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 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
, danstrict-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.
Browser | Referrer-Policy / Perilaku Default |
---|---|
Chrome |
Defaultnya adalah strict-origin-when-cross-origin .
|
Firefox |
Defaultnya adalah strict-origin-when-cross-origin .Mulai versi 93, untuk pengguna Strict Tracking Protection dan Private Browsing, kebijakan perujuk yang ketat no-referrer-when-downgrade ,
origin-when-cross-origin , dan unsafe-url adalah
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
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:
- Kebijakan tingkat 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" />
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
, danstrict-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
danstrict-origin
hanya berbagi tempat asal, danno-referrer
tidak berbagi sama sekali. Ini memberi Andastrict-origin-when-cross-origin
,strict-origin
, danno-referrer
sebagai opsi yang meningkatkan 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 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
(dandocument.referrer
) yang Anda terima. Pemancar permintaan mungkin memutuskan untuk beralih ke kebijakanno-referrer
kapan saja , atau yang lebih umum pada kebijakan yang lebih ketat dari apa yang digunakan sebelumnya. Artinya, Anda akan menerima lebih sedikit data dariReferer
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
(dandocument.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
danSec-Fetch-Site
memberi AndaOrigin
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.
- Kelebihan: lebih eksplisit dan lebih menjaga privasi bagi pengguna
- 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.
- Kontra: mungkin kurang menjaga privasi bagi pengguna
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 kepayment-provider.example
untuk mengelola transaksi.payment-provider.example
memeriksaReferer
permintaan ini terhadap daftar dari nilaiReferer
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 untukonline-shop.example
harusonline-shop.example
, bukanonline-shop.example/cart/checkout
. Dengan mengharapkan tidak adaReferer
sama sekali atau nilaiReferer
yang hanya merupakan permintaan asal situs, Anda dapat mencegah kesalahan yang mungkin muncul saat membuat asumsi tentangReferrer-Policy
penjual.
- Saat menetapkan daftar nilai
- Jika
Referer
tidak ada, atau jika ada dan asalReferer
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.