หน้านี้จะสรุปแนวทางปฏิบัติแนะนำในการตั้งค่านโยบายผู้อ้างอิงและการใช้ URL ที่มาในคำขอที่ส่งเข้ามา
สรุป
- การรั่วไหลของข้อมูลข้ามต้นทางที่ไม่คาดคิดทำลายความเป็นส่วนตัวของผู้ใช้เว็บ นโยบาย URL ที่มาที่มีการปกป้องสามารถช่วยได้
- ลองตั้งค่านโยบาย URL ที่มาเป็น
strict-origin-when-cross-origin
โดยจะช่วยรักษาประโยชน์ส่วนใหญ่ของผู้อ้างอิง พร้อมกับลดความเสี่ยงในการรั่วไหลของข้อมูลข้ามต้นทาง - อย่าใช้ URL ที่มาในการป้องกันการปลอมแปลงคําขอแบบข้ามเว็บไซต์ (CSRF) โปรดใช้โทเค็น CSRF แทน และใช้ส่วนหัวอื่นๆ เพื่อเพิ่มความปลอดภัยอีกชั้นหนึ่ง
URL ที่มาและนโยบายผู้อ้างอิง 101
คำขอ HTTP อาจมีส่วนหัว Referer
ที่ไม่บังคับ ซึ่งระบุต้นทางหรือ URL ของหน้าเว็บที่เป็นต้นทางของคำขอ ส่วนหัว Referrer-Policy
จะกำหนดข้อมูลที่พร้อมใช้งานในส่วนหัว Referer
ในตัวอย่างต่อไปนี้ ส่วนหัว Referer
มี URL ที่สมบูรณ์ของหน้าเว็บใน site-one
ซึ่งเป็นแหล่งที่มาของคำขอ
ส่วนหัว Referer
อาจปรากฏในคำขอประเภทต่างๆ ดังนี้
- คำขอการนำทางเมื่อผู้ใช้คลิกลิงก์
- ขอทรัพยากรย่อยเมื่อเบราว์เซอร์ขอรูปภาพ, iframe, สคริปต์ และทรัพยากรอื่นๆ ที่หน้าเว็บต้องการ
สำหรับการนำทางและ iframe คุณยังเข้าถึงข้อมูลนี้ด้วย JavaScript โดยใช้ document.referrer
ได้ด้วย
คุณเรียนรู้ได้มากมายจากค่า Referer
ยกตัวอย่างเช่น บริการข้อมูลวิเคราะห์อาจใช้ข้อมูลดังกล่าวในการพิจารณาว่า 50% ของผู้เข้าชมบน site-two.example
มาจาก social-network.example
แต่เมื่อมีการส่ง URL แบบเต็มซึ่งรวมถึงเส้นทางและสตริงคำค้นหาใน Referer
ระหว่างต้นทาง ก็อาจเป็นอันตรายต่อความเป็นส่วนตัวของผู้ใช้และทำให้เกิดความเสี่ยงด้านความปลอดภัย
URL #1 ถึง #5 มีข้อมูลส่วนบุคคล และบางครั้งอาจมีความละเอียดอ่อนหรือข้อมูลระบุตัวตน การรั่วไหลเหล่านี้ไปยังต้นทางต่างๆ อย่างเงียบๆ อาจส่งผลต่อความเป็นส่วนตัวของผู้ใช้เว็บได้
URL #6 คือ URL ความสามารถ หากผู้ใดนอกเหนือจากผู้ใช้ที่กำหนดได้รับการแจ้งเตือน ผู้ไม่ประสงค์ดีอาจเข้าควบคุมบัญชีของผู้ใช้รายนี้ได้
หากต้องการจำกัดข้อมูล URL ที่มาสำหรับคำขอจากเว็บไซต์ คุณตั้งค่านโยบาย URL ที่มาได้
นโยบายที่ใช้ได้และแตกต่างกันอย่างไร
คุณสามารถเลือกนโยบายข้อใดข้อหนึ่งจาก 8 ข้อ ข้อมูลที่พร้อมใช้งานจากส่วนหัว Referer
(และ document.referrer
) อาจมีลักษณะดังนี้ ทั้งนี้ขึ้นอยู่กับนโยบาย
- ไม่มีข้อมูล (ไม่มีส่วนหัว
Referer
) - เฉพาะต้นทาง
- URL แบบเต็ม: ต้นทาง เส้นทาง และสตริงการค้นหา
นโยบายบางอย่างออกแบบมาให้ทำงานแตกต่างกันตามบริบท ซึ่งได้แก่ คำขอแบบข้ามต้นทางหรือต้นทางเดียวกัน ไม่ว่าปลายทางคำขอจะปลอดภัยเท่ากับต้นทาง หรือทั้ง 2 คำขอ วิธีนี้มีประโยชน์ในการจำกัดจำนวนข้อมูลที่แชร์ระหว่างต้นทางหรือต้นทางที่มีความปลอดภัยน้อย ขณะที่ยังคงรักษาความสมบูรณ์ของ URL ที่มาภายในเว็บไซต์ของคุณเอง
ตารางต่อไปนี้แสดงวิธีที่นโยบาย URL ที่มาจำกัดข้อมูล URL ที่พร้อมใช้งานจากส่วนหัวของผู้อ้างอิงและ document.referrer
ขอบเขตนโยบาย | ชื่อนโยบาย | ผู้อ้างอิง: ไม่มีข้อมูล | URL ที่มา: ต้นทางเท่านั้น | ผู้อ้างอิง: URL แบบเต็ม |
---|---|---|---|---|
ไม่พิจารณาบริบทคำขอ | no-referrer |
เช็ค | ||
origin |
เช็ค | |||
unsafe-url |
เช็ค | |||
มุ่งเน้นความปลอดภัย | strict-origin |
คำขอจาก HTTPS ไปยัง HTTP | คำขอจาก HTTPS ไปยัง HTTPS หรือจาก HTTP ไปยัง HTTP |
|
no-referrer-when-downgrade |
คำขอจาก HTTPS ไปยัง HTTP | คำขอจาก HTTPS ไปยัง HTTPS หรือจาก HTTP ไปยัง HTTP |
||
มุ่งเน้นความเป็นส่วนตัว | origin-when-cross-origin |
คำขอข้ามต้นทาง | คำขอที่มาจากแหล่งเดียวกัน | |
same-origin |
คำขอข้ามต้นทาง | คำขอที่มาจากแหล่งเดียวกัน | ||
เน้นความเป็นส่วนตัวและความปลอดภัย | strict-origin-when-cross-origin |
คำขอจาก HTTPS ไปยัง HTTP | คำขอข้ามต้นทาง จาก HTTPS เป็น HTTPS หรือจาก HTTP เป็น HTTP |
คำขอที่มาจากแหล่งเดียวกัน |
MDN มีรายการนโยบายและตัวอย่างพฤติกรรมทั้งหมด
ต่อไปนี้เป็นสิ่งที่ควรทราบเมื่อตั้งค่านโยบาย URL ที่มา
- นโยบายทั้งหมดที่พิจารณาสคีม (HTTPS กับ HTTP) (
strict-origin
,no-referrer-when-downgrade
และstrict-origin-when-cross-origin
) จะจัดการกับคำขอจากต้นทาง HTTP หนึ่งไปยังต้นทาง HTTP อื่นในลักษณะเดียวกันกับคำขอจากต้นทาง HTTPS ไปยังต้นทาง HTTPS อื่น แม้ว่า HTTP จะมีความปลอดภัยน้อยกว่าก็ตาม นั่นเป็นเพราะสำหรับนโยบายเหล่านี้ สิ่งสำคัญคือจะมีการดาวน์เกรดความปลอดภัยหรือไม่ กล่าวคือ หากคำขอเปิดเผยข้อมูลจากต้นทางที่เข้ารหัสไปยังต้นทางที่ไม่ได้เข้ารหัสได้ เช่น ใน HTTPS → คำขอ HTTP คำขอ HTTP → HTTP ไม่ได้เข้ารหัสอย่างสมบูรณ์ จึงไม่มีการดาวน์เกรด - หากคำขอเป็นแบบต้นทางเดียวกัน แสดงว่ารูปแบบ (HTTPS หรือ HTTP) เหมือนกัน จึงไม่มีการดาวน์เกรดความปลอดภัย
นโยบาย URL ที่มาเริ่มต้นในเบราว์เซอร์
ข้อมูล ณ เดือนตุลาคม 2021
หากไม่ได้ตั้งค่านโยบาย URL ที่มา เบราว์เซอร์จะใช้นโยบายเริ่มต้น
เบราว์เซอร์ | Referrer-Policy / ลักษณะการทำงานเริ่มต้น |
---|---|
Chrome |
โดยมีค่าเริ่มต้นเป็น strict-origin-when-cross-origin
|
Firefox |
โดยมีค่าเริ่มต้นเป็น strict-origin-when-cross-origin ตั้งแต่เวอร์ชัน 93 เป็นต้นไป สําหรับผู้ใช้ที่มีการป้องกันการติดตามแบบเข้มงวดและการเรียกดูแบบส่วนตัว ระบบจะไม่สนใจนโยบาย URL ที่มาซึ่งมีการจำกัดน้อยกว่า no-referrer-when-downgrade , origin-when-cross-origin และ unsafe-url สำหรับคำขอข้ามเว็บไซต์ ซึ่งหมายความว่าระบบจะตัด URL ที่มาสำหรับคำขอข้ามเว็บไซต์เสมอ ไม่ว่านโยบายของเว็บไซต์จะเป็นนโยบายใดก็ตาม
|
Edge |
โดยมีค่าเริ่มต้นเป็น strict-origin-when-cross-origin
|
Safari |
ค่าเริ่มต้นคือ strict-origin-when-cross-origin แต่มีความแตกต่างกันบางอย่างอยู่ ดูรายละเอียดได้ที่
การป้องกันการติดตามการป้องกัน
|
แนวทางปฏิบัติแนะนำในการตั้งค่านโยบาย URL ที่มา
การตั้งค่านโยบาย URL ที่มาสำหรับเว็บไซต์ของคุณทำได้หลายวิธี ดังนี้
- เป็นส่วนหัว HTTP
- ภายใน HTML
- จาก JavaScript แบบตามคำขอ
คุณกำหนดนโยบายที่แตกต่างกันให้กับหน้าเว็บ คำขอ หรือองค์ประกอบต่างๆ ได้
ส่วนหัว HTTP และองค์ประกอบเมตาเป็นทั้ง 2 ระดับหน้า ลำดับความสำคัญในการกําหนดนโยบายที่มีผลขององค์ประกอบมีดังนี้
- นโยบายระดับองค์ประกอบ
- นโยบายระดับหน้าเว็บ
- ค่าเริ่มต้นของเบราว์เซอร์
ตัวอย่างเช่น
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
มีการขอรูปภาพโดยใช้นโยบาย no-referrer-when-downgrade
และคำขอทรัพยากรย่อยอื่นๆ ทั้งหมดจากหน้านี้เป็นไปตามนโยบาย strict-origin-when-cross-origin
วิธีการดูนโยบาย URL ที่มา
securityheaders.com มีประโยชน์ในการพิจารณาว่าเว็บไซต์หรือหน้าเว็บนั้นๆ ใช้นโยบายใด
คุณยังใช้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ใน Chrome, Edge หรือ Firefox เพื่อดูนโยบาย URL ที่มาที่ใช้กับคําขอหนึ่งๆ ได้อีกด้วย ขณะที่เขียนข้อมูลนี้ Safari จะไม่แสดงส่วนหัว Referrer-Policy
แต่แสดง Referer
ที่ส่งไป
คุณควรกำหนดนโยบายใดสำหรับเว็บไซต์ของคุณ
เราขอแนะนำอย่างยิ่งให้ตั้งค่านโยบายปรับปรุงความเป็นส่วนตัวให้ชัดเจน เช่น strict-origin-when-cross-origin
(หรือเข้มงวดขึ้น)
เหตุใดจึงต้อง "ชัดเจน"
หากคุณไม่ได้ตั้งค่านโยบาย URL ที่มา ระบบจะใช้นโยบายเริ่มต้นของเบราว์เซอร์ ซึ่งอันที่จริงแล้ว เว็บไซต์มักจะเลื่อนไปตามค่าเริ่มต้นของเบราว์เซอร์ แต่วิธีนี้ไม่ใช่วิธีที่ดีที่สุด เนื่องจากสาเหตุต่อไปนี้
- เบราว์เซอร์ต่างๆ มีนโยบายเริ่มต้นแตกต่างกัน ดังนั้นหากคุณใช้ค่าเริ่มต้นของเบราว์เซอร์ เว็บไซต์จะไม่ทำงานตามการคาดการณ์ในเบราว์เซอร์ต่างๆ
- เบราว์เซอร์กำลังใช้ค่าเริ่มต้นที่เข้มงวดมากขึ้น เช่น
strict-origin-when-cross-origin
และกลไกต่างๆ เช่น การตัด URL ที่มาสำหรับคำขอข้ามต้นทาง การเลือกใช้นโยบายปรับปรุงความเป็นส่วนตัวอย่างชัดแจ้งก่อนที่การเปลี่ยนแปลงค่าเริ่มต้นของเบราว์เซอร์จะช่วยให้คุณควบคุมและทำการทดสอบได้ตามความเหมาะสม
ทำไมจึงต้องใช้ strict-origin-when-cross-origin
(หรือเข้มงวดกว่า)
คุณต้องมีนโยบายที่ปลอดภัย ปรับปรุงความเป็นส่วนตัว และมีประโยชน์ สิ่งที่ "มีประโยชน์" ขึ้นอยู่กับสิ่งที่คุณต้องการจากผู้บอกต่อ ดังนี้
- ปลอดภัย: หากเว็บไซต์ใช้ HTTPS (หากไม่มี ให้จัดลำดับความสำคัญ) คุณไม่ต้องการให้ URL ของเว็บไซต์รั่วไหลในคำขอที่ไม่ใช่ HTTPS เนื่องจากทุกคนในเครือข่ายจะเห็นข้อมูลเหล่านี้ การรั่วไหลจึงอาจทำให้ผู้ใช้ถูกโจมตีแบบแทรกกลางการสื่อสาร นโยบาย
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
และstrict-origin
แก้ไขปัญหานี้ - การเพิ่มประสิทธิภาพให้ความเป็นส่วนตัว: สำหรับคำขอข้ามต้นทาง
no-referrer-when-downgrade
จะแชร์ URL แบบเต็ม ซึ่งอาจก่อให้เกิดปัญหาด้านความเป็นส่วนตัวstrict-origin-when-cross-origin
และstrict-origin
แชร์เฉพาะต้นทางเท่านั้น และno-referrer
ไม่ได้แชร์อะไรเลย การดำเนินการนี้จะทำให้คุณมีตัวเลือกในการเพิ่มความเป็นส่วนตัวด้วยstrict-origin-when-cross-origin
,strict-origin
และno-referrer
- มีประโยชน์:
no-referrer
และstrict-origin
จะไม่แชร์ URL แบบเต็ม แม้ว่าจะเป็นคำขอต้นทางเดียวกันก็ตาม หากคุณต้องการ URL แบบเต็มstrict-origin-when-cross-origin
ซึ่งเป็นตัวเลือกที่ดีกว่า
ซึ่งหมายความว่าโดยทั่วไป strict-origin-when-cross-origin
จะเป็นตัวเลือกที่เหมาะสม
ตัวอย่าง: การตั้งค่านโยบาย strict-origin-when-cross-origin
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
หรือฝั่งเซิร์ฟเวอร์ เช่น ใน Express
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
จะเกิดอะไรขึ้นหาก strict-origin-when-cross-origin
(หรือเข้มงวดกว่า) ไม่เป็นไปตามกรณีการใช้งานทั้งหมดของคุณ
ในกรณีนี้ ให้ใช้แนวทางแบบค่อยเป็นค่อยไป กล่าวคือตั้งค่านโยบายการป้องกัน เช่น strict-origin-when-cross-origin
สำหรับเว็บไซต์ของคุณ และนโยบายที่ผ่อนปรนมากขึ้นสำหรับคำขอหรือองค์ประกอบ HTML หนึ่งๆ หากจำเป็น
ตัวอย่าง: นโยบายระดับองค์ประกอบ
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 อาจกำหนดขีดจำกัด document.referrer
หรือส่วนหัว Referer
สำหรับคำขอแบบข้ามเว็บไซต์
ดูรายละเอียด
ตัวอย่าง: นโยบายระดับคำขอ
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
คุณควรพิจารณาสิ่งใดอีกบ้าง
นโยบายของคุณควรขึ้นอยู่กับเว็บไซต์และกรณีการใช้งาน ตามที่คุณ ทีมงาน และบริษัทของคุณระบุไว้ หาก URL บางรายการมีข้อมูลระบุตัวตนหรือข้อมูลที่ละเอียดอ่อน ให้กำหนดนโยบายการป้องกัน
แนวทางปฏิบัติแนะนำสำหรับคำขอที่เข้ามาใหม่
ต่อไปนี้เป็นหลักเกณฑ์บางประการสำหรับสิ่งที่ต้องทำหากเว็บไซต์ของคุณใช้ URL ผู้อ้างอิงของคำขอที่เข้ามา
ปกป้องข้อมูลของผู้ใช้
Referer
อาจมีข้อมูลส่วนตัว ข้อมูลส่วนตัว หรือข้อมูลที่ใช้ระบุตัวบุคคลได้ ดังนั้นโปรดตรวจสอบว่าคุณใช้ข้อมูลนี้
ผู้อ้างอิงที่เข้ามาสามารถเปลี่ยนแปลง {referer-can-change}
การใช้ URL ที่มาจากคำขอข้ามต้นทางขาเข้ามีข้อจำกัดบางประการดังนี้
- หากไม่มีสิทธิ์ควบคุมการใช้งานตัวปล่อยคำขอ คุณจะคาดเดาเกี่ยวกับส่วนหัว
Referer
(และdocument.referrer
) ที่ได้รับไม่ได้ ผู้ปล่อยคำขออาจตัดสินใจเปลี่ยนไปใช้นโยบายno-referrer
ได้ทุกเมื่อ หรือโดยทั่วไปจะใช้นโยบายที่เข้มงวดกว่าที่ใช้ก่อนหน้านี้ ซึ่งหมายความว่าคุณจะได้รับข้อมูลจากReferer
น้อยลงกว่าเดิม - เบราว์เซอร์ต่างๆ ใช้นโยบาย Referrer-Policy
strict-origin-when-cross-origin
มากขึ้นโดยค่าเริ่มต้น ซึ่งหมายความว่าตอนนี้คุณอาจได้รับเฉพาะต้นทางเท่านั้น แทนที่จะได้รับ URL แบบเต็มของ URL ที่มา ในคำขอแบบข้ามต้นทางที่เข้ามา หากเว็บไซต์ของผู้ส่งไม่ได้กำหนดนโยบายไว้ - เบราว์เซอร์อาจเปลี่ยนแปลงวิธีจัดการ
Referer
เช่น นักพัฒนาซอฟต์แวร์เบราว์เซอร์บางรายอาจเลือกที่จะตัด URL ที่มากับต้นทางในคำขอทรัพยากรย่อยแบบข้ามต้นทางเสมอ เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ - ส่วนหัว
Referer
(และdocument.referrer
) อาจมีข้อมูลมากกว่าที่คุณต้องการ เช่น อาจมี URL แบบเต็มเมื่อคุณต้องการทราบเพียงว่าคําขอเป็นแบบข้ามต้นทางหรือไม่
วิธีอื่นๆ ที่ใช้แทน Referer
คุณอาจต้องพิจารณาใช้ทางเลือกอื่นในกรณีต่อไปนี้
- ฟีเจอร์สำคัญของเว็บไซต์ใช้ URL ผู้อ้างอิงของคำขอข้ามต้นทางขาเข้า
- เว็บไซต์ไม่ได้รับส่วนของ URL ผู้อ้างอิงที่จำเป็นต้องใช้ในคำขอข้ามต้นทางอีกต่อไป ซึ่งจะเกิดขึ้นเมื่อผู้ปล่อยคำขอเปลี่ยนนโยบาย หรือเมื่อไม่ได้ตั้งค่านโยบายและนโยบายเริ่มต้นของเบราว์เซอร์มีการเปลี่ยนแปลง (อย่างเช่นใน Chrome 85)
หากต้องการกำหนดทางเลือก ให้วิเคราะห์ส่วนของผู้อ้างอิงที่คุณกำลังใช้งาน
ถ้าต้องการเฉพาะต้นทาง
- หากคุณใช้ URL ที่มาในสคริปต์ที่มีสิทธิ์เข้าถึงหน้าเว็บระดับสูงสุด
window.location.origin
จะเป็นอีกตัวเลือกหนึ่ง - ส่วนหัวอย่าง
Origin
และSec-Fetch-Site
จะแสดงOrigin
หรืออธิบายว่าคำขอเป็นแบบข้ามต้นทางหรือไม่ ซึ่งอาจเป็นสิ่งที่คุณต้องการจริงๆ
หากคุณต้องการองค์ประกอบอื่นๆ ของ URL (เส้นทาง พารามิเตอร์การค้นหา...)
- พารามิเตอร์คำขออาจจัดการกรณีการใช้งานของคุณ ซึ่งช่วยให้คุณไม่ต้องแยกวิเคราะห์ URL ที่มา
- หากคุณใช้ URL ที่มาในสคริปต์ที่มีสิทธิ์เข้าถึงหน้าเว็บระดับสูงสุด
window.location.pathname
อาจทํางานแทน ดึงเฉพาะส่วนเส้นทางของ URL แล้วส่งต่อเป็นอาร์กิวเมนต์ เพื่อไม่ให้มีการส่งข้อมูลที่อาจมีความละเอียดอ่อนในพารามิเตอร์ของ URL
หากใช้ทางเลือกเหล่านี้ไม่ได้ ให้ทำดังนี้
- ตรวจสอบว่าคุณสามารถเปลี่ยนระบบเพื่อให้ตัวปล่อยคำขอ (เช่น
site-one.example
) ตั้งค่าข้อมูลที่คุณต้องการอย่างชัดเจนในการกำหนดค่าประเภทได้หรือไม่- ข้อดี: ชัดเจนมากขึ้น รักษาความเป็นส่วนตัวได้มากขึ้นสำหรับผู้ใช้
site-one.example
และรองรับอนาคตมากกว่า - ข้อเสีย: อาจมีงานเพิ่มขึ้นจากฝั่งของคุณหรือผู้ใช้ของระบบ
- ข้อดี: ชัดเจนมากขึ้น รักษาความเป็นส่วนตัวได้มากขึ้นสำหรับผู้ใช้
- ตรวจสอบว่าเว็บไซต์ที่ปล่อยคำขออาจยอมรับที่จะตั้งค่านโยบาย URL ที่มาตามองค์ประกอบหรือต่อคำขอเป็น
no-referrer-when-downgrade
- ข้อเสีย: อาจรักษาความเป็นส่วนตัวได้น้อยลงสำหรับผู้ใช้
site-one.example
ซึ่งอาจไม่มีการรองรับในบางเบราว์เซอร์
- ข้อเสีย: อาจรักษาความเป็นส่วนตัวได้น้อยลงสำหรับผู้ใช้
การป้องกันการปลอมแปลงคำขอแบบข้ามเว็บไซต์ (CSRF)
ผู้ปล่อยคำขอตัดสินใจได้เสมอว่าจะไม่ส่ง URL ที่มาโดยการตั้งค่านโยบาย no-referrer
และผู้ดำเนินการที่เป็นอันตรายอาจปลอมแปลง URL ที่มาได้
ใช้โทเค็น CSRF
เป็นการปกป้องหลัก เพิ่มการปกป้องอีกระดับโดยใช้ SameSite และแทนที่จะใช้ Referer
ให้ใช้ส่วนหัว เช่น Origin
(ใช้ได้กับคำขอ POST และ CORS) และ Sec-Fetch-Site
(หากมี)
บันทึกและแก้ไขข้อบกพร่อง
โปรดปกป้องข้อมูลส่วนบุคคลหรือข้อมูลที่ละเอียดอ่อนของผู้ใช้ที่อาจอยู่ใน Referer
หากคุณใช้เฉพาะต้นทาง ให้ตรวจสอบว่าคุณสามารถใช้ส่วนหัว Origin
เป็นทางเลือกได้หรือไม่ วิธีนี้จะช่วยให้คุณมีข้อมูลที่จําเป็นในการแก้ไขข้อบกพร่องได้ง่ายขึ้นและไม่จําเป็นต้องแยกวิเคราะห์ URL ที่มา
การชำระเงิน
ผู้ให้บริการชำระเงินอาจใช้ส่วนหัว Referer
ของคำขอที่เข้ามาใหม่เพื่อตรวจสอบความปลอดภัย
เช่น
- ผู้ใช้คลิกปุ่มซื้อใน
online-shop.example/cart/checkout
online-shop.example
เปลี่ยนเส้นทางไปยังpayment-provider.example
เพื่อจัดการธุรกรรมpayment-provider.example
ตรวจสอบReferer
ของคำขอนี้เทียบกับรายการค่าReferer
ที่อนุญาตซึ่งผู้ขายตั้งค่าไว้ หากไม่ตรงกับชื่อในรายการpayment-provider.example
จะปฏิเสธคำขอ หากตรงกัน ผู้ใช้ก็สามารถทำธุรกรรมได้
แนวทางปฏิบัติแนะนำสำหรับการตรวจสอบความปลอดภัยของขั้นตอนการชำระเงิน
ในฐานะผู้ให้บริการชำระเงิน คุณใช้ Referer
เป็นการตรวจสอบเบื้องต้นเพื่อป้องกันการโจมตีบางอย่างได้ แต่ส่วนหัว Referer
เพียงอย่างเดียวยังขาดความน่าเชื่อถือในการตรวจสอบ เว็บไซต์ที่ส่งคำขอไม่ว่าจะเป็นผู้ขายที่ถูกต้องหรือไม่ก็ตาม สามารถกำหนดนโยบาย no-referrer
ที่ทำให้ผู้ให้บริการชำระเงินไม่มีข้อมูล Referer
ได้
การตรวจสอบ Referer
อาจช่วยให้ผู้ให้บริการชำระเงินตรวจจับผู้บุกรุกที่ซื่อสัตย์ซึ่งไม่ได้กำหนดนโยบาย no-referrer
ได้ หากคุณใช้ Referer
เป็นการตรวจสอบครั้งแรก ให้ทำดังนี้
- อย่าคาดหวังว่าจะมี
Referer
ตลอดเวลา หากมีอยู่ ให้ตรวจสอบกับข้อมูล ขั้นต่ำที่สามารถระบุได้ ซึ่งเป็นข้อมูลต้นทาง- เมื่อตั้งค่ารายการค่า
Referer
ที่อนุญาต โปรดตรวจสอบว่าได้รวมเฉพาะต้นทางเท่านั้นและไม่มีเส้นทาง - ตัวอย่างเช่น ค่า
Referer
ที่อนุญาตสำหรับonline-shop.example
ควรเป็นonline-shop.example
ไม่ใช่online-shop.example/cart/checkout
การคาดว่าไม่มีReferer
เลยหรือมีค่าReferer
ที่เป็นต้นทางของเว็บไซต์ที่ส่งคำขอเท่านั้นจะช่วยป้องกันไม่ให้ข้อผิดพลาดที่อาจมาจากการคาดเดาReferrer-Policy
ของผู้ขาย
- เมื่อตั้งค่ารายการค่า
- หากไม่มี
Referer
หรือหากมีอยู่และการตรวจสอบต้นทางReferer
พื้นฐานสำเร็จ คุณเปลี่ยนไปใช้วิธีการยืนยันอื่นที่เชื่อถือได้มากกว่าได้
ให้ผู้ขอแฮชพารามิเตอร์คำขอร่วมกับคีย์ที่ไม่ซ้ำกันเพื่อให้ยืนยันการชำระเงินได้น่าเชื่อถือมากขึ้น จากนั้นผู้ให้บริการชำระเงินสามารถคำนวณแฮชเดียวกันในฝั่งของคุณ และจะยอมรับคำขอก็ต่อเมื่อตรงกับการคำนวณของคุณเท่านั้น
จะเกิดอะไรขึ้นกับ Referer
เมื่อเว็บไซต์ผู้ขาย HTTP ที่ไม่มีนโยบาย URL ที่มาเปลี่ยนเส้นทางไปยังผู้ให้บริการชำระเงิน HTTPS
ไม่มี Referer
ปรากฏในคำขอที่ส่งไปยังผู้ให้บริการชำระเงิน HTTPS เนื่องจากเบราว์เซอร์ส่วนใหญ่ใช้ strict-origin-when-cross-origin
หรือ no-referrer-when-downgrade
โดยค่าเริ่มต้นเมื่อเว็บไซต์ไม่ได้ตั้งค่านโยบาย
การเปลี่ยนแปลงของ Chrome เป็นนโยบายเริ่มต้นใหม่จะไม่เปลี่ยนลักษณะการทำงานนี้
บทสรุป
นโยบาย URL ที่มาที่มีการปกป้องเป็นวิธีที่ดีเยี่ยมในการช่วยให้ผู้ใช้ของคุณมีความเป็นส่วนตัวมากขึ้น
ดูข้อมูลเพิ่มเติมเกี่ยวกับเทคนิคต่างๆ ในการปกป้องผู้ใช้ได้ที่คอลเล็กชันการรักษาความปลอดภัย
แหล่งข้อมูล
- การทำความเข้าใจ "เว็บไซต์เดียวกัน" และ "ต้นทางเดียวกัน"
- ส่วนหัวความปลอดภัยใหม่: นโยบาย URL ที่มา (2017)
- นโยบายการอ้างอิงใน MDN
- ส่วนหัวอ้างอิง: ข้อกังวลเกี่ยวกับความเป็นส่วนตัวและความปลอดภัยใน MDN
- การเปลี่ยนแปลงของ Chrome: ความตั้งใจ ในการกะพริบจะใช้งาน
- การเปลี่ยนแปลงของ Chrome: กะพริบ Intent เพื่อจัดส่ง
- การเปลี่ยนแปลงของ Chrome: รายการสถานะ
- การเปลี่ยนแปลงของ Chrome: บล็อกโพสต์ของ 85 เบต้า
- ชุดข้อความ GitHub ที่มีการตัดส่วนหัว: เบราว์เซอร์ต่างๆ ทำอะไรบ้าง
- ข้อกำหนดของนโยบายการอ้างอิง
ขอขอบคุณอย่างยิ่งสำหรับการมีส่วนร่วมและความคิดเห็นต่อผู้รีวิวทุกคน โดยเฉพาะ Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck และ Kayce Basques