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

Maud Nalpas

หน้านี้สรุปแนวทางปฏิบัติที่ดีที่สุดบางส่วนสำหรับการตั้งค่านโยบาย URL ที่มา และ โดยใช้ URL ที่มาในคำขอที่เข้ามา

สรุป

• การรั่วไหลของข้อมูลข้ามต้นทางที่ไม่คาดคิดสร้างความเสียหายให้แก่ผู้ใช้เว็บ ความเป็นส่วนตัว ต นโยบาย URL ที่มาแบบป้องกันสามารถช่วยได้
• ลองตั้งค่านโยบาย URL ที่มาเป็น strict-origin-when-cross-origin ทั้งนี้ ช่วยคงประโยชน์ส่วนใหญ่ของผู้อ้างอิง ไปพร้อมๆ กับลดความเสี่ยงของ การรั่วไหลของข้อมูลข้ามต้นทาง
• อย่าใช้ URL ที่มาสำหรับการป้องกัน Cross-Site Request Forgery (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 ที่มาได้

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

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

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

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

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

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

ต่อไปนี้เป็นสิ่งที่ควรทราบเมื่อตั้งค่านโยบาย URL ที่มา

• นโยบายทั้งหมดที่นำสคีม (HTTPS กับ HTTP) มาพิจารณา (strict-origin, no-referrer-when-downgrade และ strict-origin-when-cross-origin) จะดำเนินการกับคำขอจากต้นทาง HTTP หนึ่งไปยัง ต้นทาง HTTP อื่นใช้วิธีการเดียวกับคำขอจากต้นทาง HTTPS ไปยังอีกต้นทางหนึ่ง ต้นทาง HTTPS แม้ว่า HTTP จะมีความปลอดภัยน้อยกว่า นั่นเป็นเพราะว่า สิ่งที่สำคัญคือการมีการดาวน์เกรดการรักษาความปลอดภัยหรือไม่ นั่น คือหากคำขอสามารถเปิดเผยข้อมูลจากต้นทางที่เข้ารหัสไปยังปลายทางที่ไม่ได้เข้ารหัส 1. เช่น ใน HTTPS → คำขอ HTTP คำขอ HTTP → HTTP เสร็จสมบูรณ์ ไม่ได้เข้ารหัส ดังนั้นจึงไม่มีการดาวน์เกรด
• หากคำขอเป็นต้นทางเดียวกัน ก็หมายความว่ารูปแบบ (HTTPS หรือ HTTP) นั้น เช่นเดียวกัน ดังนั้นจึงไม่มีการดาวน์เกรดระดับความปลอดภัย

นโยบาย URL ที่มาเริ่มต้นในเบราว์เซอร์

ข้อมูล ณ เดือนตุลาคม 2021

หากไม่ได้ตั้งค่านโยบาย URL ที่มา เบราว์เซอร์จะใช้นโยบายเริ่มต้น

แนวทางปฏิบัติแนะนำสำหรับการตั้งค่านโยบาย URL ที่มา

มีวิธีการต่างๆ ในการตั้งค่านโยบาย 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 เพื่อดู นโยบาย URL ที่มาสำหรับคำขอที่เฉพาะเจาะจง ในขณะที่เขียนบทความนี้ Safari ไม่แสดงส่วนหัว Referrer-Policy แต่แสดง Referer ที่ ที่คุณส่งไป

วันที่

คุณควรตั้งค่านโยบายใดสำหรับเว็บไซต์

เราขอแนะนำเป็นอย่างยิ่งให้ตั้งค่านโยบายสำหรับเพิ่มความเป็นส่วนตัวอย่างชัดเจน เช่น strict-origin-when-cross-origin (หรือเข้มงวดกว่า)

ทำไม "อย่างชัดแจ้ง"

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

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

เหตุใดจึงควรใช้strict-origin-when-cross-origin (หรือเข้มงวดกว่า)

คุณต้องมีนโยบายที่ปลอดภัย เพิ่มความเป็นส่วนตัว และมีประโยชน์ "มีประโยชน์" อะไร ขึ้นอยู่กับสิ่งที่คุณต้องการจากผู้บอกต่อ ดังนี้

• ปลอดภัย: หากเว็บไซต์ใช้ HTTPS (หากไม่ ให้ใช้ 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 น้อยกว่าเดิม
• เบราว์เซอร์ต่างๆ ใช้นโยบายผู้อ้างอิง strict-origin-when-cross-origin มากขึ้น โดยค่าเริ่มต้น ซึ่งหมายความว่าตอนนี้คุณอาจได้รับเฉพาะต้นทาง แทนที่จะเป็น URL ที่มาแบบเต็มในคำขอแบบข้ามต้นทางขาเข้า หากเว็บไซต์ของผู้ส่ง ไม่ได้ตั้งค่านโยบายไว้
• เบราว์เซอร์อาจเปลี่ยนแปลงวิธีจัดการ Referer เช่น บางเบราว์เซอร์ นักพัฒนาซอฟต์แวร์อาจตัดสินใจตัด URL ที่มาออกสำหรับต้นทางแบบข้ามต้นทางเสมอ ทรัพยากรย่อย เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
• ส่วนหัว Referer (และ document.referrer) อาจมีข้อมูลมากกว่า ที่คุณต้องการ ตัวอย่างเช่น หน้าอาจมี URL แบบเต็มเมื่อคุณต้องการทราบว่า คำขอเป็นแบบข้ามต้นทาง

ตัวเลือกอื่นๆ สำหรับ Referer

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

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

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

หากต้องการเฉพาะจุดเริ่มต้น

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

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

• พารามิเตอร์คำขออาจจัดการ Use Case ของคุณ ซึ่งช่วยให้คุณไม่ต้องเสียเวลา การแยกวิเคราะห์ 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และผู้ไม่ประสงค์ดีอาจปลอมแปลงผู้บอกต่อได้

ใช้โทเค็น 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)
• Referrer-Policy เปิดอยู่ MDN
• ส่วนหัว URL ที่มา: ข้อกังวลเรื่องความเป็นส่วนตัวและความปลอดภัยเปิดอยู่ MDN
• การเปลี่ยนแปลงใน Chrome: กะพริบ Intent เป็น ใช้งาน
• การเปลี่ยนแปลงใน Chrome: กะพริบ Intent เป็น เรือ
• การเปลี่ยนแปลงของ Chrome: รายการสถานะ
• การเปลี่ยนแปลงใน Chrome: 85 เบต้า blogpost
• Referrer ตัดชุดข้อความ GitHub: เบราว์เซอร์ต่างๆ สิ่งที่ควรทำ
• ข้อกำหนดของนโยบายผู้อ้างอิง

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