Chrome, Firefox, Edge และเบราว์เซอร์อื่นๆ กำลังเปลี่ยนลักษณะการทำงานเริ่มต้นให้สอดคล้องกับข้อเสนอของ IETF เกี่ยวกับคุกกี้ที่ดีขึ้นเรื่อยๆ เพื่อให้เกิดผลดังนี้
- ระบบจะถือว่าคุกกี้ที่ไม่มีแอตทริบิวต์
SameSite
เป็นSameSite=Lax
ซึ่งหมายความว่าลักษณะการทำงานเริ่มต้นคือการจํากัดคุกกี้ให้แสดงในบริบทของบุคคลที่หนึ่งเท่านั้น - คุกกี้สําหรับการใช้งานข้ามเว็บไซต์ต้องระบุ
SameSite=None; Secure
เพื่อเปิดใช้การรวมในบริบทของบุคคลที่สาม
คุณควรอัปเดตแอตทริบิวต์สําหรับคุกกี้ของบุคคลที่สามเพื่อไม่ให้ถูกบล็อกในอนาคต หากยังไม่ได้ดำเนินการ
กรณีการใช้งานสําหรับคุกกี้ข้ามเว็บไซต์หรือคุกกี้ของบุคคลที่สาม
มีกรณีการใช้งานและรูปแบบทั่วไปหลายรายการที่จำเป็นต้องส่งคุกกี้ในบริบทของบุคคลที่สาม หากคุณระบุหรือใช้กรณีการใช้งานอย่างใดอย่างหนึ่งเหล่านี้ โปรดตรวจสอบว่าคุณหรือผู้ให้บริการอัปเดตคุกกี้เพื่อให้บริการทำงานได้อย่างถูกต้อง
เนื้อหาภายใน <iframe>
เนื้อหาจากเว็บไซต์อื่นที่แสดงใน <iframe>
อยู่ในบริบทของบุคคลที่สาม กรณีการใช้งานมาตรฐานมีดังนี้
- เนื้อหาที่ฝังซึ่งแชร์จากเว็บไซต์อื่นๆ เช่น วิดีโอ แผนที่ ตัวอย่างโค้ด และโพสต์โซเชียล
- วิดเจ็ตจากบริการภายนอก เช่น การชำระเงิน ปฏิทิน การจอง และฟีเจอร์การจอง
- วิดเจ็ต เช่น ปุ่มโซเชียลหรือบริการป้องกันการประพฤติมิชอบซึ่งทำให้ผู้ใช้สังเกตเห็นได้น้อยลง
<iframes>
คุกกี้อาจใช้เพื่อคงสถานะเซสชัน จัดเก็บค่ากําหนดทั่วไป เปิดใช้สถิติ หรือปรับเปลี่ยนเนื้อหาในแบบของคุณสําหรับผู้ใช้ที่มีบัญชีอยู่แล้ว
เนื่องจากเว็บเป็นแพลตฟอร์มที่ประกอบกันได้อยู่แล้ว <iframes>
จึงใช้เพื่อฝังเนื้อหาที่ดูในบริบทระดับบนสุดหรือบริบทของบุคคลที่หนึ่งด้วย คุกกี้ที่เว็บไซต์แสดงใน iframe จะใช้คุกกี้ของบุคคลที่สาม หากคุณสร้างเว็บไซต์ที่ต้องการให้เว็บไซต์อื่นๆ ฝังและต้องการใช้คุกกี้เพื่อให้เว็บไซต์ทำงานได้ คุณจะต้องตรวจสอบด้วยว่าเว็บไซต์เหล่านั้นมีการทำเครื่องหมายสำหรับการใช้งานข้ามเว็บไซต์ หรือคุณมีวิธีเปลี่ยนเส้นทางอย่างราบรื่นหากไม่มีคุกกี้
คำขอที่ "ไม่ปลอดภัย" ในเว็บไซต์ต่างๆ
"ไม่ปลอดภัย" อาจฟังดูน่ากังวล แต่คำนี้หมายถึงคำขอที่อาจมีเจตนาเปลี่ยนแปลงสถานะ บนเว็บ คำขอดังกล่าวคือคำขอ POST เป็นหลัก ระบบจะส่งคุกกี้ที่มีการทำเครื่องหมายเป็น SameSite=Lax
ในการนําทางระดับบนสุดที่ปลอดภัย เช่น การคลิกลิงก์เพื่อไปยังเว็บไซต์อื่น อย่างไรก็ตาม การดำเนินการบางอย่าง เช่น <form>
การส่งไปยังเว็บไซต์อื่นโดยใช้ POST จะไม่รวมคุกกี้
รูปแบบนี้ใช้สำหรับเว็บไซต์ที่เปลี่ยนเส้นทางผู้ใช้ไปยังบริการระยะไกลเพื่อดำเนินการบางอย่างก่อนที่จะกลับมา เช่น การเปลี่ยนเส้นทางไปยังผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม ก่อนที่ผู้ใช้จะออกจากเว็บไซต์ ระบบจะตั้งค่าคุกกี้ที่มีโทเค็นแบบใช้ครั้งเดียว โดยคาดหวังว่าจะตรวจสอบโทเค็นนี้ได้ในคําขอที่ส่งกลับเพื่อลดการโจมตีการปลอมแปลงคําขอข้ามเว็บไซต์ (CSRF) หากคำขอที่ส่งกลับนั้นมาผ่าน POST คุณจะต้องทําเครื่องหมายคุกกี้เป็น SameSite=None; Secure
ทรัพยากรระยะไกล
ทรัพยากรระยะไกลในหน้าเว็บ เช่น จากแท็ก <img>
หรือแท็ก <script>
อาจใช้คุกกี้ที่ส่งไปพร้อมกับคําขอ กรณีการใช้งานที่พบได้ทั่วไป ได้แก่ พิกเซลการติดตามและการปรับเปลี่ยนเนื้อหาในแบบของคุณ
ซึ่งจะมีผลกับคําขอที่ส่งจาก JavaScript โดยใช้ fetch
หรือ
XMLHttpRequest
ด้วย หากเรียก fetch()
ด้วยตัวเลือก credentials: 'include'
คำขอเหล่านั้นมีแนวโน้มที่จะรวมคุกกี้
สําหรับ XMLHttpRequest
คุกกี้ที่คาดไว้มักจะระบุด้วยค่า withCredentials
ของ true
คุกกี้เหล่านั้นต้องได้รับการทําเครื่องหมายอย่างเหมาะสมเพื่อให้รวมอยู่ในคําขอข้ามเว็บไซต์
เนื้อหาภายใน WebView
WebView ในแอปเฉพาะแพลตฟอร์มจะทำงานด้วยเบราว์เซอร์ นักพัฒนาแอปต้องทดสอบว่าข้อจำกัดหรือปัญหาที่ส่งผลกระทบต่อแอปมีผลกับ WebView ของแอปด้วยหรือไม่
นอกจากนี้ Android ยังอนุญาตให้แอปเฉพาะแพลตฟอร์มตั้งค่าคุกกี้ได้โดยตรงโดยใช้ CookieManager API
เช่นเดียวกับคุกกี้ที่ตั้งค่าโดยใช้ส่วนหัวหรือ JavaScript ให้พิจารณารวม SameSite=None; Secure
ไว้ด้วยหากมีไว้เพื่อการใช้งานข้ามเว็บไซต์
วิธีติดตั้งใช้งาน SameSite
วันนี้
ทําเครื่องหมายคุกกี้ที่จําเป็นในบริบทของบุคคลที่หนึ่งเท่านั้นเป็น SameSite=Lax
หรือ SameSite=Strict
ตามต้องการ หากคุณไม่ได้ทําเครื่องหมายคุกกี้เหล่านี้และอาศัยลักษณะการทํางานเริ่มต้นของเบราว์เซอร์เพื่อจัดการแทน คุกกี้อาจทํางานอย่างไม่สอดคล้องกันในเบราว์เซอร์ต่างๆ และอาจทริกเกอร์คําเตือนในคอนโซลสําหรับคุกกี้แต่ละรายการ
Set-Cookie: first_party_var=value; SameSite=Lax
อย่าลืมทําเครื่องหมายคุกกี้ที่จําเป็นในบริบทของบุคคลที่สามเป็น SameSite=None; Secure
โดยต้องระบุแอตทริบิวต์ทั้ง 2 รายการ หากคุณระบุแค่ None
โดยไม่ระบุ Secure
ระบบจะปฏิเสธคุกกี้ คุณอาจต้องใช้กลยุทธ์การบรรเทาผลกระทบบางอย่างที่อธิบายไว้ในจัดการไคลเอ็นต์ที่เข้ากันไม่ได้เพื่อพิจารณาความแตกต่างในการใช้งานเบราว์เซอร์
Set-Cookie: third_party_var=value; SameSite=None; Secure
จัดการไคลเอ็นต์ที่ใช้ร่วมกันไม่ได้
เนื่องจากการเปลี่ยนแปลงเหล่านี้เพื่อรวม None
และอัปเดตลักษณะการทำงานเริ่มต้นยังค่อนข้างใหม่ เบราว์เซอร์แต่ละรุ่นจึงจัดการการเปลี่ยนแปลงเหล่านี้แตกต่างกันไป คุณสามารถไปที่หน้าอัปเดตใน chromium.org เพื่อดูรายการปัญหาที่ทราบ แต่รายการนี้อาจไม่ครอบคลุมทั้งหมด
วิธีแก้ปัญหาที่เป็นไปได้อย่างหนึ่งคือการตั้งค่าคุกกี้แต่ละรายการทั้งในรูปแบบใหม่และแบบเก่า ดังนี้
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
เบราว์เซอร์ที่ใช้ลักษณะการทํางานแบบใหม่จะตั้งค่าคุกกี้ด้วยค่า SameSite
เบราว์เซอร์ที่ไม่ได้ใช้ลักษณะการทำงานใหม่จะละเว้นค่าดังกล่าวและตั้งค่าคุกกี้ 3pcookie-legacy
เมื่อประมวลผลคุกกี้ที่รวมไว้ เว็บไซต์ควรตรวจสอบก่อนว่ามีคุกกี้รูปแบบใหม่หรือไม่ จากนั้นจึงเปลี่ยนไปใช้คุกกี้เดิมหากไม่พบคุกกี้ใหม่
ตัวอย่างต่อไปนี้แสดงวิธีดำเนินการใน Node.js โดยใช้เฟรมเวิร์ก Express และมิดเดิลแวร์ cookie-parser
const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());
app.get('/set', (req, res) => {
// Set the new style cookie
res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
// And set the same value in the legacy cookie
res.cookie('3pcookie-legacy', 'value', { secure: true });
res.end();
});
app.get('/', (req, res) => {
let cookieVal = null;
if (req.cookies['3pcookie']) {
// check the new style cookie first
cookieVal = req.cookies['3pcookie'];
} else if (req.cookies['3pcookie-legacy']) {
// otherwise fall back to the legacy cookie
cookieVal = req.cookies['3pcookie-legacy'];
}
res.end();
});
app.listen(process.env.PORT);
วิธีนี้ทําให้คุณต้องทํางานเพิ่มในการตั้งค่าคุกกี้ที่ซ้ำซ้อนและทําการเปลี่ยนแปลงทั้งเมื่อตั้งค่าและอ่านคุกกี้ อย่างไรก็ตาม ควรจะครอบคลุมเบราว์เซอร์ทั้งหมดโดยไม่คำนึงถึงลักษณะการทำงาน และทำให้คุกกี้ของบุคคลที่สามทำงานต่อไปได้
หรือจะตรวจหาไคลเอ็นต์โดยใช้สตริง User Agent เมื่อมีการส่งส่วนหัว Set-Cookie
ก็ได้ โปรดดูรายการไคลเอ็นต์ที่เข้ากันไม่ได้ และใช้ไลบรารีการตรวจหา User Agent ที่เหมาะสมสำหรับแพลตฟอร์มของคุณ เช่น ไลบรารี ua-parser-js ใน Node.js วิธีนี้กำหนดให้คุณทำการเปลี่ยนแปลงเพียงครั้งเดียว แต่การสแกน User Agent อาจไม่พบผู้ใช้ที่ได้รับผลกระทบทั้งหมด
การรองรับ SameSite=None
ในภาษา ไลบรารี และเฟรมเวิร์ก
ภาษาและไลบรารีส่วนใหญ่รองรับแอตทริบิวต์ SameSite
สําหรับคุกกี้ อย่างไรก็ตาม เนื่องจากการเพิ่ม SameSite=None
เพิ่งเกิดขึ้นเมื่อไม่นานมานี้ คุณจึงอาจต้องปรับเปลี่ยนลักษณะการทํางานบางอย่างที่เป็นมาตรฐานในตอนนี้
ลักษณะการทำงานเหล่านี้มีการบันทึกไว้ในSameSite
ที่เก็บตัวอย่างใน GitHub
การขอความช่วยเหลือ
คุกกี้มีการใช้งานในทุกที่บนเว็บ และทีมพัฒนาซอฟต์แวร์แทบจะไม่มีความรู้ที่สมบูรณ์เกี่ยวกับตําแหน่งที่เว็บไซต์ตั้งค่าและใช้คุกกี้ โดยเฉพาะใน Use Case แบบข้ามเว็บไซต์ เมื่อพบปัญหา อาจเป็นปัญหาที่ไม่มีใครพบมาก่อน ดังนั้นโปรดติดต่อเรา
- แจ้งปัญหาใน
SameSite
ที่เก็บตัวอย่างใน GitHub - ถามคำถามในแท็ก"samesite" ใน StackOverflow
- หากพบปัญหาเกี่ยวกับลักษณะการทํางานของ Chromium โปรดรายงานข้อบกพร่องในเครื่องมือติดตามปัญหาของ Chromium
- ติดตามความคืบหน้าของ Chrome ใน
หน้าการอัปเดต
SameSite