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

Maud Nalpas

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

สรุป

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

หมายเหตุ:

• หากไม่แน่ใจเกี่ยวกับความแตกต่างระหว่าง "เว็บไซต์" กับ "ต้นทาง" โปรดดูทำความเข้าใจ "เว็บไซต์เดียวกัน" และ "ต้นทางเดียวกัน"
• ส่วนหัว Referer ไม่มีตัว R เนื่องจากมีการสะกดผิดในข้อกำหนดเดิม ส่วนหัว Referrer-Policy และ referrer ใน JavaScript และ DOM สะกดถูกต้อง

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

คำขอ HTTP อาจมีส่วนหัว Referer ที่ไม่บังคับ ซึ่งระบุต้นทางหรือ URL ของหน้าเว็บที่ส่งคำขอ ส่วนหัว Referrer-Policy จะกำหนดข้อมูลที่พร้อมใช้งานในส่วนหัว Referer

ในตัวอย่างต่อไปนี้ ส่วนหัว Referer มี URL แบบเต็มของหน้าใน site-one ที่ส่งคำขอ

คำขอ HTTP ที่มีส่วนหัว Referer

ส่วนหัว Referer อาจปรากฏในคำขอประเภทต่างๆ ดังนี้

• คำขอการนำทางเมื่อผู้ใช้คลิกลิงก์
• คำขอทรัพยากรย่อย เมื่อเบราว์เซอร์ขอรูปภาพ, iframe, สคริปต์ และทรัพยากรอื่นๆ ที่หน้าเว็บต้องการ

สำหรับการนำทางและ iframe คุณยังเข้าถึงข้อมูลนี้ด้วย JavaScript โดยใช้ document.referrer ได้ด้วย

คุณสามารถเรียนรู้ได้มากมายจากค่า Referer ตัวอย่างเช่น บริการวิเคราะห์อาจใช้คุกกี้เพื่อระบุว่า 50% ของผู้เข้าชมใน site-two.example มาจาก social-network.example แต่เมื่อมีการส่ง URL แบบเต็ม ซึ่งรวมถึงเส้นทางและสตริงการค้นหาในReferer ข้ามต้นทาง อาจเป็นอันตรายต่อความเป็นส่วนตัวของผู้ใช้และสร้างความเสี่ยงด้านความปลอดภัย ดังนี้

การใช้ URL แบบเต็มอาจส่งผลต่อความเป็นส่วนตัวของผู้ใช้และความปลอดภัย

URL #1 ถึง #5 มีข้อมูลส่วนตัว และบางครั้งอาจมีข้อมูลที่ละเอียดอ่อนหรือข้อมูลระบุตัวบุคคล การรั่วไหลของข้อมูลเหล่านี้ข้ามต้นทางโดยไม่มีการแจ้งเตือนอาจทำให้ความเป็นส่วนตัวของผู้ใช้เว็บลดลง

URL #6 เป็น URL ความสามารถ หากบุคคลอื่นที่ไม่ใช่ผู้ใช้ที่ต้องการได้รับข้อความนี้ ผู้ไม่ประสงค์ดีจะควบคุมบัญชีของผู้ใช้รายนี้ได้

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

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

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

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

ตัวอย่างข้อมูล Referer

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

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

ขอบเขตนโยบาย	ชื่อนโยบาย	Referer: ไม่มีข้อมูล	Referer: Origin only	URL ที่มา: URL แบบเต็ม
ไม่พิจารณาบริบทของคำขอ	no-referrer	check
	origin		check
	unsafe-url			check
เน้นความปลอดภัย	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

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

เบราว์เซอร์	Referrer-Policy/ลักษณะการทำงานเริ่มต้น
Chrome	โดยมีค่าเริ่มต้นเป็น strict-origin-when-cross-origin
Firefox	โดยมีค่าเริ่มต้นเป็น strict-origin-when-cross-origin ตั้งแต่เวอร์ชัน 93 เป็นต้นไป สำหรับผู้ใช้การป้องกันการติดตามที่เข้มงวดและการท่องเว็บแบบส่วนตัว ระบบจะไม่สนใจนโยบาย Referrer ที่เข้มงวดน้อยกว่าอย่าง no-referrer-when-downgrade, origin-when-cross-origin และ unsafe-url สำหรับคำขอแบบข้ามเว็บไซต์ ซึ่งหมายความว่าระบบจะตัด Referrer สำหรับคำขอแบบข้ามเว็บไซต์เสมอ ไม่ว่านโยบายของเว็บไซต์จะเป็นอย่างไร
Edge	โดยมีค่าเริ่มต้นเป็น strict-origin-when-cross-origin
Safari	ค่าเริ่มต้นจะคล้ายกับ strict-origin-when-cross-origin โดยมีความแตกต่างบางประการ ดูรายละเอียดได้ที่ การป้องกันการติดตามการป้องกันการติดตาม

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

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

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

• เป็นส่วนหัว 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 ที่ส่ง

แผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ที่มีคำขอที่เลือกไว้

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

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

ทำไมจึงต้อง "ชัดเจน"

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

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

ทำไมต้องเป็น strict-origin-when-cross-origin (หรือเข้มงวดกว่า)

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

• Secure: หากเว็บไซต์ใช้ HTTPS (หากไม่ใช้ ให้ตั้งค่าเป็นลำดับความสำคัญสูงสุด) คุณคงไม่ต้องการให้ URL ของเว็บไซต์รั่วไหลในคำขอที่ไม่ใช่ HTTPS เนื่องจากทุกคนในเครือข่ายสามารถเห็นข้อมูลเหล่านี้ได้ การรั่วไหลจึงอาจทำให้ผู้ใช้เสี่ยงต่อการถูกโจมตีแบบ Person-in-the-Middle นโยบาย 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 (หรือเข้มงวดกว่า) ไม่รองรับ Use Case ทั้งหมดของคุณ

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

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

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

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

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

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

• หากคุณใช้ 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 และใช้ส่วนหัว เช่น Origin (ใช้ได้กับคำขอ POST และ CORS) และ Sec-Fetch-Site หากมี แทน Referer

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

โปรดปกป้องข้อมูลส่วนบุคคลหรือข้อมูลที่ละเอียดอ่อนของผู้ใช้ที่อาจอยู่ใน 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 ซึ่งไม่มีนโยบาย Referrer เปลี่ยนเส้นทางไปยังผู้ให้บริการชำระเงินที่เป็น HTTPS

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

หมายเหตุ: หากเว็บไซต์ใช้ HTTP ให้เปลี่ยนไปใช้ HTTPS

บทสรุป

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

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

แหล่งข้อมูล

• ทำความเข้าใจ "same-site" และ "same-origin"
• ส่วนหัวความปลอดภัยใหม่: นโยบาย Referrer (2017)
• Referrer-Policy ใน MDN
• Referer header: privacy and security concerns on MDN
• การเปลี่ยนแปลงของ Chrome: ความตั้งใจของ Blink ที่จะนำไปใช้
• การเปลี่ยนแปลงของ Chrome: ความตั้งใจของ Blink ที่จะจัดส่ง
• การเปลี่ยนแปลงใน Chrome: รายการสถานะ
• การเปลี่ยนแปลงใน Chrome: บล็อกโพสต์เกี่ยวกับเวอร์ชัน 85 เบต้า
• ชุดข้อความ GitHub เกี่ยวกับการตัด Referrer: สิ่งที่เบราว์เซอร์ต่างๆ ทำ
• ข้อกำหนด Referrer-Policy

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