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

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

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

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

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

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

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

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 (หากไม่มี ให้จัดลำดับความสำคัญ) คุณไม่ต้องการให้ 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