Definisi "situs yang sama" berkembang untuk menyertakan skema URL, sehingga link antara versi HTTP dan HTTPS situs kini dihitung sebagai permintaan lintas situs. Upgrade ke HTTPS secara default untuk menghindari masalah jika memungkinkan, atau baca terus untuk mengetahui detail nilai atribut SameSite yang diperlukan.
Skema Situs yang Sama mengubah definisi situs (web) dari hanya domain yang dapat didaftarkan menjadi skema + domain yang dapat didaftarkan. Anda dapat menemukan detail dan contoh selengkapnya di Memahami "same-site" dan "origin yang sama".
Kabar baiknya adalah: jika situs web Anda telah sepenuhnya ditingkatkan ke HTTPS maka Anda tidak perlu mengkhawatirkan apa pun. Tidak ada yang berubah untuk Anda.
Jika Anda belum sepenuhnya mengupgrade situs, ini harus menjadi prioritas.
Namun, jika ada kasus di mana pengunjung situs
Anda akan beralih antara HTTP dan
HTTPS, lalu beberapa skenario umum tersebut dan cookie SameSite
terkait
perilaku tersebut diuraikan di bawah ini.
Anda dapat mengaktifkan perubahan ini untuk pengujian di Chrome dan Firefox.
- Mulai Chrome 86, aktifkan
about://flags/#schemeful-same-site
. Memantau progres di Status Chrome halaman kami. - Dari Firefox 79, tetapkan
network.cookie.sameSite.schemeful
ketrue
melaluiabout:config
. Lacak progres via Bugzilla masalah.
Salah satu alasan utama untuk perubahan ke SameSite=Lax
sebagai default untuk
adalah untuk melindungi dari Pemalsuan Permintaan Lintas Situs
(CSRF). Namun,
lalu lintas HTTP yang tidak aman masih
memiliki peluang bagi penyerang untuk
mengutak-atik {i>cookie<i} yang kemudian akan
digunakan pada versi HTTPS yang aman
situs Anda. Membuat batas lintas situs tambahan di antara skema akan memberikan
pertahanan yang lebih baik
dari serangan tersebut.
Skenario silang umum
Navigasi
Menavigasi di antara versi situs web lintas skema (misalnya, menautkan dari
http://site.example ke https://site.example) sebelumnya akan mengizinkan
SameSite=Strict
cookie yang akan dikirim. Sekarang, hal ini diperlakukan sebagai lintas situs
navigasi yang berarti cookie SameSite=Strict
akan diblokir.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Diblokir | ⛔ Diblokir |
SameSite=Lax
|
✓ Diizinkan | ✓ Diizinkan |
SameSite=None;Secure
|
✓ Diizinkan | ⛔ Diblokir |
Memuat subresource
Setiap perubahan yang Anda buat di sini sebaiknya hanya dianggap sebagai perbaikan sementara selama Anda bekerja untuk meningkatkan ke HTTPS penuh.
Contoh subresource mencakup gambar, iframe, dan permintaan jaringan yang dibuat dengan XHR atau Fetch.
Memuat subresource lintas skema pada halaman sebelumnya akan mengizinkan
SameSite=Strict
atau SameSite=Lax
cookie yang akan dikirim atau ditetapkan. Ini adalah
diperlakukan dengan cara yang sama seperti subresource pihak
ketiga atau lintas situs lainnya yang
berarti bahwa cookie SameSite=Strict
atau SameSite=Lax
akan diblokir.
Selain itu, meskipun browser mengizinkan sumber
daya dari skema yang tidak aman ke
dimuat di halaman yang aman, semua cookie akan diblokir pada permintaan ini ketika
cookie pihak ketiga atau lintas situs memerlukan Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Diblokir | ⛔ Diblokir |
SameSite=Lax
|
⛔ Diblokir | ⛔ Diblokir |
SameSite=None;Secure
|
✓ Diizinkan | ⛔ Diblokir |
MEMPOSTING formulir
Pengeposan antar-skema situs web
sebelumnya akan memungkinkan
cookie yang ditetapkan dengan SameSite=Lax
atau SameSite=Strict
untuk dikirim. Ini adalah
diperlakukan sebagai POST lintas situs—hanya SameSite=None
cookie yang dapat dikirim. Anda mungkin
mengalami skenario ini pada situs yang
memberikan versi yang tidak aman secara {i>default<i},
tetapi meningkatkan pengguna ke versi
aman saat melakukan upaya masuk atau
formulir {i>check out<i}.
Seperti pada subresource, jika permintaan berasal dari jaringan aman, mis. HTTPS, dengan
tidak aman, misalnya HTTP, konteks lalu semua cookie akan diblokir pada permintaan ini
karena cookie pihak ketiga atau lintas situs memerlukan Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Diblokir | ⛔ Diblokir |
SameSite=Lax
|
⛔ Diblokir | ⛔ Diblokir |
SameSite=None;Secure
|
✓ Diizinkan | ⛔ Diblokir |
Bagaimana cara menguji situs saya?
Alat dan pesan developer tersedia di Chrome dan Firefox.
Mulai Chrome 86, tab Masalah di DevTools akan mencakup masalah Schemeful Same-Site. Anda mungkin melihat masalah berikut ditandai untuk situs Anda.
Masalah navigasi:
- "Bermigrasi sepenuhnya ke HTTPS agar cookie terus dikirim di situs yang sama permintaan"—Peringatan bahwa cookie akan diblokir pada versi mendatang Chrome.
- "Migrasikan sepenuhnya ke HTTPS agar cookie dikirim pada permintaan situs yang sama"—A peringatan bahwa cookie telah diblokir.
Masalah pemuatan subresource:
- "Bermigrasi sepenuhnya ke HTTPS agar cookie terus dikirim ke situs yang sama subresource" atau "Migrasikan sepenuhnya ke HTTPS untuk terus mengizinkan cookie untuk ditetapkan oleh subresource situs yang sama"—Peringatan bahwa cookie akan diblokir di Chrome versi mendatang.
- "Migrasikan sepenuhnya ke HTTPS agar cookie dikirim ke subresource situs yang sama" atau "Bermigrasi sepenuhnya ke HTTPS untuk mengizinkan cookie disetel oleh situs yang sama subresources"—Peringatan bahwa cookie telah diblokir. Terakhir peringatan ini juga dapat muncul saat MEMPOSTING formulir.
Detail selengkapnya tersedia di Tips Pengujian dan Proses Debug untuk Schemeful Situs yang Sama.
Dari Firefox 79, dengan network.cookie.sameSite.schemeful
ditetapkan ke true
melalui
about:config
konsol akan menampilkan pesan untuk masalah Schemeful Same-Site.
Anda mungkin melihat hal berikut di situs Anda:
- "Cookie
cookie_name
akan segera diperlakukan sebagai cookie lintas situs terhadaphttp://site.example/
karena skema tidak cocok." - "Cookie
cookie_name
telah diperlakukan sebagai lintas situs terhadaphttp://site.example/
karena skema tidak cocok."
FAQ
Situs saya sudah sepenuhnya tersedia di HTTPS, mengapa saya melihat masalah di DevTools browser?
Mungkin beberapa link dan subresource Anda masih mengarah ke status tidak aman URL.
Salah satu cara untuk memperbaiki masalah ini adalah dengan menggunakan HTTP
Strict-Transport-Security
(ECPC) dan perintah includeSubDomain
. Dengan ECPC + includeSubDomain
merata
jika salah satu halaman Anda tidak sengaja menyertakan link yang tidak aman, browser akan
secara otomatis menggunakan
versi yang aman sebagai gantinya.
Bagaimana jika saya tidak dapat mengupgrade ke HTTPS?
Meskipun kami sangat menyarankan agar Anda mengupgrade situs sepenuhnya ke HTTPS untuk melindungi pengguna Anda, jika Anda tidak dapat melakukannya sendiri, sebaiknya bicarakan dengan penyedia hosting Anda untuk melihat apakah mereka dapat menawarkan opsi tersebut. Jika Anda menghosting sendiri, lalu Let's Encrypt menyediakan sejumlah alat untuk menginstal dan mengonfigurasi sertifikat. Anda juga dapat menyelidiki pemindahan situs di belakang CDN atau proxy lain yang dapat menyediakan koneksi HTTPS.
Jika masih tidak memungkinkan, coba longgarkan perlindungan SameSite
di
cookie yang terpengaruh.
- Jika hanya
SameSite=Strict
cookie yang diblokir, Anda dapat menurunkan perlindungan keLax
. - Jika cookie
Strict
danLax
diblokir dan cookie dikirim ke (atau disetel dari) URL aman, Anda dapat menurunkan perlindungan data menjadiNone
.- Solusi ini akan gagal jika URL tujuan pengiriman cookie (atau
menyetelnya) tidak aman. Hal ini karena
SameSite=None
memerlukanSecure
pada cookie, yang berarti cookie tersebut tidak dapat dikirim atau menggunakan koneksi yang tidak aman. Dalam kasus ini, Anda tidak akan dapat mengakses cookie tersebut hingga situs Anda diupgrade ke HTTPS. - Ingat, ini hanya bersifat sementara karena pada akhirnya cookie pihak ketiga akan dihentikan sepenuhnya.
- Solusi ini akan gagal jika URL tujuan pengiriman cookie (atau
menyetelnya) tidak aman. Hal ini karena
Bagaimana pengaruhnya terhadap cookie saya jika saya belum menentukan atribut SameSite
?
Cookie tanpa atribut SameSite
diperlakukan seolah-olah cookie tersebut ditentukan
SameSite=Lax
dan perilaku lintas skema yang sama berlaku untuk cookie ini sebagai
ya. Perhatikan bahwa pengecualian sementara untuk metode yang tidak aman masih berlaku. Lihat
mitigasi Lax + POST di Chromium SameSite
FAQ untuk mengetahui informasi selengkapnya.
Bagaimana WebSockets terpengaruh?
Koneksi WebSocket akan tetap dianggap sebagai situs yang sama jika koneksinya sama tingkat keamanan sebagai halaman.
Situs yang sama:
wss://
koneksi darihttps://
ws://
koneksi darihttp://
Lintas situs:
wss://
koneksi darihttp://
ws://
koneksi darihttps://
Foto oleh Julissa {i>Capdevilla<i} aktif Buka Pembukaan