Defaults.Exposed › 修復 › Referrer-Policy（來源頁策略）

如何修復 Referrer-Policy（來源頁策略）

Referrer-Policy 是你網站交給每位訪客瀏覽器的一條簡單指令，控制當訪客點擊通往別的網站的連結時，你的網址會隨他們帶走多少。少了它，他們當時所在那個頁面的完整網址——搜尋詞、帳號、重置連結、內部頁面路徑，統統在內——會被悄悄交給他們接著落地的那個網站，包括廣告商、分析公司，以及連結指向的任何地方。

對您業務的關鍵影響： 每當訪客點擊一個外部連結、廣告或共享資源，他們的瀏覽器都可能把你頁面的完整網址交給目標站點——而如果你的網址裡帶著搜尋詞、客戶 ID、訂單號或一次性連結，你就在向自己無法掌控的第三方洩露客戶資料。這是監管機構嚴肅對待的資料保護問題，是一項被悄悄打破的隱私承諾，也是客戶安全團隊在盡職調查時會標記出來的計分漏洞。

這會讓您付出什麼代價

• 客戶填了表單或做了一次搜尋，然後點擊一個外部連結或廣告——於是連同他們輸入的內容在內的頁面網址，被直接交給了你從沒打算分享給的廣告商或分析公司。
• 密碼重置和帳戶確認連結有時會在網址裡帶著一個秘密令牌；沒有這條回應標頭，點擊該頁面上的任何連結都可能把整個網址——連令牌一起——傳給外部站點。
• 私密的內部頁面路徑（管理後台、僅限客戶的頁面、定價分層、文件連結）會被暴露給訪客點過去的每一個第三方，等於把你網站的地圖交給本不該看到它的競爭對手和窺探者。
• 客戶的安全審查或隱私稽核掃描你的網站，發現沒有 Referrer-Policy，便把它記為資料最小化失職——這類發現足以拖住一份合約或一項認證。
• 個人資料落入你與之沒有任何協議的資料處理方手中，把一次五分鐘的疏忽變成一起須上報的資料保護事故。

為什麼它重要。 瀏覽器若任其自便，是很愛多嘴的：它們預設會告訴下一個網站訪客剛從哪裡來，往往連頁面的完整網址一起帶上。對一個純展示型網站這也許無害，但只要你的網址裡含有任何私密資訊——一個搜尋詞、一個訂單 ID、一個連結裡的信箱、一條私密路徑——這個預設行為就會悄悄把它洩露給外部方。Referrer-Policy 正是那一個讓瀏覽器停止過度分享的設定。它是評分卡上一項實打實得分的計分檢查，直接對應隱私法下的資料最小化義務，也是任何專業審查都期望看到的標準安全回應標頭之一。

一句話說清這是什麼

每當你網站上的訪客點擊通往另一個站點的連結——一個外部連結、一條橫幅廣告、一個分享此頁、甚至一個從別處載入的字型或圖片——他們的瀏覽器都會悄悄附上一張便條，說明他們從你的哪個頁面過來。這張便條就叫來源頁（referrer）。

用得合理，來源頁無害甚至有用：別的網站正是靠它知道流量來自你，許多正當的分析也靠它支撐。問題出在預設行為上。若不加管理，瀏覽器不只是說他們來自 your-business.com——它往往會交出那個確切頁面的完整網址，包括網域之後的一切。而網址承載的遠比人們以為的多：輸入到你網站裡的搜尋詞、訂單號和帳號、通往一個僅限會員頁面的路徑，甚至密碼重置和確認連結裡的一次性秘密令牌。

Referrer-Policy 是你網站發給瀏覽器的一條指令，規定它可以分享那張便條裡的多少內容。你可以讓它只分享你的網域、只分享給你自己網站上的其他頁面，或者什麼都不分享。把它想成這樣的差別：要麼把寫滿日程的完整家庭住址遞給一個陌生人，要麼只告訴對方你住在哪個城市。

它屬於一小族安全回應標頭——你網站給每位訪客瀏覽器的簡短指令。它不改變你網站的外觀或運作。它只是讓瀏覽器別替你過度分享。

這會讓你付出什麼代價

下面是缺失或寬鬆的 Referrer-Policy 咬傷真實企業的幾種具體、日常的方式。它們都不需要駭客——它們在正常使用中每天自動發生。

• **被洩露的搜尋。**客戶在你網站上搜尋某種敏感的東西——一款醫療產品、一項與債務相關的服務、一份競品對比——而搜尋詞落進了頁面網址裡。接著他們點擊該結果頁上的一個外部連結或廣告。廣告商現在收到了你的網址連同其中的搜尋詞，從而準確得知你的客戶在找什麼。你從未同意分享它，而且收不回來。

• **暴露的重置連結。**許多系統會把一次性秘密令牌放進密碼重置、信箱確認或一鍵登入頁面的網址裡。如果那個頁面包含任何外部連結或第三方資源，完整網址——連令牌一起——就可能被交給外部站點。最糟的情況下，這等於把一個帳戶的鑰匙遞給了第三方。

• **你免費送出的網站地圖。**你的內部頁面路徑往往會暴露你的結構：/admin、/enterprise-pricing、/clients/acme、/downloads/private-report。沒有這條回應標頭，訪客點過去的每一個外部站點都會收到這些路徑。競爭對手摸清你的定價分層和產品線；爬蟲摸清該盯哪些頁面。

• **不情願的資料共享關係。**隱私法要求你知道客戶的個人資料流向了誰，並要有協議在先。把含有客戶 ID 或信箱地址的頁面網址，在沒有協議、沒有同意的情況下洩露給廣告網路和分析公司——這正是那種會把一次例行稽核變成發現項、再把發現項變成須上報事故的失控資料流。

• **卡在盡職調查上的交易。**當一個較大客戶的安全團隊審查你時，缺失標準安全回應標頭是一個快速、自動的勾選項。看到 Referrer-Policy 缺失，會告訴他們基礎隱私衛生從未做過——而這個印象會給整場審查的其餘部分都染上色彩。

它實際上是什麼

預設情況下，現代版本的瀏覽器遵循一種大致等同於 strict-origin-when-cross-origin 的行為——但你不能依賴它，因為舊瀏覽器、內嵌網頁視圖和某些設定仍會退回到洩露更多。唯一保險的辦法是顯式設定該策略。設定時，你是在一份簡短清單中選一條規則。要緊的有：

• no-referrer——什麼都不分享。下一個站點對訪客從哪裡來一無所知。隱私最大化；可能削弱你的引薦分析。
• same-origin——僅當訪客在你自己網站的頁面之間移動時分享完整網址；對外部站點什麼都不分享。
• strict-origin-when-cross-origin——推薦的預設值。在你自己網站內部，分享完整路徑；對外部站點，只分享你光禿禿的網域（從安全頁面前往不安全頁面時則完全不分享）。外部方知道流量來自你，卻永遠不知道你網域之後的私密細節。
• origin——始終只分享你的網域，即便在你自己網站內部也是如此。

以及兩個要避免的取值，因為評分卡把它們視同根本沒有回應標頭：

• unsafe-url——永遠向所有人分享完整網址。一個詞概括的最壞情況。
• no-referrer-when-downgrade——舊的瀏覽器預設值；它仍會把完整網址發給其他安全站點，洩露上面描述的一切。

**良好的狀態長什麼樣：**存在一條 Referrer-Policy 回應標頭，且設為收緊的取值——對大多數企業是 strict-origin-when-cross-origin。這既讓引薦分析照常工作，又確保你網域之後的任何內容永遠不會到達外部站點。

如何修復（免費，約 5 分鐘）

**把這一節交給你的 IT 人員、網頁開發人員或主機服務商——修復是免費的，只有一行，而且不會弄壞你的網站。**這裡沒有什麼有風險的上線：不像某些安全設定，一個合理的 Referrer-Policy 不會讓你的連結或頁面停止工作。它只是裁剪分享給別的網站的內容。

目標：設定一條值為 strict-origin-when-cross-origin 的 Referrer-Policy 回應標頭（如果你想分享得更少，也可設更嚴的值）。

Cloudflare（無需程式碼——如果你用它，這是最簡單的）： 儀表板 → 你的網域 → Rules → Transform Rules → Modify Response Header → Create rule → Set static → 回應標頭名 Referrer-Policy，值 strict-origin-when-cross-origin → 套用於所有進入的請求 → Deploy。

**Google Workspace / Microsoft 365：**這些管理的是你的信箱，不是你的網站，所以回應標頭要設在你網站實際託管的地方（你的 Web 主機、CDN 或伺服器）——而不是 Workspace 或 365 的管理後台。先確定主機，再用下面對應的方法。

Nginx：

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache（在站點設定或 .htaccess 中）：

Header always set Referrer-Policy "strict-origin-when-cross-origin"

IIS（web.config）：

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express：

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

**WordPress / 常見主機：**大多數託管型 WordPress 和共享主機都允許你透過安全外掛程式、主機控制台裡的回應標頭面板，或上面的 .htaccess 片段來加回應標頭。如果你在 Cloudflare 後面，Cloudflare 的方法最乾淨，一次就全站生效。

**套用之後：**打開你的網站並重新執行檢查，或用瀏覽器的開發者工具（網路標籤頁 → 點擊主文件 → 回應標頭）確認 Referrer-Policy: strict-origin-when-cross-origin 存在。

常見錯誤

• 設了個寬鬆值，卻以為它算數。unsafe-url 和 no-referrer-when-downgrade 仍然都會洩露完整網址。評分卡給它們記零——和沒有回應標頭完全一樣。如果回應標頭在、分數卻不在，幾乎總是這個原因。
• **只在首頁設定它。**這條回應標頭應該在每個頁面上發送，因為洩露發生在搜尋結果頁、帳戶頁和重置頁上——而不是首頁。在伺服器、CDN 或 Cloudflare 層面設定，讓它自動全站生效。
• 只在 HTML 的 <meta> 標籤裡設定它。<meta name="referrer"> 標籤對某些情況有效、但不是全部，而且很容易在各頁面之間出現不一致。把它設成一條正經的回應標頭（上面的方法）才是可靠的做法。
• **讓一層覆蓋另一層。**如果你的來源端伺服器和 CDN 都設了這條回應標頭、卻取值不同，結果可能難以預料。挑一個地方來統管它——如果你有 CDN 或 Cloudflare，通常選它們——並讓其餘保持一致。
• **把它當成把資料排除在網址之外的替代品。**回應標頭限制了損害，但更乾淨的長期習慣，是一開始就不要把秘密和個人資料放進網址。現在先用回應標頭；把網址衛生作為後續工作提給你的開發人員。

關於相關回應標頭的簡短說明

Referrer-Policy 與我們檢查的另外幾個網頁安全回應標頭並列——Content-Security-Policy、X-Frame-Options、X-Content-Type-Options，以及幾個進階的跨源回應標頭。它們防護的是不同的東西，所以有其一並不涵蓋其餘。如果你的 Referrer-Policy 缺失，值得請修它的人同時確認其他標準回應標頭也已到位，因為它們通常設定在同一個地方，順手做完不另外花成本。

簡而言之

Referrer-Policy 是你評分卡上最便宜、最安全的隱私修復：一行，約五分鐘，沒有弄壞任何東西的風險，而且免費。它阻止訪客的瀏覽器把你私密的頁面網址——以及其中所含的任何個人資料——悄悄交給他們點過去的每一個外部站點。把它設成 strict-origin-when-cross-origin，確認它在每個頁面上都已生效，那個中等嚴重級的漏洞及其 15 分就堵上了。

常見問題