Chrome, Firefox, Edge, และเบราว์เซอร์อื่นๆ กำลังเปลี่ยนลักษณะการทำงานเริ่มต้นให้สอดคล้องกับข้อเสนอของ IETF ที่ชื่อว่า Incrementally Better Cookies เพื่อให้เป็นไปตามเงื่อนไขต่อไปนี้
- ระบบจะถือว่าคุกกี้ที่ไม่มีแอตทริบิวต์
SameSiteเป็นSameSite=Lax, ซึ่งหมายความว่าลักษณะการทำงานเริ่มต้นคือการจำกัดคุกกี้ไว้เฉพาะบริบทของบุคคลที่หนึ่ง เท่านั้น - คุกกี้สำหรับการใช้งานข้ามเว็บไซต์ต้อง ระบุ
SameSite=None; Secureเพื่อเปิดใช้การรวมในบริบทของบุคคลที่สาม
หากยังไม่ได้ดำเนินการ คุณควรอัปเดตแอตทริบิวต์สำหรับคุกกี้ของบุคคลที่สามเพื่อไม่ให้ระบบบล็อกคุกกี้เหล่านั้นในอนาคต
Browser Support
กรณีการใช้งานคุกกี้ข้ามเว็บไซต์หรือคุกกี้ของบุคคลที่สาม
มีกรณีการใช้งานและรูปแบบที่พบบ่อยจำนวนมากที่ต้องส่งคุกกี้ในบริบทของบุคคลที่สาม หากคุณให้บริการหรือใช้ประโยชน์จากกรณีการใช้งานเหล่านี้ โปรดตรวจสอบว่าคุณหรือผู้ให้บริการกำลังอัปเดตคุกกี้เพื่อให้บริการทำงานได้อย่างถูกต้อง
เนื้อหาภายใน <iframe>
เนื้อหาจากเว็บไซต์อื่นที่แสดงใน <iframe> อยู่ในบริบทของบุคคลที่สาม
กรณีการใช้งานมาตรฐานมีดังนี้
- เนื้อหาที่ฝังไว้ซึ่งแชร์จากเว็บไซต์อื่นๆ เช่น วิดีโอ แผนที่ ตัวอย่างโค้ด และโพสต์ในโซเชียล
- วิดเจ็ตจากบริการภายนอก เช่น ฟีเจอร์การชำระเงิน ปฏิทิน การจอง และการสำรอง
- วิดเจ็ต เช่น ปุ่มโซเชียลหรือบริการป้องกันการฉ้อโกงที่สร้างที่ไม่ชัดเจน
<iframes>
คุกกี้อาจใช้ที่นี่เพื่อรักษาสถานะเซสชัน จัดเก็บค่ากำหนดทั่วไป เปิดใช้สถิติ หรือปรับเปลี่ยนเนื้อหาให้เหมาะกับผู้ใช้ที่มีบัญชีอยู่แล้ว
เนื่องจากเว็บสามารถประกอบขึ้นจากส่วนต่างๆ ได้โดยธรรมชาติ <iframes> จึงใช้เพื่อฝัง
เนื้อหาที่ดูในบริบทระดับบนสุดหรือบริบทของบุคคลที่หนึ่งด้วย คุกกี้ใดๆ ที่เว็บไซต์ซึ่งแสดงใน iframe ใช้จะถือว่าเป็นคุกกี้ของบุคคลที่สาม หากคุณสร้างเว็บไซต์ที่ต้องการให้เว็บไซต์อื่นๆ ฝังไว้และต้องใช้คุกกี้เพื่อให้เว็บไซต์ทำงานได้ คุณต้องตรวจสอบด้วยว่าได้ทำเครื่องหมายคุกกี้เหล่านั้นสำหรับการใช้งานข้ามเว็บไซต์ หรือคุณสามารถกลับไปใช้เว็บไซต์ได้ตามปกติหากไม่มีคุกกี้เหล่านั้น
คำขอ "ไม่ปลอดภัย" ข้ามเว็บไซต์
คำว่า "ไม่ปลอดภัย" อาจฟังดูน่ากังวลในที่นี้ แต่หมายถึงคำขอใดๆ ที่อาจมีวัตถุประสงค์เพื่อเปลี่ยนสถานะ ในเว็บ คำขอเหล่านั้นส่วนใหญ่จะเป็นคำขอ POST ระบบจะส่งคุกกี้ที่ทำเครื่องหมายเป็น SameSite=Lax ในการนำทางระดับบนสุดที่ปลอดภัย เช่น การคลิกลิงก์เพื่อไปยังเว็บไซต์อื่น อย่างไรก็ตาม การส่ง <form> ไปยัง
เว็บไซต์อื่นโดยใช้ POST จะไม่รวมคุกกี้
รูปแบบนี้ใช้สำหรับเว็บไซต์ที่สามารถเปลี่ยนเส้นทางผู้ใช้ออกไปยังบริการระยะไกลเพื่อดำเนินการบางอย่างก่อนที่จะกลับมา เช่น การเปลี่ยนเส้นทางไปยังผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม ก่อนที่ผู้ใช้จะออกจากเว็บไซต์ ระบบจะตั้งค่าคุกกี้ที่มีโทเค็นแบบใช้ครั้งเดียว โดยคาดหวังว่าจะสามารถตรวจสอบโทเค็นนี้ในคำขอที่ส่งกลับมาเพื่อลดการโจมตีแบบCross Site Request Forgery (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
การขอความช่วยเหลือ
คุกกี้ใช้กันอย่างแพร่หลายในเว็บ และทีมพัฒนาส่วนใหญ่ไม่ทราบข้อมูลทั้งหมดเกี่ยวกับตำแหน่งที่เว็บไซต์ตั้งค่าและใช้คุกกี้ โดยเฉพาะในกรณีการใช้งานข้ามเว็บไซต์ เมื่อพบปัญหา ปัญหานั้นอาจเป็นปัญหาแรกที่พบ ดังนั้นโปรดติดต่อเรา
- แจ้งปัญหาในที่เก็บตัวอย่าง
SameSiteใน GitHub - ถามคำถามใน "samesite" แท็กใน StackOverflow
- หากพบปัญหาเกี่ยวกับลักษณะการทำงานของ Chromium ให้แจ้งข้อบกพร่องใน เครื่องมือติดตามปัญหาของ Chromium
- ติดตามความคืบหน้าของ Chrome ในหน้าการอัปเดต
SameSite