Referer 問題
Referer（拼寫錯誤）頭部包含請求的地址（例如，使用者從哪個網頁連結到當前請求的網頁，或者載入圖片的頁面地址）。這有許多無害的用途，包括分析、日誌記錄或最佳化快取。然而，也存在一些更有問題的用途，例如跟蹤或竊取資訊，甚至僅僅是無意中洩露敏感資訊的副作用。
例如，考慮一個頁尾帶有社交媒體連結的“重置密碼”頁面。如果使用者點選了該連結，根據資訊共享的方式，社交媒體網站可能會收到重置密碼的 URL，並且仍然可以利用共享的資訊，從而可能危及使用者安全。
同理，嵌入在你頁面中的第三方網站的圖片可能導致敏感資訊洩露給第三方。即使安全沒有受到威脅，這些資訊也可能不是使用者希望共享的內容。
我們如何解決這個問題？
透過合理的應用程式設計可以緩解大部分風險。一個合理的應用程式可以透過生成一次性使用的密碼重置 URL，或將其與唯一的使用者令牌結合來消除此類風險。透過更安全的方式傳輸敏感資料也可以降低風險。
應儘可能使用 POST 而不是 GET，以避免透過 URL 將敏感資料傳遞給其他位置。
你應該始終為你的網站使用 HTTPS。這有很多安全優勢，包括 HTTPS 網站永遠不會向非 HTTPS 網站傳輸 Referer 資訊。現在由於絕大多數網站都使用 HTTPS，這個建議的相關性有所降低，但仍然值得考慮。
此外，你應該考慮從你網站的安全區域（如重置密碼頁面、支付表單、登入區域等）中移除任何第三方內容（例如，嵌入在 <iframe> 中的社交網路小部件）。
你還可以透過以下方式緩解此類風險：
- 伺服器上的
Referrer-Policy頭部，用於控制透過Referer頭部發送哪些資訊。例如，`no-referrer` 指令將完全省略 Referer 頭部。 - HTML 元素上易於洩露此類資訊的 `referrerpolicy` 屬性（例如
<img>和<a>）。例如，可以將其設定為 `no-referrer` 以完全停止傳送 `Referer` 頭部。 - HTML 元素上設定為
noreferrer的 `rel` 屬性，這些元素易於洩露此類資訊（例如<form>和<a>）。 - 使用 `referrer` 作為
<meta>元素的 name，並將 content 設定為 `no-referrer`，以停用整個文件的 Referer 頭部。請參閱 Referrer-Policy 與 HTML 的整合。 - “退出頁面”技術。
注重安全的伺服器端框架通常內建了此類問題的緩解措施，例如：
- Django 安全性（特別是 跨站請求偽造 (CSRF) 防護）。
- Helmet referrer-policy — 用於在 Node.js/Express 應用中設定 Referrer-Policy 的中介軟體（另請參閱 Helmet 以獲取更多安全措施）。
策略和要求
為你的專案團隊編寫一套安全和隱私要求，明確使用此類功能來緩解相關風險，這是有意義的。你應該尋求網路安全專家的幫助來撰寫這些要求，並同時考慮使用者需求和福祉，以及其他問題，如由《歐盟通用資料保護條例》(GDPR) 等立法強制執行的政策和法規。