先找出會傳出去的資料
瀏覽器開啟連結，或載入外部圖片、程式及其他資源時，可能把原來頁面的網址放進名為 Referer 的請求標頭。名稱的拼法是歷史遺留；控制它的設定則叫 Referrer-Policy。顧客眼中只是按了一個正常連結，但接收請求的一方可能知道顧客從哪一頁過來。要先看來源網址本身有甚麼：路徑可能顯示正在處理帳戶、訂單或特定活動；查詢參數可能包含搜尋字詞、訂單參考編號，甚至本來就不應放在網址的資料。政策能限制標頭披露，卻不能清除瀏覽器歷史、伺服器日誌或分析工具已記錄的敏感網址。先列出登入、訂單、查詢、電郵連結、付款及客服等顧客路徑，逐一標記會連到哪些外部網域，以及對方是否真的需要知道來源。外部嵌入資源也要列入，不要只看顯眼的超連結。這張清單會把籠統的私隱要求變成可逐項測試的設定決定。
選擇足夠而較少的披露
對 HTTPS 網站而言，常見的 strict-origin-when-cross-origin 會在同源請求傳送完整來源網址；前往另一個 HTTPS 網域時只傳來源網域；由 HTTPS 前往 HTTP 則不傳來源。MDN 說這是現時瀏覽器的預設值，但在部署中明確設定，團隊較容易審核。若外部合作方只需要知道流量來自你的網域，跨網域只傳 origin 可能已足夠。對特別敏感的頁面，no-referrer 會完全略去 Referer；same-origin 只容許同源請求帶來源。strict-origin 則在適用請求只提供 origin，而不提供完整同源路徑。這些設定是不同用途的選擇，並非網站品質排行榜。不要為了營銷歸因而隨便採用 unsafe-url，因為它可能把路徑和查詢參數連同請求送到不安全的目的地。亦不要假設所有瀏覽器、裝置模式和第三方應用都用同一方式回報來源。先寫清楚哪個業務報表依賴來源資訊，再評估目的地的活動參數、自己掌握的伺服器紀錄或披露較少的政策能否滿足實際需要。想看流量報表，並不等於有理由透露顧客正在看的頁面細節。
以一條顧客路徑作決定
假設網店的訂單確認頁連到外部送貨追蹤網站，而確認頁網址的查詢參數有顧客專屬參考編號。在 strict-origin-when-cross-origin 下，另一網域的 HTTPS 追蹤網站應只收到網店的 origin，不應收到確認頁的路徑及查詢參數；若採用 no-referrer，則不應收到 Referer。不過，網店仍應盡可能移除可分享網址中的顧客識別資料。任何人複製網址、日誌記錄網址，或截圖顯示網址，都不受這個標頭保護。送貨連結只應帶追蹤服務確實需要的資料；存取權及有效期限是另一項要獨立設計的控制。再比較由確認頁前往同一網站的訂單協助頁：預設政策可能把完整來源網址傳給同源請求，並進入內部日誌。如沒有必要，可考慮較嚴格的頁面政策，或者先整理網址。最後，檢查確認頁上的分析圖片或外部小工具。資源請求也可能帶 Referer，顧客即使沒有按連結仍會觸發。可見這不是單一送貨按鈕的設定，而是整頁、網址設計及嵌入服務的共同決定。
在合適範圍套用設定
HTTP 回應標頭可以設定整份文件的政策。MDN 亦記載 HTML meta 設定、個別連結或資源的 referrerpolicy 屬性，以及連結可用的 rel=noreferrer。可行時先採用一致的全站政策，再清楚記錄少數頁面或元素例外。實際檢查主機、應用程式和 CDN 最後送出的回應：即使程式碼內有標頭，快取頁、錯誤頁或靜態宣傳頁也可能遺漏；共用版面一改，局部例外亦可能失效。要看瀏覽器收到甚麼，而不是只相信設定檔。帳戶或付款相關頁面可按真實流程判斷 no-referrer 或 same-origin 是否較合適，並與服務供應商測試跳轉。這個政策只處理一部分私隱風險，不是存取控制；它不能證明外部網站可信、阻止其他欄位追蹤、隱藏顧客自行複製的網址，也不能代替訂單頁面的授權檢查。尤其不要以為設了政策，就可以安全地把密碼、一次性憑證或其他秘密放進網址。這些資料需要獨立的設計審核、有效期限及安全處理方法。
檢查實際請求，而非只看標頭
測試時建立只有無害標記的網址，切勿使用真正顧客資料。以 HTTPS 開啟頁面，透過瀏覽器網絡面板查看同源連結、外部 HTTPS 連結，以及外部圖片或程式請求。在可觀察的測試目的地核對 Referer 是沒有值、只有 origin，還是完整網址。敏感頁和一般公開頁都要試。若實際路徑經過轉址，也要查看最終目的地收到甚麼，因為顧客的流程可能不止一跳。若英文及中文頁面、手機版使用不同模板，亦應各自檢查。把觀察結果與預期政策表逐項對照；僅見到回應標頭存在，不代表所有頁面和嵌入資源都套用正確。若外部供應商聲稱一定要完整路徑，先問清楚是哪個整合功能需要，並尋找較安全的替代方法，再考慮放寬設定。測試紀錄及截圖只保留合成網址。推出後，留意編輯頁面新增的第三方工具與連結；付款、客服或分析整合一變，就重查政策。這樣能長期維持決定，也不會把一次瀏覽器測試說成所有瀏覽器和未來頁面都已證實安全。
讓決定可以重查
實用的交接紀錄可包含四項：哪些頁面的網址可能透露資訊、採用甚麼政策及例外、一張列明外發請求預期結果的小表，以及日後修改的負責人。技術人員可以先負責設定，但營銷與客服也要明白，政策收緊後來源報表可能改變。若確實需要歸因，先界定只看哪一種整體來源資料已足夠，不要把顧客的帳戶或查詢路徑當成報表輸入。若發現外部目的地收到完整網址，應視為要調查的缺陷，不應把它當成新增的有用分析資料。敏感流程若沒有合理的來源需求，no-referrer 是清楚的選項。若團隊需要同源診斷，但外部歸因只需網域層級，strict-origin-when-cross-origin 經測試後可以是有理據的基線。重要的是明確作決定、寫下取捨，並在模板或外部整合有實質變更後重查請求。顧客所得到的實際保障很直接：他們按一個普通連結時，網站不會隨便把剛才瀏覽的詳細頁面透露出去。
分清哪些保障須另外處理
最後審核時，應分清來源政策與其他不同用途的保障。Referrer-Policy 控制瀏覽器外發的來源資料；它不能限制已在頁面內運作的第三方程式在其權限範圍讀到甚麼，也不能令原本不可信的目的地變得安全。因此敏感帳戶頁除政策外，仍須另外檢查嵌入程式及外部連結。目的地網址本身的參數，接收方本來就看得到，企業要獨立決定可以放甚麼資訊。若付款或送貨夥伴需要返回地址，應測試真正跳轉與回調，而非憑猜測放寬全站政策。保留簡短變更紀錄，列出涉及頁面、合作方、觀察到的請求及批准的例外；供應商整合方式或宣傳模板改變時，才有根據重查。合適的政策，是以實際請求驗證：在滿足已記錄需求的前提下，只披露必要資料。
進行前先確認
- 列出帶查詢參數的顧客頁面及外部請求。
- 為一般及敏感流程選擇並記錄政策。
- 以合成網址驗證實際外發的 Referer 標頭。
