แนวทางปฏิบัติแนะนำสำหรับผู้อ้างอิงและนโยบายผู้อ้างอิง

Maud Nalpas

หน้านี้อธิบายแนวทางปฏิบัติแนะนำบางส่วนสำหรับการตั้งค่า Referrer-Policy และการใช้ผู้แนะนำในคำขอขาเข้า

สรุป

• การรั่วไหลของข้อมูลข้ามต้นทางโดยไม่คาดคิดจะทำลายความเป็นส่วนตัวของผู้ใช้เว็บ นโยบาย URL ที่มาแบบป้องกันจะช่วยได้
• ลองตั้งค่านโยบาย URL ที่มาเป็น strict-origin-when-cross-origin ซึ่งจะ รักษาประโยชน์ส่วนใหญ่ของเครื่องมืออ้างอิงไว้ พร้อมกับลดความเสี่ยงในการ รั่วไหลของข้อมูลข้ามต้นทาง
• อย่าใช้ URL ที่มาสำหรับการป้องกัน Cross-Site Request Forgery (CSRF) ใช้โทเค็น CSRF แทน และใช้ส่วนหัวอื่นๆ เป็นการรักษาความปลอดภัยอีกชั้น

ข้อมูลเบื้องต้นเกี่ยวกับ Referer และ Referrer-Policy

คำขอ 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 ที่มาได้

นโยบายใดบ้างที่พร้อมใช้งานและนโยบายเหล่านั้นแตกต่างกันอย่างไร

คุณเลือกได้ 1 ใน 8 นโยบาย ข้อมูล ที่ได้จากส่วนหัวของ Referer (และ document.referrer) จะทำสิ่งต่อไปนี้ได้ ทั้งนี้ขึ้นอยู่กับนโยบาย

• ไม่มีข้อมูล (ไม่มีส่วนหัว Referer)
• เฉพาะต้นทาง
• URL แบบเต็ม: ต้นทาง เส้นทาง และสตริงการค้นหา

นโยบายบางอย่างได้รับการออกแบบมาให้ทำงานแตกต่างกันโดยขึ้นอยู่กับบริบท ดังนี้ คำขอข้ามต้นทางหรือคำขอที่มีต้นทางเดียวกัน ไม่ว่าปลายทางของคำขอจะปลอดภัยเท่าต้นทางหรือไม่ หรือทั้งสองอย่าง ซึ่งจะเป็นประโยชน์ในการจำกัดปริมาณข้อมูลที่แชร์ในต้นทางต่างๆ หรือต้นทางที่มีความปลอดภัยน้อยกว่า ขณะเดียวกันก็ยังคงความสมบูรณ์ของ URL ที่มาภายในเว็บไซต์ของคุณเอง

ตารางต่อไปนี้แสดงวิธีที่นโยบายผู้อ้างอิงจำกัดข้อมูล URL ที่ใช้ได้ จากส่วนหัว Referer และ document.referrer

MDN มีรายการนโยบายและตัวอย่างลักษณะการทำงาน ทั้งหมด

ข้อควรทราบเมื่อตั้งค่านโยบายผู้แนะนำมีดังนี้

• นโยบายทั้งหมดที่พิจารณารูปแบบ (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 ที่มา เบราว์เซอร์จะใช้นโยบายเริ่มต้น

แนวทางปฏิบัติแนะนำในการตั้งค่านโยบายผู้แนะนำ

คุณตั้งค่านโยบายการอ้างอิงสำหรับเว็บไซต์ได้หลายวิธี ดังนี้

• เป็นส่วนหัว HTTP
• ภายใน HTML
• จาก JavaScript ต่อคำขอ

คุณตั้งค่านโยบายที่แตกต่างกันสำหรับหน้าเว็บ คำขอ หรือองค์ประกอบต่างๆ ได้

ทั้งส่วนหัว HTTP และองค์ประกอบเมตาอยู่ในระดับหน้าเว็บ ลำดับความสำคัญในการ กำหนดนโยบายที่มีผลขององค์ประกอบมีดังนี้

1. นโยบายระดับองค์ประกอบ
2. นโยบายระดับหน้าเว็บ
3. ค่าเริ่มต้นของเบราว์เซอร์

ตัวอย่างเช่น

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 เพื่อดู นโยบายผู้แนะนำที่ใช้สำหรับคำขอที่เฉพาะเจาะจงได้ด้วย ในขณะที่เขียนบทความนี้ 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}

การใช้ผู้แนะนำจากคำขอข้ามต้นทางขาเข้ามีข้อจำกัดบางประการดังนี้

• หากคุณไม่มีสิทธิ์ควบคุมการติดตั้งใช้งานของเครื่องมือปล่อยคำขอ คุณจะ คาดเดาเกี่ยวกับส่วนหัว Referer (และ document.referrer) ที่คุณ ได้รับไม่ได้ ผู้ออกคำขออาจตัดสินใจเปลี่ยนไปใช้นโยบาย no-referrer ได้ทุกเมื่อ หรืออาจเปลี่ยนไปใช้นโยบายที่เข้มงวดกว่าที่เคยใช้ ก่อนหน้านี้ ซึ่งหมายความว่าคุณจะได้รับข้อมูลจาก Referer น้อยลงกว่าเดิม
• เบราว์เซอร์ใช้ Referrer-Policy strict-origin-when-cross-origin มากขึ้นโดยค่าเริ่มต้น ซึ่งหมายความว่าตอนนี้คุณอาจได้รับเฉพาะต้นทางแทนที่จะเป็น URL ที่มาแบบเต็มในคำขอข้ามต้นทางที่เข้ามา หากเว็บไซต์ผู้ส่งไม่ได้ตั้งค่านโยบายไว้
• เบราว์เซอร์อาจเปลี่ยนวิธีจัดการ Referer ตัวอย่างเช่น นักพัฒนาเบราว์เซอร์บางรายอาจตัดสินใจตัดผู้อ้างอิงให้เหลือเฉพาะต้นทางในคำขอทรัพยากรย่อยแบบข้ามต้นทางเสมอเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
• ส่วนหัว Referer (และ document.referrer) อาจมีข้อมูลมากกว่าที่คุณต้องการ เช่น อาจมี URL แบบเต็มในกรณีที่คุณต้องการทราบว่าคำขอเป็นแบบข้ามต้นทางหรือไม่

ทางเลือกแทน Referer

คุณอาจต้องพิจารณาทางเลือกอื่นในกรณีต่อไปนี้

• ฟีเจอร์ที่สำคัญของเว็บไซต์ใช้ URL ที่มาของคำขอขาเข้าแบบข้ามต้นทาง
• เว็บไซต์ของคุณไม่ได้รับ URL ที่มาของผู้เข้าชมบางส่วนที่จำเป็นในคำขอข้ามต้นทางอีกต่อไป เหตุการณ์นี้จะเกิดขึ้นเมื่อผู้ออกคำขอเปลี่ยนนโยบาย หรือเมื่อไม่ได้ตั้งค่านโยบายและนโยบายเริ่มต้นของเบราว์เซอร์มีการเปลี่ยนแปลง (เช่น ใน Chrome 85)

หากต้องการกำหนดทางเลือกอื่น ให้วิเคราะห์ก่อนว่าคุณใช้ส่วนใดของแหล่งที่มาของการอ้างอิง

หากต้องการเฉพาะต้นทาง

• หากคุณใช้ผู้แนะนำในสคริปต์ที่มีสิทธิ์เข้าถึงระดับบนสุดของหน้า window.location.origin จะเป็นทางเลือกแทน
• หากมีอยู่ ส่วนหัว เช่น Origin และ Sec-Fetch-Site จะให้ Origin หรืออธิบายว่าคำขอเป็นแบบข้ามต้นทางหรือไม่ ซึ่ง อาจเป็นสิ่งที่คุณต้องการ

หากคุณต้องการองค์ประกอบอื่นๆ ของ URL (เส้นทาง พารามิเตอร์การค้นหา...)

• พารามิเตอร์คำขออาจตอบโจทย์กรณีการใช้งานของคุณ ซึ่งช่วยให้คุณไม่ต้องแยกวิเคราะห์ URL ที่มา
• หากคุณใช้ผู้แนะนำในสคริปต์ที่มีสิทธิ์เข้าถึงระดับบนสุดของหน้า window.location.pathname อาจใช้แทนได้ ดึงเฉพาะส่วนเส้นทาง ของ URL และส่งต่อเป็นอาร์กิวเมนต์ เพื่อไม่ให้มีการส่งต่อข้อมูลที่อาจมีความละเอียดอ่อน ในพารามิเตอร์ของ URL

หากใช้ตัวเลือกอื่นเหล่านี้ไม่ได้ ให้ทำดังนี้

• ตรวจสอบว่าคุณเปลี่ยนระบบให้คาดหวังว่าเครื่องมือปล่อยคำขอ (เช่น site-one.example) จะตั้งค่าข้อมูลที่คุณต้องการอย่างชัดเจน ในการกำหนดค่าบางประเภทได้หรือไม่
  • ข้อดี: ชัดเจนมากขึ้น รักษาความเป็นส่วนตัวมากขึ้นสำหรับsite-one.exampleผู้ใช้ พร้อมสำหรับอนาคตมากขึ้น
  • ข้อเสีย: คุณหรือผู้ใช้ระบบอาจต้องทำงานมากขึ้น
• ตรวจสอบว่าเว็บไซต์ที่ส่งคำขออาจยอมรับการตั้งค่า นโยบาย URL ที่มาต่อองค์ประกอบหรือต่อคำขอของ no-referrer-when-downgrade หรือไม่
  • ข้อเสีย: อาจรักษาความเป็นส่วนตัวของผู้ใช้ site-one.example ได้น้อยลง อาจไม่รองรับในบางเบราว์เซอร์

การป้องกันคำขอแบบข้ามเว็บไซต์ (CSRF)

ผู้ส่งคำขอสามารถเลือกไม่ส่งผู้แนะนำได้เสมอโดยการตั้งค่าno-referrerนโยบาย และผู้ไม่ประสงค์ดีอาจปลอมแปลงผู้แนะนำได้ด้วย

ใช้โทเค็น CSRF เป็นการป้องกันหลัก เพื่อการปกป้องที่ดียิ่งขึ้น ให้ใช้ SameSite และ แทน Referer ให้ใช้ส่วนหัว เช่น Origin (ใช้ได้กับคำขอ POST และ CORS) และ Sec-Fetch-Site หากมี

บันทึกและแก้ไขข้อบกพร่อง

โปรดปกป้องข้อมูลส่วนบุคคลหรือข้อมูลที่ละเอียดอ่อนของผู้ใช้ซึ่งอาจอยู่ใน Referer

หากคุณใช้เฉพาะต้นทาง ให้ตรวจสอบว่าคุณใช้ส่วนหัว Origin เป็นทางเลือกได้หรือไม่ ซึ่งอาจให้ข้อมูลที่คุณต้องการสําหรับการแก้ไขข้อบกพร่อง ในวิธีที่ง่ายขึ้นและไม่ต้องแยกวิเคราะห์ผู้เข้าชม

การชำระเงิน

ผู้ให้บริการชำระเงินอาจใช้ส่วนหัว 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 ที่ไม่มีนโยบายผู้แนะนำเปลี่ยนเส้นทางไปยังผู้ให้บริการชำระเงิน HTTPS

ไม่มี Referer ปรากฏในคำขอไปยังผู้ให้บริการชำระเงิน HTTPS เนื่องจากเบราว์เซอร์ส่วนใหญ่ใช้ strict-origin-when-cross-origin หรือ no-referrer-when-downgrade โดยค่าเริ่มต้นเมื่อเว็บไซต์ไม่ได้ตั้งค่านโยบาย การเปลี่ยนแปลงนโยบายเริ่มต้นใหม่ของ Chrome จะไม่เปลี่ยนลักษณะการทำงานนี้

บทสรุป

นโยบายการอ้างอิงที่ปกป้องเป็นวิธีที่ยอดเยี่ยมในการให้ความเป็นส่วนตัวแก่ผู้ใช้มากขึ้น

ดูข้อมูลเพิ่มเติมเกี่ยวกับเทคนิคต่างๆ ในการปกป้องผู้ใช้ได้ที่คอลเล็กชันปลอดภัย

แหล่งข้อมูล

• ทำความเข้าใจ "Same-Site" และ "Same-Origin"
• ส่วนหัวด้านความปลอดภัยใหม่: นโยบายผู้อ้างอิง (2017)
• นโยบาย URL ที่มาใน MDN
• ส่วนหัว Referer: ข้อกังวลด้านความเป็นส่วนตัวและความปลอดภัยใน MDN
• การเปลี่ยนแปลงใน Chrome: ความตั้งใจของ Blink ที่จะ ใช้
• การเปลี่ยนแปลงใน Chrome: ความตั้งใจของ Blink ที่จะ เปิดตัว
• การเปลี่ยนแปลงใน Chrome: รายการสถานะ
• การเปลี่ยนแปลงใน Chrome: 85 เบต้า บล็อกโพสต์
• เธรด GitHub เกี่ยวกับการตัด Referrer: สิ่งที่เบราว์เซอร์ต่างๆ ทำ
• ข้อกำหนดของนโยบาย URL ที่มา

ขอขอบคุณอย่างยิ่งสำหรับผลงานและการให้ฟีดแบ็กแก่ผู้ตรวจสอบทุกท่าน โดยเฉพาะ Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck และ Kayce Basques