安全標頭檢查器

標頭來源

貼上 curl -D 的輸出或 DevTools 的回應標頭。這一版不提供「輸入網址自動掃描」—— 瀏覽器的跨來源限制會藏起大部分標頭，Set-Cookie 前端根本讀不到，掃出來的「缺少」會是假的。

網站 URL（這份回應實際的網址）沒有填的話，HSTS、Cookie 作用域這類需要知道來源的檢查會降成待確認，不會判成缺少。

資料範圍只有選「完整回應」時，找不到某個標頭才會判成缺少；否則一律寫「本次資料未提供」。

資源類型 API 不需要頁框防護，靜態資源不需要 Referrer 政策。判斷錯了可以自己改。

跨來源（CORS）的請求情境

填了才判斷得出「這個來源會不會被擋」。沒填的話 CORS 那一條只依回應本身的欄位判斷，不會替你假設一個請求。

請求來源 Origin 發出這個請求的網頁是哪一個來源。只要 scheme + 主機 + 埠，不含路徑。

credentials 模式 fetch 的 credentials 選項。帶憑證時瀏覽器不接受 Access-Control-Allow-Origin: *。

請求方法不在 GET / HEAD / POST 裡的方法一定會先送一次 OPTIONS preflight，而那一次的回應不是這一份。

這一頁含個資或登入後才看得到的內容（勾了才檢查快取設定。公開頁面設成可快取是正常的，不勾就不判定）

標頭內容

解析與判定都在這個分頁裡完成。本站不會替你發出任何請求，也不會把你貼的內容送到任何地方。

怎麼取得完整的回應標頭

瀏覽器按 F12 → Network → 點實際的文件請求 → Headers → 複製 Response Headers，另外把完整網址、方法與狀態碼填進上面的欄位。
Linux 或 macOS：curl -sS -D headers.txt -o /dev/null -- 'https://example.com/'
Windows：curl.exe -sS -D headers.txt -o NUL -- "https://example.com/"
要追轉址再加 -L。那樣下載到的標頭會有好幾段，貼進來之後在下面自己選要看哪一段。
GET 與 HEAD 的回應可能不同，所以預設不用 -I 取代 GET。需要登入才看得到的頁面建議用 DevTools 複製，貼進來之前先自行移除不必要的敏感內容。

使用說明 8 項

「找不到」與「缺少」是兩件事

只有把資料範圍選成「完整回應」時，本站才會說某個標頭缺少；其餘一律寫「本次資料未提供」。從 DevTools 挑幾列貼過來的內容本來就不完整，判成缺少會讓你去補一個其實早就設好的設定。

沒有分數，只有五種狀態

符合檢查、需改善、待確認、不適用、未支援。不會把它們壓成一個百分比或字母等第 —— 那種數字會讓「不知道」看起來像「通過」。

不提供輸入網址自動掃描

純前端的跨來源請求看不到大部分回應標頭，no-cors 只拿得到不透明回應，Set-Cookie 更是完全讀不到。用那種方式掃出來的「缺少」清單是假的，所以本站不做。

重複的標頭是資料不是雜訊

每一段回應各自保存一份有順序的標頭陣列。重複的 Set-Cookie 逐筆解析（Expires 裡的逗號是日期的一部分，不會被切壞），重複的 CSP 也不會被併成一條 —— 併了就會把兩份共同作用的限制變成一份比較寬鬆的。

幾條不會跟著別人喊的判定

HTTP 上的 HSTS 不算有效保護；preload 字樣不代表已經加入清單；API 不需要頁框防護；沒有 Access-Control-Allow-Origin 多半是刻意的同源政策；X-XSS-Protection 缺少不是漏洞。

內容不會離開這個分頁

解析、判定與報告都在瀏覽器內完成，不寫瀏覽器儲存，也不放進網址。重新整理就會清空。複製連結只會複製工具網址，不含你貼的任何內容。

要看 CSP 的細節請用 CSP 規則設計器

這一頁只檢查 CSP 存在、格式與明顯問題。兩支工具共用同一份剖析器。本站每個工具都是獨立頁面、沒有同分頁路由，所以交接改用「下載 CSP 計畫 JSON」再到那一頁匯入 —— 內容不會經過網址或跨分頁的瀏覽器儲存。

依據：WHATWG Fetch 標準、MDN 的 Strict-Transport-Security 與 X-XSS-Protection 說明、W3C CSP3。檢查清單、介面與上限是本站的產品設計，不同欄位仍要依實際部署逐項確認。