網站裝了 SSL、網址已經是 HTTPS，就代表安全設定做完了嗎？其實瀏覽器收到頁面後，還需要知道哪些資源可以載入、網站能不能被其他頁面嵌入，以及是否只能透過 HTTPS 連線。這些規則，就是 HTTP Security Headers（HTTP 安全標頭）。
SecurityHeaders.com 是一個快速檢查網站安全標頭的免費工具。輸入網址後，它會讀取網站實際回傳的 HTTP Response Headers，列出已設定與缺少的項目，並給出 A+ 到 F 的評級。這篇會說明分數怎麼看、哪些標頭重要，以及 WordPress 網站該如何安全導入。
先講結論：SecurityHeaders.com 的 A+ 代表安全標頭配置較完整，不代表網站沒有外掛漏洞、惡意程式、弱密碼或錯誤權限。它是安全健檢的一部分，不是完整滲透測試。
SecurityHeaders.com 是什麼？
SecurityHeaders.com 最初由資安研究者 Scott Helme 建立，目前是 Snyk 旗下服務。它不需要安裝外掛，也不用登入網站後台，只要送出公開網址，就能檢查該網址回應中的安全標頭。
- 進入 SecurityHeaders.com。
- 輸入完整網域，例如
https://example.com。 - 需要跟隨 HTTP 轉址時，開啟 Follow Redirects。
- 不想讓本次結果出現在首頁近期掃描，可開啟 Hide Results。
- 按下 Scan，查看評級、缺少的標頭與實際回應值。
若結果顯示 R，代表網址回傳重新導向，並不是安全分數。應跟隨轉址後再檢查最終 HTTPS 頁面。網站可能從 F、D、C 一路提升到 A 或 A+，但不要只為追分數，把不相容的政策一次強制上線。
Security Header 為什麼重要？
安全標頭是伺服器寫給瀏覽器的規則。它們不會修補 WordPress 外掛漏洞，卻能縮小部分攻擊面。例如限制可執行的 JavaScript 來源、禁止瀏覽器猜測錯誤的檔案類型、降低 Clickjacking 風險，或要求瀏覽器只使用 HTTPS。
| 安全標頭 | 主要作用 | 設定時要注意 |
|---|---|---|
Content-Security-Policy | 限制 Script、Style、圖片、Frame 等資源可從哪些來源載入，協助降低 XSS 與內容注入風險。 | 最容易影響 Elementor、分析碼、第三方字型、影片、表單與付款服務；先用 Report-Only。 |
Strict-Transport-Security | 告訴瀏覽器在指定期間只能透過 HTTPS 連線。 | includeSubDomains 與 preload 會擴大影響範圍，必須先確認所有子網域都支援 HTTPS。 |
X-Content-Type-Options | 使用 nosniff 阻止瀏覽器自行猜測 MIME Type。 | 伺服器原本就要為 CSS、JavaScript 與上傳檔案提供正確 Content-Type。 |
Referrer-Policy | 控制使用者離開頁面時，瀏覽器要帶出多少來源網址資訊。 | 政策太嚴可能減少第三方分析工具看到的來源資料。 |
X-Frame-Options | 降低網站被惡意 iframe 包住、誘導點擊的風險。 | 現代網站可搭配 CSP 的 frame-ancestors；需要跨網域嵌入時要另外規劃。 |
Permissions-Policy | 限制相機、麥克風、定位等瀏覽器功能可否在頁面或 iframe 使用。 | 視訊會議、地圖、掃碼或付款流程可能真的需要特定功能。 |
另外，舊式的 X-XSS-Protection 已被 MDN 標記為棄用。現代瀏覽器應以良好的輸出轉義、更新程式與 CSP 為主，不要因為掃描工具顯示某個 Header，就把過時設定當成主要防線。
A+ 就代表網站安全嗎？
不代表。SecurityHeaders.com 官方說明，分數反映網站送出了多少安全相關 HTTP Response Headers。它不會登入 WordPress 檢查管理員密碼，也不會取代惡意程式掃描、外掛漏洞管理、檔案權限檢查、備份或 WAF。
- 安全標頭：控制瀏覽器如何處理頁面與資源。
- Cloudflare WAF：在網站前方過濾惡意請求、Bot 與已知攻擊模式。
- WordPress 安全外掛：處理登入、檔案異動、弱點通知與惡意程式。
- 主機安全：涵蓋更新、帳號權限、Nginx／Apache、PHP、SSH 與備份。
這些層級是互補關係。若想理解主機端的實作流程，可以接著閱讀我的 Nginx VHOST 與 WordPress 防火牆設定整理；使用 Cloudflare API 自動管理設定時，也要先遵守 Cloudflare API Token 最小權限原則。
WordPress 安全標頭要設在哪裡？
常見做法有三種：在 Nginx／Apache 原始主機設定、在 Cloudflare Response Header Transform Rules 設定，或透過 WordPress 外掛送出。若可以管理主機或 CDN，我會優先放在主機或 Cloudflare，因為靜態檔案、錯誤頁與 WordPress 尚未載入時也能套用，規則也比較集中。
| 設定位置 | 優點 | 適合情境 |
|---|---|---|
| Nginx／Apache | 由來源站統一控制，回應範圍完整。 | 自有主機、VPS、可管理 VHOST 的網站。 |
| Cloudflare | 可在邊緣修改回應標頭，不必改 WordPress 程式。 | 網域已經橘雲代理，且沒有主機設定權限。 |
| WordPress 外掛 | 後台操作容易。 | 一般虛擬主機；但要避免和 CDN、主機重複送出或互相覆蓋。 |
Nginx 的低風險起始範例
以下可以當作起點，不是每個網站都能原封不動套用。先備份設定檔，確認所在的 server 或共用 include 不會被其他 add_header 覆蓋，再測試正式網址。
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;如果網站已完整支援 HTTPS，可再評估 HSTS：
add_header Strict-Transport-Security "max-age=31536000" always;先不要急著加上 includeSubDomains 或 preload。一旦套用，仍使用 HTTP 的舊子網域、內部系統或測試站可能無法開啟。變更後要先執行 nginx -t，通過才 reload，並以瀏覽器和 curl -I https://你的網域 確認最終回應。
CSP 不要直接複製貼上：先用 Report-Only
CSP 是很有價值、也最容易造成前台功能失效的安全標頭。WordPress 網站常同時載入 Elementor inline style、Google Fonts、GA4、GTM、YouTube、Meta Pixel、reCAPTCHA、LINE、金流與外部 API。直接套用嚴格的 default-src 'self'，畫面可能正常一半，按鈕、表單或付款卻已經不能使用。
比較穩定的流程，是先建立 Content-Security-Policy-Report-Only。它會回報違規，但不阻擋資源。收集實際使用的來源後，再逐步整理 script-src、style-src、img-src、font-src、connect-src、frame-src 與 frame-ancestors，最後才切換成正式 CSP。
上線前後的實作檢查清單
- 先掃描並留存：記錄原始分數、回應標頭與正常功能。
- 確認設定責任層：決定由 Cloudflare、Nginx、Apache 或 WordPress 管理，避免重複。
- 先加入低風險項目：例如
nosniff與合適的 Referrer-Policy。 - 高影響政策分階段：HSTS 先確認 HTTPS；CSP 先用 Report-Only。
- 測試真實流程：首頁、手機版、登入、Elementor 編輯器、搜尋、表單、影片、地圖、分析碼、金流與第三方登入都要實測。
- 同時檢查正常與錯誤頁：200、301、404 與 API 回應不一定套用相同設定。
- 再次掃描：確認標頭由公開網址真的送出，而不是只存在設定檔裡。
也要特別分清楚 CORS 與安全標頭的用途。CORS 決定瀏覽器中的跨網域 JavaScript 是否可以讀取資源，不是開成 Access-Control-Allow-Origin: * 就更安全。涉及登入狀態、會員資料或 API 憑證的端點，更不應直接套用萬用來源。
常見問題 FAQ
SecurityHeaders.com 是免費的嗎？
一般網站可以直接在首頁輸入網址進行公開掃描，不需要安裝 WordPress 外掛。若要透過程式大量查詢，Security Headers 另提供需要 API Key 的 API。
SecurityHeaders.com 拿到 A+，網站就不會被駭嗎？
不是。A+ 代表工具檢查的 HTTP 安全標頭較完整，不代表網站沒有外掛漏洞、惡意程式、弱密碼或主機權限問題。仍需搭配更新、備份、WAF、弱點管理與登入防護。
為什麼掃描結果顯示 R？
R 代表被掃描的網址回傳 Redirect。開啟 Follow Redirects，或直接輸入重新導向後的最終 HTTPS 網址，再查看實際評級。
WordPress 加上 CSP 後為什麼會破版？
CSP 可能阻擋 Elementor inline style、外部字型、分析碼、影片、表單或付款服務。應先使用 Content-Security-Policy-Report-Only 收集違規來源，再逐項建立允許規則與測試流程。
Security Header 應該設在 Cloudflare、主機還是外掛？
能管理主機或 CDN 時，通常優先放在 Nginx、Apache 或 Cloudflare，讓規則集中並涵蓋更多回應。只有後台權限時可使用外掛，但要檢查是否和其他層重複或互相覆蓋。
結論：先建立可驗證的安全基線
SecurityHeaders.com 很適合當作網站上線前與主機調整後的快速檢查工具。真正有價值的不是把分數衝到 A+，而是知道每一條政策保護什麼、可能影響哪些功能，並保留回復方式與驗證紀錄。
如果你的 WordPress 同時使用 Elementor、Cloudflare、會員、表單或付款功能，安全標頭應該配合實際架構設計，而不是複製一段萬用設定。需要整理主機、防火牆與網站安全層級，也可以從 WordPress 網站架設與維護規劃開始盤點。
