標頭設定範例到處都是。問題是其中大多數已經停止更新。照抄幾年前正確的清單，就會帶進已經失去作用的標頭，以及一個可能實際造成危害的標頭。
① 現在值得設定的 6 個
本站的安全標頭檢測工具以這 6 個來評分。已棄用的標頭刻意排除在外。
- Content-Security-Policy
- 宣告腳本和資源可以從哪裡載入。是縮小 XSS 能做的事的核心控制。它的
frame-ancestors也控制內嵌 - Strict-Transport-Security
- 告訴瀏覽器一律用 HTTPS 回來，堵住第一次的明文請求（
max-age加上includeSubDomains） - X-Frame-Options
- 拒絕被其他網站放進框架，用來防禦點擊劫持。實務上會和 CSP 的
frame-ancestors一起設定 - X-Content-Type-Options
nosniff。阻止瀏覽器從內容猜測類型，減少上傳的檔案被解讀成不該是的東西的事故- Referrer-Policy
- 限制往外傳遞的 referrer，減少放進 URL 的資訊外洩（前提是你本來就不把機密放在 URL 裡）
- Permissions-Policy
- 預設停用瀏覽器的功能，例如相機、麥克風、地理位置。用不到的就關掉
順序很重要：從不會弄壞東西的開始
X-Content-Type-Options、X-Frame-Options、Referrer-Policy 和 Permissions-Policy 可靠且不容易弄壞畫面，可以先加。Strict-Transport-Security 要等所有路徑的 HTTPS 都正常後再加，因為瀏覽器會記住它，要撤回很麻煩。
CSP 最後加，而且要逐步導入。它影響的功能最多，一次就設得很嚴格會弄壞正常的功能。請用 CSP 產生器逐步建立。
② 已經失去作用的
Expect-CT：自 2021 年 6 月起大致已無作用
MDN 把這個標頭標為 Deprecated，並說明只有 Google Chrome 和其他以 Chromium 為基礎的瀏覽器實作過它，而 Chromium 從 107 版起棄用了這個標頭，因為 Chromium 現在預設就會強制執行 CT。同一頁的附註還寫道「Expect-CT 自 2021 年 6 月起大致已無作用」。
換句話說，瀏覽器開始預設這麼做，網站已經沒有需要指示的東西。沒有理由在新的設定中加入它。
③ 現在可能造成危害的
X-XSS-Protection：已棄用、非標準，而且可能製造 XSS
MDN 在這個標頭上同時掛著 Deprecated 和 Non-standard 的標示，另外還有一則警告：「雖然這個功能能保護不支援 CSP 的舊瀏覽器使用者，但在某些情況下，X-XSS-Protection 可能在原本安全的網站上製造 XSS 漏洞。」
它的建議毫不含糊：「建議使用 Content-Security-Policy，而不是 XSS 過濾。」
這是反駁「標頭越多越好」的決定性例子。出於好意加上的設定，在特定條件下可能變成攻擊面。沒有送出的話就不要加；已經在送的話，請規劃移除。底層的缺陷請見什麼是 XSS。
過時清單的樣子
CSP、HSTS、X-Frame-Options 和 nosniff，再加上
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …
清單比較長，有些檢測工具甚至可能給更高的分數。但對目前的瀏覽器而言，這些多出來的項目不是沒有作用，就是可能造成危害。
現在的做法
以 CSP 為中心，其他 5 個在旁支援。
已棄用的標頭不加，已有的就移除。把心力放在 CSP 的品質上，具體來說就是你消除了多少 'unsafe-inline'，換到的實際防禦遠比把清單拉長多得多。
前提：標頭不會修好漏洞本身
應用程式的缺陷（XSS、授權缺失、上傳）
再多的標頭也無法消除這些
↓ 一旦發生
標頭控制的東西
資料可以送到哪裡・頁面能否被放進框架・是否允許明文 ＝ 限制擴散
在有 XSS 缺陷的網站加上 CSP，並不會讓 XSS 消失，而是縮小它能做的事。所以順序是：先修好應用程式的缺陷，再把標頭疊上去當作多一道防線。反過來也成立：標頭拿到滿分，不能證明網站是安全的。
檢查自己的網站
測量實際回傳的內容
讀回應，而不是設定檔。反向代理、CDN、框架和應用程式本身都會新增或覆寫標頭，所以設定的內容和實際送出的內容不一定相同。本站的標頭檢測工具會直接測量 URL。
在輸出中找已棄用的標頭
如果回傳了 X-XSS-Protection 或 Expect-CT，請規劃移除。尤其是前者，如上所述，文件明載它可能製造漏洞。
加上不會弄壞東西的 4 個
X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Referrer-Policy: strict-origin-when-cross-origin，以及關閉用不到功能的 Permissions-Policy。可靠，而且不容易影響畫面。
HSTS 等 HTTPS 完全正常後再加
Strict-Transport-Security 會被瀏覽器記住，在 HTTPS 還不穩定時啟用，復原會很痛苦。請先確認所有路徑都提供 HTTPS。憑證的基礎知識請見什麼是 Let's Encrypt。
本站的看法：照抄的設定，來源有多舊就決定了它有多安全
安全標頭是最典型的複製貼上式設定，正因如此，來源有多舊決定了結果有多安全。本文提到的兩個標頭都曾經是正確的。X-XSS-Protection 甚至更進一步：當年的建議，成了今天的警告。
我們的立場是把標頭設定當作偶爾要重新檢視的設定，而不是做一次就完成的工作，也不要以檢測工具的分數為目標，因為加上已棄用的標頭也可能讓分數上升。請把時間花在 CSP 的品質上，而不是清單的長度。
資料來源（一手資料）
- MDN Web Docs「X-XSS-Protection」— developer.mozilla.org（Deprecated 與 Non-standard 標示、可能在原本安全的網站上製造 XSS 漏洞的警告，以及改用 CSP 的建議）
- MDN Web Docs「Expect-CT」— developer.mozilla.org（Deprecated 標示、Chromium 107 棄用及其理由，以及自 2021 年 6 月起大致已無作用的附註）
兩者皆於 2026 年 9 月 5 日確認。
接著讀
FAQ
Q應該設定 X-XSS-Protection 嗎？
不應該。MDN 把這個標頭同時標為 Deprecated（已棄用）和 Non-standard（非標準），並警告：雖然它能保護不支援 CSP 的舊瀏覽器使用者，但在某些情況下，X-XSS-Protection 可能在原本安全的網站上製造 XSS 漏洞。它的建議很明確：用 Content-Security-Policy 取代 XSS 過濾。沒有送出的話就不要加；有送出的話，請規劃移除。
QExpect-CT 還需要嗎？
不需要。MDN 把它標為 Deprecated，並說明只有 Google Chrome 和其他以 Chromium 為基礎的瀏覽器實作過它，而 Chromium 從 107 版起棄用了這個標頭，因為 Chromium 現在預設就會強制執行憑證透明度（Certificate Transparency）。同一頁的附註寫道，這個標頭自 2021 年 6 月起大致已無作用。沒有理由在新的設定中加入它。
Q那應該設定哪些？
我們的標頭檢測工具用來評分的 6 個是實用的起點：Content-Security-Policy、Strict-Transport-Security、X-Frame-Options、X-Content-Type-Options、Referrer-Policy 和 Permissions-Policy。已棄用的標頭刻意不包含在內。順序上，先加可靠且不容易弄壞東西的（nosniff、X-Frame-Options），CSP 因為影響的功能最多，要逐步導入。
Q所有標頭都設好了，網站就安全了嗎？
不是。標頭不會修好應用程式的漏洞，它們限制的是損害擴散的範圍。在有 XSS 缺陷的網站加上 CSP，並不會讓 XSS 消失，而是縮小它能做的事。請先修好應用程式的缺陷，再把標頭疊上去當作多一道防線。反過來也成立：標頭檢測拿到滿分，不能證明網站是安全的。