คู่มือ Referrer Policy Generator: หยุดการรั่วไหลของ URL ของคุณ
เรียนรู้วิธีใช้ Referrer Policy Generator ฟรี สร้าง header Referrer-Policy จากทั้งแปด directive ของ W3C เห็นข้อมูลที่รั่วไหลรายสถานการณ์ และคัดลอกสนิปเป็ต nginx, Apache, Express และ meta tag ที่พร้อมวางใช้ทันที
Table of Contents
คู่มือ Referrer Policy Generator: หยุดการรั่วไหลของ URL ของคุณ
ทุกหน้าเว็บที่มีลิงก์ออกไปข้างนอกกำลังเปิดเผยข้อมูลในนามของคุณอย่างเงียบ ๆ เมื่อผู้เข้าชมคลิกจากหน้าหนึ่งของคุณไปยังเว็บอื่น เบราว์เซอร์จะแนบ header Referer ไปกับ request — และตามค่าเริ่มต้นมันสามารถส่ง URL เต็มของหน้าที่ผู้ใช้เพิ่งออกจากไปด้วย: scheme, host, path และ query string ถ้าผู้ใช้กำลังอยู่บนหน้า admin ภายใน หรือลิงก์รีเซ็ตรหัสผ่านที่ฝัง token ทั้งที่อยู่จะถูกส่งตรงไปยังเว็บปลายทาง
header Referrer-Policy คือวิธีที่คุณคว้าสิทธิ์ตัดสินใจจุดนี้คืนมา สเปกของ W3C กำหนด directive ไว้แปดตัว แต่ละตัวทำงานต่างกันในกรณี same-origin, cross-origin และ request ที่ถูก downgrade เครื่องมือ Referrer Policy Generator ฟรีทำให้การเลือกเห็นภาพ: เลือก directive ดูตารางวิเคราะห์ว่าอะไรรั่วไหลในแต่ละสถานการณ์อัปเดตสด ๆ แล้วคัดลอกสนิปเป็ตที่พร้อมใช้สำหรับ nginx, Apache, Express หรือแท็ก <meta> — ทำงานในเบราว์เซอร์ 100% คู่มือนี้จะพาไล่ดูทั้งแปดตัว พร้อมบอกว่าเมื่อไรควรเข้มกว่าค่าเริ่มต้น
ทำไมต้องใช้ Referrer Policy Generator?
- เห็นการรั่วไหล ไม่ใช่แค่ชื่อ. ชื่ออย่าง origin-when-cross-origin ซ่อนพฤติกรรมไว้ในคำต่อกันยาว ๆ คำเดียว เครื่องมือแปลงแต่ละ directive เป็นตารางแยกให้เห็นว่าส่ง full URL, origin เท่านั้น หรือไม่ส่งอะไรเลย
- ทั้งแปด directive ของ W3C อยู่ในที่เดียว. ตั้งแต่ no-referrer ถึง unsafe-url ทุกตัวเลือกคลิกถึง พร้อมติดป้ายเตือนตัวที่เสี่ยง
- ไวยากรณ์ครบทุกแพลตฟอร์ม deploy. พอลิซีเดียวกันออกมาเป็น add_header ของ nginx, Header always set ของ Apache, middleware ของ Express และแท็ก <meta name="referrer">
- ค่าเริ่มต้นที่ปลอดภัยพร้อมใช้. เครื่องมือเลือก strict-origin-when-cross-origin ไว้ให้ตั้งแต่แรก — ค่าที่เบราว์เซอร์ยุคใหม่ใช้กันอยู่แล้ว — และทำเครื่องหมายว่าแนะนำ
- ทันที เป็นส่วนตัว และฟรี. ทำงานฝั่งไคลเอนต์ 100%: ไม่ต้องสมัคร ไม่มีโควตา และการกลับมาเช็ก header หลัง deploy ทุกรอบใช้เวลาไม่กี่วินาที
ฟีเจอร์หลัก
| ฟีเจอร์ | สิ่งที่ทำ |
|---|---|
| ครบทั้ง 8 directive ของ W3C | no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url. |
| วิเคราะห์รายสถานการณ์ | สิ่งที่ถูกส่งใน request แบบ same-origin, cross-origin และแบบถูก downgrade: full URL, origin เท่านั้น หรือไม่ส่งอะไรเลย |
| สนิปเป็ตสำหรับ deploy | ผลลัพธ์พร้อมคัดลอกสำหรับ nginx, Apache และ Express บวกแท็ก <meta name="referrer"> สำหรับโฮสต์ที่ตั้ง header เองไม่ได้ |
| ป้ายแนะนำและป้ายเสี่ยง | strict-origin-when-cross-origin ถูกทำเครื่องหมายว่าแนะนำ ส่วน unsafe-url มีคำเตือนกำกับ |
| คัดลอกคลิกเดียว | แต่ละสนิปเป็ตคัดลอกมาเป็นบล็อกสมบูรณ์ ถูกต้องตามไวยากรณ์ |
| ทำงานฝั่งไคลเอนต์ 100% | รันทั้งหมดในเบราว์เซอร์ ไม่มีอะไรถูกอัปโหลด |
มีสองรายละเอียดที่ควรให้น้ำหนักก่อน deploy อะไรก็ตาม:
- คอลัมน์ downgrade คือที่ที่ความผิดพลาดซ่อนตัว. พอลิซีที่ดูปลอดภัยบนกระดาษก็ยังรั่วได้เมื่อ request ถูก downgrade จาก HTTPS ลงเป็น HTTP
- สนิปเป็ตถูกจัดรูปให้พร้อม deploy ไม่ใช่แค่ค่าดิบ: add_header ของ nginx ที่ไม่ใส่ always จะข้าม response หน้า error ไปเงียบ ๆ
วิธีใช้งาน
- เปิดเครื่องมือและดูค่าเริ่มต้นที่แนะนำ. Referrer Policy Generator เริ่มด้วย strict-origin-when-cross-origin ที่ถูกเลือกไว้แล้ว — จุดที่เว็บส่วนใหญ่ควรยืนอยู่
- ศึกษาตารางวิเคราะห์รายสถานการณ์. ดูว่า request แบบ same-origin ส่งอะไรไป อะไรออกไปข้าม origin และเกิดอะไรขึ้นเมื่อถูก downgrade
- เทียบทางเลือกกับ threat model ของคุณ. ถ้า URL ของคุณฝังสถานะที่อ่อนไหว ลองวาง strict-origin และ same-origin เคียงกัน ถ้าคุณพึ่งการวัดแหล่งทราฟฟิกจากพาร์ตเนอร์ ให้เทียบกับ origin
- คัดลอกสนิปเป็ตของแพลตฟอร์มคุณ. เอาผลลัพธ์ nginx, Apache หรือ Express ไปวางในคอนฟิกเซิร์ฟเวอร์ หรือเอาแท็ก <meta> ไปวางใน <head> ถ้าโฮสต์ของคุณตั้ง header เองไม่ได้
- Deploy แล้วตรวจด้วย request จริง. ส่อง response header ด้วย curl -I หรือแผง Network ใน devtools แล้วยืนยันว่าค่า Referrer-Policy ตรงกัน
ทั้งแปด directive โดยไม่ต้องปวดหัว
ขอแวะเรื่องการตั้งชื่อก่อน: header ของ request สะกดว่า Referer — คำสะกดผิดที่กลายเป็นฟอสซิลตั้งแต่สเปก HTTP ต้นฉบับ — ขณะที่พอลิซีที่ควบคุมมันคือ Referrer-Policy ซึ่งสะกดถูก ทั้งคู่ถือว่าถูกต้องในบริบทของตัวเอง
header Referer ส่งส่วนประกอบของ URL ที่ผู้เข้าชมมาจากได้ถึงสี่ส่วน: scheme (https://), host (yoursite.com), path (/admin/users) และ query (?id=42) ส่วน fragment (#section) จะไม่ถูกส่งไปเด็ดขาด นั่นคือเหตุผลที่ referrer แบบ full URL เป็นปัญหาด้านความเป็นส่วนตัว — เพราะมันมักเผยไม่ใช่แค่ "เว็บไหนส่งผู้เข้าชมคนนี้มา" แต่รวมถึง "หน้าภายในหน้าไหน หรือลิงก์ที่มี token ตัวไหนที่เขาเพิ่งออกจากไป"
| directive | same-origin | cross-origin | downgrade (HTTPS เป็น HTTP) |
|---|---|---|---|
| no-referrer | ไม่ส่งอะไรเลย | ไม่ส่งอะไรเลย | ไม่ส่งอะไรเลย |
| no-referrer-when-downgrade | full URL | full URL | ไม่ส่งอะไรเลย |
| origin | origin เท่านั้น | origin เท่านั้น | origin เท่านั้น |
| origin-when-cross-origin | full URL | origin เท่านั้น | origin เท่านั้น |
| same-origin | full URL | ไม่ส่งอะไรเลย | ไม่ส่งอะไรเลย |
| strict-origin | origin เท่านั้น | origin เท่านั้น | ไม่ส่งอะไรเลย |
| strict-origin-when-cross-origin | full URL | origin เท่านั้น | ไม่ส่งอะไรเลย |
| unsafe-url | full URL | full URL | full URL |
แถวเดียวอธิบายการตัดสินใจส่วนใหญ่ในโลกจริงได้ strict-origin-when-cross-origin คือเส้นทางกลางที่แนะนำ และ Chrome, Edge และ Firefox ยกมันขึ้นเป็นค่าเริ่มต้นของเบราว์เซอร์ราวปี 2020: เว็บของคุณเองได้ full URL (analytics ภายในยังทำงานปกติ) เว็บอื่นได้แค่ origin และ request ที่ถูก downgrade ลง HTTP ได้ไม่มีอะไรเลย
ใครควรเข้มกว่านั้น? ถ้า URL ของคุณฝังสถานะที่อ่อนไหว — แผง admin, ตั๋วช่วยเหลือ, flow การเงิน, ลิงก์ที่มี token — พิจารณา strict-origin (ส่ง origin ทุกที่ และไม่ส่งอะไรเลยเมื่อถูก downgrade) หรือ no-referrer (ไม่ส่งอะไรเลยทุกที่) เว็บปลายทางจะเสียการวัดแหล่งทราฟฟิกทั้งหมด ซึ่งมักเป็นสิ่งที่คุณตั้งใจ
ทีนี้ลองเดินตามสถานการณ์ในภาพประกอบ: พนักงานที่อยู่บน https://yoursite.com/admin/users?id=42 คลิกลิงก์ไปยังบล็อกของพาร์ตเนอร์
- ด้วย strict-origin-when-cross-origin พาร์ตเนอร์ได้รับ Referer: https://yoursite.com — แหล่งทราฟฟิกเท่านั้น ไม่มีอะไรเพิ่ม
- ด้วย unsafe-url พาร์ตเนอร์ได้รับ URL เต็ม ซึ่งจะถูกเก็บอยู่ใน access log ของเขาตลอดไป
- ด้วย no-referrer พาร์ตเนอร์ไม่ได้รับ header Referer เลย — ความเป็นส่วนตัวสูงสุด แลกกับการวัดแหล่งทราฟฟิก
กรณีการใช้งานจริง
Hardening ด้านความเป็นส่วนตัวสำหรับเว็บคอนเทนต์
บล็อกและเว็บเอกสารลิงก์ออกไปข้างนอกตลอดเวลา และทุกคลิกที่ออกไปคือการเปิดเผยเล็ก ๆ หนึ่งครั้ง การตั้ง strict-origin-when-cross-origin ที่ระดับเซิร์ฟเวอร์ทำให้เส้นทางการอ่านของผู้ใช้ยังเป็นของคุณ ขณะที่พาร์ตเนอร์ยังเห็นแหล่งทราฟฟิก เว็บไหนที่อยากไปให้ถึงสุด เลือก no-referrer แล้วระบุไว้ในนโยบายความเป็นส่วนตัวของตัวเอง
กัน token และ path ภายในหลุดไปอยู่บนเซิร์ฟเวอร์บุคคลที่สาม
คมสุดของการรั่วไหลแบบ referrer คือสถานะที่ถูกฝังใน URL: token รีเซ็ตรหัสผ่าน, ลิงก์เชิญชวน หรือ path ภายในอย่าง /admin ที่ไม่เคยตั้งใจให้ประกาศศัพท์ พอลิซีแบบเข้มงวด — ใส่เฉพาะเส้นทางนั้นหรือทั้งเว็บ — หมายความว่าแม้ referrer จะหลุดไป มันก็เผยอะไรไม่ได้
ตัดสินใจเรื่อง analytics อย่างรู้เท่าทัน
referrer แบบเต็มช่วยให้ analytics สร้างเส้นทางการใช้งานย้อนกลับได้ ส่วนแบบ origin เท่านั้นทำให้คำถาม "มาจากเว็บไหน" ยังตอบได้ แต่รายละเอียดในเว็บเบลอลง ค่าเริ่มต้นที่แนะนำแบ่งกันพอดี: พาร์ตเนอร์ได้แค่ origin ขณะที่ analytics ฝั่ง first-party ยังเห็น referrer แบบเต็มของ same-site ทีมส่วนใหญ่ไม่เสียอะไรเลย — แต่ควรตัดสินใจอย่างมีสติ
ผ่านการรีวิวด้านความปลอดภัยและ compliance
แบบสอบถามความปลอดภัยและการรีวิวสไตล์ GDPR ถามถึงข้อมูลส่วนบุคคลที่ออกจากเว็บคุณระหว่างการส่งผ่านมากขึ้นทุกปี referrer แบบ full URL — ซึ่งอาจมีตัวระบุบัญชีและ ID เอกสาร — คือข้อมูลที่รั่วไหลโดยไม่ตั้งใจแบบที่ผู้รีวิวชี้เป็นจุดตั้งคำถามพอดี header Referrer-Policy ที่ถูกบันทึกไว้เปลี่ยนข้อเสียในเช็กลิสต์ให้กลายเป็นคำตอบบรรทัดเดียว
แนวปฏิบัติที่ดีที่สุด
- ตั้ง header นี้กับทุก response ไม่ใช่แค่หน้า HTML. พอลิซีที่ใส่เฉพาะเอกสารจะทิ้งให้ asset, redirect และ API endpoint ลอยอยู่กับค่าเริ่มต้นของเบราว์เซอร์ ใส่ที่ระดับเซิร์ฟเวอร์ทั้งหมด
- เลือกพฤติกรรม origin เท่านั้นสำหรับ request ข้ามเว็บ. เว้นแต่คุณมีเหตุผลที่บันทึกไว้ว่าต้องส่ง full URL ไปยัง origin อื่น strict-origin-when-cross-origin (หรือ strict-origin) คือทางเลือกที่ป้องกันตัวได้
- ตรวจด้วยตัวตรวจ request หลังทุกการเปลี่ยนแปลง. curl -I บนหน้าที่รันอยู่หรือแผง Network ใน devtools แสดงสิ่งที่เบราว์เซอร์ได้รับจริง รวมถึงเลเยอร์ CDN ด้วย
- อย่าลืมแผนสำรองแบบ meta tag. บนโฮสต์ที่ตั้ง response header เองไม่ได้ การใส่ <meta name="referrer" content="strict-origin-when-cross-origin"> ใน <head> ให้ผลเหมือนกัน
- ห้ามส่ง unsafe-url ขึ้น production. ค่านี้มีไว้แทบจะเพียงเพื่อ debug เคสพิเศษเท่านั้น ถ้ามันปรากฏในคอนฟิก production แปลว่ามันอยู่ที่นั่นโดยบังเอิญ
- แก้ HTTPS ให้เรียบร้อยก่อนค่อยจัดการคอลัมน์ downgrade. การเสิร์ฟทุกอย่างผ่าน HTTPS พร้อม HSTS — ดู HSTS Header Generator — ตัดสถานการณ์ downgrade ออกไปทั้งหมด
นำ Referrer-Policy ไปใช้ตั้งแต่วันนี้
การรั่วไหลแบบ referrer มองไม่เห็นจนกว่าใครสักคนจะชี้บรรทัดใน log ให้ดู และมันใช้แค่ header เดียวกับไม่กี่นาทีในการกำจัด เปิด Referrer Policy Generator ทบทวนตารางวิเคราะห์ของค่าเริ่มต้น แล้วคัดลอกสนิปเป็ตสำหรับสแตกของคุณไปใช้ตั้งแต่วันนี้
เครื่องมือที่เกี่ยวข้อง
- Security Headers Generator — สร้างชุด security header ครบชุด รวมถึง Referrer-Policy ในรอบเดียว
- CSP Generator — ประกอบ Content Security Policy ที่หยุด XSS และการดึงข้อมูลออกจากระบบ พร้อมตรวจสอบแบบเรียลไทม์
- HSTS Header Generator — สร้าง header Strict-Transport-Security ที่บังคับ HTTPS และปิด downgrade attack
ขอให้ทุกคลิกที่ออกไปข้างนอกส่งไปเท่าที่คุณตั้งใจจะให้ส่ง!
คำถามที่พบบ่อย
ถ: เครื่องมือนี้ฟรีไหม และมีการอัปโหลดอะไรหรือไม่?
ตอบ: ฟรีทั้งหมดโดยไม่ต้องสมัคร และไม่มีอะไรถูกอัปโหลด: ทุกอย่างรันในเครื่องของคุณผ่านเบราว์เซอร์
ถ: Referer กับ Referrer-Policy ต่างกันอย่างไร?
ตอบ: Referer คือ header ฝั่ง request ที่เบราว์เซอร์ส่งไปยังเว็บปลายทาง เพื่อบอกว่าผู้เข้าชมมาจากไหน ส่วน Referrer-Policy คือ response header ที่เว็บของคุณตั้ง เพื่อบอกเบราว์เซอร์ว่าควรใส่ URL นั้นไปมากแค่ไหน
ถ: เว็บส่วนใหญ่ควรเลือก directive ตัวไหน?
ตอบ: strict-origin-when-cross-origin คือค่าเริ่มต้นที่สมเหตุสมผล: full URL ภายในเว็บของคุณเอง origin เท่านั้นสำหรับเว็บอื่น และไม่มีอะไรเมื่อถูก downgrade ค่อยเข้มขึ้นเมื่อ URL ของคุณพา token ไปเรื่อย ๆ เท่านั้น
ถ: ใช้ meta tag แทน header ฝั่งเซิร์ฟเวอร์ได้ไหม?
ตอบ: ได้ ในฐานะแผนสำรอง <meta name="referrer" content="..."> ใน <head> ใช้พอลิซีกับ request ที่เริ่มจากเอกสารนั้น — เหมาะกับโฮสต์แบบ static แม้ header ที่ระดับเซิร์ฟเวอร์จะยังแข็งแรงกว่าก็ตาม