คำจำกัดความของ "เว็บไซต์เดียวกัน" มีการเปลี่ยนแปลงเพื่อรวมรูปแบบ URL ดังนั้นการลิงก์ระหว่างเวอร์ชัน HTTP และ HTTPS ของเว็บไซต์จึงนับเป็นคำขอข้ามเว็บไซต์ อัปเกรดเป็น HTTPS โดยค่าเริ่มต้นเพื่อหลีกเลี่ยงปัญหาที่เป็นไปได้ หรืออ่านต่อไปเพื่อดูรายละเอียดเกี่ยวกับค่าแอตทริบิวต์ SameSite ที่จำเป็น
รูปแบบ เว็บไซต์เดียวกัน แก้ไขคำจำกัดความของเว็บไซต์ (เว็บ) จากเฉพาะโดเมนที่จดทะเบียนได้ไปยัง รูปแบบ + โดเมนที่จดทะเบียนได้ ดูรายละเอียดและตัวอย่างเพิ่มเติมได้ในการทำความเข้าใจเกี่ยวกับ "เว็บไซต์เดียวกัน" และ "ต้นทางเดียวกัน"
ข่าวดีคือ หากเว็บไซต์ของคุณได้รับการอัปเกรดเป็น HTTPS โดยสมบูรณ์แล้ว คุณก็ไม่ต้องกังวลอะไรเลย โดยจะไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้น
หากคุณยังไม่ได้อัปเกรดเว็บไซต์อย่างเต็มรูปแบบ ก็ควรให้ความสำคัญกับเรื่องนี้
อย่างไรก็ตาม หากมีกรณีที่ผู้เข้าชมเว็บไซต์อยู่ระหว่าง HTTP กับ HTTPS สถานการณ์ที่พบบ่อยเหล่านั้นบางส่วนและลักษณะการทำงานของคุกกี้ SameSite
ที่เกี่ยวข้องจะแสดงอยู่ด้านล่าง
คุณเปิดใช้การเปลี่ยนแปลงเหล่านี้สำหรับการทดสอบได้ทั้งใน Chrome และ Firefox
- จาก Chrome 86 ให้เปิดใช้
about://flags/#schemeful-same-site
ติดตามความคืบหน้าในหน้าสถานะของ Chrome - จาก Firefox 79 ให้ตั้งค่า
network.cookie.sameSite.schemeful
เป็นtrue
ผ่านabout:config
ติดตามความคืบหน้าผ่านปัญหา Bugzilla
หนึ่งในเหตุผลหลักที่เปลี่ยนเป็น SameSite=Lax
เป็นค่าเริ่มต้นสำหรับคุกกี้คือการป้องกันการปลอมแปลงคำขอข้ามเว็บไซต์ (CSRF) อย่างไรก็ตาม การเข้าชม HTTP ที่ไม่ปลอดภัยยังคงเปิดโอกาสให้ผู้โจมตีเครือข่ายปรับเปลี่ยนคุกกี้ซึ่งจะนำมาใช้ในเว็บไซต์เวอร์ชัน HTTPS ที่ปลอดภัย การสร้างขอบเขตเพิ่มเติมข้ามเว็บไซต์ระหว่างรูปแบบจะช่วยเสริมการป้องกันการโจมตีเหล่านี้
สถานการณ์ที่พบบ่อยแบบข้ามรูปแบบ
การนำทาง
การสลับไปมาระหว่างเว็บไซต์เวอร์ชันข้ามรูปแบบ (เช่น การลิงก์จาก http://site.example ไปยัง https://site.example) จะทำให้ก่อนหน้านี้สามารถส่งคุกกี้ SameSite=Strict
ได้ ตอนนี้ระบบจะถือว่าเป็นการไปยังส่วนต่างๆ แบบข้ามเว็บไซต์ ซึ่งหมายความว่าระบบจะบล็อกคุกกี้ SameSite=Strict
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ ถูกบล็อก | ⛔ ถูกบล็อก |
SameSite=Lax
|
✓ อนุญาต | ✓ อนุญาต |
SameSite=None;Secure
|
✓ อนุญาต | ⛔ ถูกบล็อก |
กำลังโหลดทรัพยากรย่อย
การเปลี่ยนแปลงที่คุณทำที่นี่ถือเป็นการแก้ไขชั่วคราวเท่านั้นระหว่างการอัปเกรดสู่ HTTPS เต็มรูปแบบ
ตัวอย่างของทรัพยากรย่อย ได้แก่ รูปภาพ, iframe และคำขอเครือข่ายที่สร้างด้วย XHR หรือ Fetch
การโหลดทรัพยากรย่อยแบบข้ามรูปแบบในหน้าเว็บจะทำให้สามารถส่งหรือตั้งค่าคุกกี้ SameSite=Strict
หรือ SameSite=Lax
ได้ก่อนหน้านี้ และตอนนี้ก็จะมีการดำเนินการในลักษณะเดียวกับทรัพยากรย่อยอื่นๆ ของบุคคลที่สามหรือข้ามเว็บไซต์ ซึ่งหมายความว่าคุกกี้ SameSite=Strict
หรือ SameSite=Lax
จะถูกบล็อก
นอกจากนี้ แม้ว่าเบราว์เซอร์จะอนุญาตให้โหลดทรัพยากรจากรูปแบบที่ไม่ปลอดภัยในหน้าเว็บที่ปลอดภัย แต่ระบบจะบล็อกคุกกี้ทั้งหมดในคำขอเหล่านี้เนื่องจากคุกกี้ของบุคคลที่สามหรือคุกกี้ข้ามเว็บไซต์ต้องใช้ Secure
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ ถูกบล็อก | ⛔ ถูกบล็อก |
SameSite=Lax
|
⛔ ถูกบล็อก | ⛔ ถูกบล็อก |
SameSite=None;Secure
|
✓ อนุญาต | ⛔ ถูกบล็อก |
การโพสต์แบบฟอร์ม
การโพสต์ระหว่างเว็บไซต์เวอร์ชันข้ามรูปแบบจะอนุญาตให้ส่งคุกกี้ที่ตั้งค่าด้วย SameSite=Lax
หรือ SameSite=Strict
ได้ก่อนหน้านี้ แต่ตอนนี้จะทำงานแบบ POST แบบข้ามเว็บไซต์ โดยจะส่งได้เฉพาะคุกกี้ SameSite=None
เท่านั้น คุณอาจพบสถานการณ์นี้ในเว็บไซต์ที่แสดงเวอร์ชันที่ไม่ปลอดภัยโดยค่าเริ่มต้น แต่ให้อัปเกรดผู้ใช้เป็นเวอร์ชันที่ปลอดภัยเมื่อส่งฟอร์มลงชื่อเข้าใช้หรือชำระเงิน
เช่นเดียวกับทรัพยากรย่อย หากคำขอส่งจากที่ปลอดภัย เช่น HTTPS ไปยังที่ไม่ปลอดภัย เช่น บริบท HTTP คุกกี้ทั้งหมดจะถูกบล็อกในคำขอเหล่านี้เนื่องจากคุกกี้ของบุคคลที่สามหรือคุกกี้ข้ามเว็บไซต์ต้องใช้ Secure
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ ถูกบล็อก | ⛔ ถูกบล็อก |
SameSite=Lax
|
⛔ ถูกบล็อก | ⛔ ถูกบล็อก |
SameSite=None;Secure
|
✓ อนุญาต | ⛔ ถูกบล็อก |
ฉันจะทดสอบเว็บไซต์ได้อย่างไร
เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และการรับส่งข้อความพร้อมใช้งานใน Chrome และ Firefox แล้ว
แต่จาก Chrome 86 แท็บปัญหาใน DevTools จะมีปัญหา Schemeful Same-Site รวมอยู่ด้วย คุณอาจเห็นปัญหาต่อไปนี้ที่ไฮไลต์ สำหรับเว็บไซต์ของคุณ
ปัญหาเกี่ยวกับการนําทาง
- "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้มีการส่งคุกกี้ในคำขอของเว็บไซต์เดียวกันต่อไป" - คำเตือนว่าคุกกี้จะถูกบล็อกใน Chrome เวอร์ชันในอนาคต
- "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้มีการส่งคุกกี้ในคำขอของเว็บไซต์เดียวกัน" - คำเตือนว่าคุกกี้ถูกบล็อกแล้ว
ปัญหาการโหลดทรัพยากรย่อย:
- "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้ส่งคุกกี้ไปยังทรัพยากรย่อยในเว็บไซต์เดียวกันต่อไป" หรือ "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่ออนุญาตให้ทรัพยากรย่อยในเว็บไซต์เดียวกันตั้งค่าคุกกี้ต่อไป" - คำเตือนว่าคุกกี้จะบล็อกใน Chrome เวอร์ชันในอนาคต
- "ย้ายข้อมูลทั้งหมดไปยัง HTTPS เพื่อให้ส่งคุกกี้ไปยังทรัพยากรย่อยในเว็บไซต์เดียวกัน" หรือ "ย้ายข้อมูลไปยัง HTTPS ทั้งหมดเพื่ออนุญาตให้ทรัพยากรย่อยในเว็บไซต์เดียวกันตั้งค่าคุกกี้" - คำเตือนว่าคุกกี้ถูกบล็อกไว้ คำเตือนหลังอาจปรากฏขึ้นเมื่อโพสต์แบบฟอร์ม
ดูรายละเอียดเพิ่มเติมได้ในเคล็ดลับการทดสอบและแก้ไขข้อบกพร่องสำหรับ Schemeful Same-Site
จาก Firefox 79 โดยตั้งค่า network.cookie.sameSite.schemeful
เป็น true
ผ่าน
about:config
คอนโซลจะแสดงข้อความสำหรับปัญหาเกี่ยวกับ Schemeful Same-Site
คุณอาจเห็นสิ่งต่อไปนี้บนเว็บไซต์ของคุณ
- "ระบบจะถือว่าคุกกี้
cookie_name
เร็วๆ นี้ เป็นคุกกี้ข้ามเว็บไซต์กับhttp://site.example/
เนื่องจากรูปแบบไม่ตรงกัน" - "คุกกี้
cookie_name
ได้รับถือว่าข้ามเว็บไซต์กับhttp://site.example/
เนื่องจากรูปแบบไม่ตรงกัน"
คำถามที่พบบ่อย
เว็บไซต์ของฉันพร้อมใช้งานอย่างเต็มรูปแบบบน HTTPS แล้ว เหตุใดฉันจึงเห็นปัญหาในเครื่องมือสำหรับนักพัฒนาเว็บของเบราว์เซอร์
อาจเป็นไปได้ว่าลิงก์และทรัพยากรย่อยบางส่วนของคุณยังคงชี้ไปยัง URL ที่ไม่ปลอดภัย
วิธีหนึ่งในการแก้ปัญหานี้คือการใช้ HTTP
Strict-Transport-Security (HSTS) และคำสั่ง includeSubDomain
เมื่อใช้ HSTS + includeSubDomain
แม้ว่าหน้าใดหน้าหนึ่งของคุณจะใส่ลิงก์ที่ไม่ปลอดภัยโดยไม่ตั้งใจ เบราว์เซอร์ก็จะใช้เวอร์ชันที่ปลอดภัยแทนโดยอัตโนมัติ
จะเกิดอะไรขึ้นหากฉันอัปเกรดเป็น HTTPS ไม่ได้
แม้ว่าเราจะแนะนำเป็นอย่างยิ่งให้คุณอัปเกรดเว็บไซต์ไปใช้ HTTPS ทั้งหมดเพื่อปกป้องผู้ใช้ แต่หากไม่สามารถดำเนินการด้วยตนเองได้ เราขอแนะนำให้ปรึกษาผู้ให้บริการโฮสติ้งของคุณเพื่อสอบถามว่าสามารถเสนอตัวเลือกดังกล่าวได้หรือไม่ หากคุณโฮสต์ด้วยตนเอง Let's Encrypt มีเครื่องมือจำนวนมากสำหรับติดตั้งและกำหนดค่าใบรับรอง คุณยังตรวจสอบการย้ายเว็บไซต์ตาม CDN หรือพร็อกซีอื่นๆ ที่มีการเชื่อมต่อ HTTPS ได้อีกด้วย
หากยังทำไม่ได้ ให้ลองผ่อนปรนการปกป้อง SameSite
สำหรับคุกกี้ที่ได้รับผลกระทบ
- ในกรณีที่บล็อกคุกกี้เพียง
SameSite=Strict
รายการ คุณสามารถลดการป้องกันให้เหลือเพียงLax
- ในกรณีที่บล็อกทั้งคุกกี้
Strict
และLax
และระบบส่งคุกกี้ไปยัง (หรือตั้งค่าจาก) URL ที่ปลอดภัย คุณจะลดการป้องกันเป็นNone
ได้- วิธีแก้ปัญหานี้จะไม่สำเร็จหาก URL ที่คุณส่งคุกกี้ไป (หรือตั้งค่าคุกกี้) ไม่ปลอดภัย เนื่องจาก
SameSite=None
ต้องใช้แอตทริบิวต์Secure
ในคุกกี้ ซึ่งหมายความว่าจะไม่มีการส่งหรือตั้งค่าคุกกี้เหล่านั้นผ่านการเชื่อมต่อที่ไม่ปลอดภัย ในกรณีนี้ คุณจะไม่สามารถเข้าถึงคุกกี้ดังกล่าวจนกว่าเว็บไซต์จะได้รับการอัปเกรดเป็น HTTPS - โปรดทราบว่าปัญหานี้เกิดขึ้นเพียงชั่วคราวเท่านั้น เนื่องจากคุกกี้ของบุคคลที่สามจะเลิกใช้งานอย่างสมบูรณ์ในที่สุด
- วิธีแก้ปัญหานี้จะไม่สำเร็จหาก URL ที่คุณส่งคุกกี้ไป (หรือตั้งค่าคุกกี้) ไม่ปลอดภัย เนื่องจาก
การดําเนินการนี้จะส่งผลต่อคุกกี้ของฉันอย่างไร หากฉันยังไม่ได้ระบุแอตทริบิวต์ SameSite
คุกกี้ที่ไม่มีแอตทริบิวต์ SameSite
จะได้รับการดำเนินการเหมือนกับที่ระบุ SameSite=Lax
และลักษณะการทำงานแบบข้ามรูปแบบจะมีผลกับคุกกี้เหล่านี้ด้วยเช่นกัน โปรดทราบว่าข้อยกเว้นชั่วคราวสำหรับวิธีการที่ไม่ปลอดภัยยังคงมีผล โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการบรรเทาปัญหา Lax + POST ในSameSite
คำถามที่พบบ่อยของ Chromium
WebSocket ได้รับผลกระทบอย่างไร
การเชื่อมต่อ WebSocket จะยังถือว่าเป็นเว็บไซต์เดียวกันหากมีความปลอดภัยระดับเดียวกับหน้าเว็บ
เว็บไซต์เดียวกัน:
- การเชื่อมต่อ
wss://
จากhttps://
- การเชื่อมต่อ
ws://
จากhttp://
ข้ามเว็บไซต์:
- การเชื่อมต่อ
wss://
จากhttp://
- การเชื่อมต่อ
ws://
จากhttps://
รูปภาพโดย Julissa Capdevilla ใน Unsplash