CSP 生成器
勾選指令和來源，本頁會為你拼出一行正確的 Content-Security-Policy，可用於響應頭或 <meta> 標籤 —— 並附上真正要緊的提醒：哪些指令絕不回退到 default-src、雜湊或 nonce 何時會悄悄覆蓋 unsafe-inline、以及 strict-dynamic 會關掉什麼。內建的 SHA-256/384/512 雜湊生成器能把內聯指令碼和樣式變成 'sha256-…' 來源。全部在你的瀏覽器裡執行；不上傳任何內容。
未勾選的指令不會出現在策略裡；勾選了卻沒選任何來源的指令會被忽略。'none' 會取消同一行裡其它勾選。額外來源框接受逗號分隔的列表：主機名（cdn.example.com）、協議（https:）、雜湊和 nonce，帶不帶引號都可以。
這四條不會回退到 default-src：省略它們就意味著“不限制”，所以一份完整的策略會顯式設定它們。
還沒有生成任何內容。勾選一些來源後按生成策略，或載入 OWASP 基線示例。
把 <script> 與 </script>（或樣式塊）之間的內容逐字節粘貼進來——不要多出開頭或結尾的換行——然後選擇一個算法。結果就是 CSP 3 要求的 'sha256-…' 來源。
雜湊結果會顯示在這裡。
只要有可能，就用響應頭而不是 meta 標籤部署。響應頭才是完整的 CSP：
frame-ancestors、
report-uri 和
report-to 只在響應頭裡生效，而且響應頭在第一個位元組的 HTML 被解析之前就已生效。meta 標籤只是無法配置伺服器時的靜態檔案兜底方案。本站的
安全響應頭檢查可以檢視你站點實際發出的響應頭，
HTTP 響應頭解析器則可以逐段拆解原始響應塊。
自測
用一組固定狀態重跑構建器：來源排序、'none' 互斥、OWASP 基線字串、nonce 與雜湊的引號處理、base-uri / form-action / frame-ancestors 的無回退提醒、nonce 或雜湊覆蓋 unsafe-inline、strict-dynamic 提醒、Report-Only 響應頭名稱、meta 標籤排除項、用獨立計算的 SHA 向量校驗雜湊生成器，以及各條失敗路徑。不會向任何地方傳送資料。
什麼是 Content Security Policy？
一句話：CSP 是伺服器隨頁面一起發出的一份白名單，它告訴瀏覽器指令碼、樣式、圖片和連線究竟可以從哪裡來 —— 這樣一來，即使攻擊者注入了 HTML，被注入的指令碼依然載入不了，因為它的來源不在名單上。
三類指令
| 類別 | 示例 | 控制什麼 | 會回退到 default-src 嗎？ |
|---|
| 抓取指令 | script-src、style-src、img-src、connect-src、font-src、object-src、frame-src、worker-src、media-src、manifest-src | 各類內容可以從哪裡載入 | 會 —— 未勾選的指令繼承 default-src |
| 文件指令 | base-uri、form-action、frame-ancestors、sandbox | 頁面自身可以做什麼（能否被嵌入、表單能提交到哪、相對 URL 基於什麼解析） | 不會 —— 每一條都必須顯式設定 |
| 上報與其它 | report-uri、report-to、upgrade-insecure-requests | 違規報告發往哪裡，以及舊式 URL 的升級 | 不會（它們不是抓取指令） |
最尖銳的幾個坑，每段一個
'unsafe-inline' 與雜湊、nonce 的博弈。如果一條指令裡包含 nonce 或任意雜湊來源，CSP 3 規定 'unsafe-inline' 會被忽略 —— 它留在那裡只是為了照顧非常老的瀏覽器。這就是為什麼“我們加了 nonce，但為了保險還留著 unsafe-inline”實際上意味著現代瀏覽器只認 nonce。本生成器會把這種組合標出來，讓它變成一個主動決定，而不是無心之失。
strict-dynamic 會廢掉你的白名單。在 script-src 裡寫上 strict-dynamic 後，主機來源、協議、'self'、'unsafe-inline' 和 data: 在載入指令碼時全部被忽略；只有 nonce 和雜湊起作用，而且由可信指令碼載入的指令碼還能繼續載入更多指令碼。這是執行載入器指令碼的現代做法 —— 但它也讓你 script-src 列表裡剩下的內容變成了擺設。
meta 標籤是二等公民。frame-ancestors、report-uri 和 report-to 在 <meta http-equiv> 裡會被忽略。本生成器會指出你的策略裡哪些部分會靜默失效。
常見錯誤
- 從
default-src * 起步，再掛一長串例外。應該反過來：先設一個收緊的 default-src 'self'，然後只放寬確實需要放寬的指令。收得緊的策略會在測試期間響亮地失敗；放得寬的策略會永遠靜默地失敗。
- 發一份
script-src 'unsafe-inline' 'unsafe-eval' 就算完事。這樣的策略幾乎攔不住 XSS 攻擊想做的任何事。給你的指令碼加 nonce 或雜湊，加上 strict-dynamic，並在生產環境持續執行 report-only 以便發現迴歸。
- 忘了
default-src 並不能覆蓋一切。base-uri、form-action、frame-ancestors 和 sandbox 都沒有回退機制 —— 這是真實世界 CSP 部署中最常被提到的漏洞。
- 一上來就用強制模式測試。先帶上報收集器跑一週 Report-Only，讀完報告再切到強制執行。一個把結賬流程搞壞的策略，比沒有策略更糟。
- 雜湊時把空白字元算錯了。雜湊覆蓋的是內聯塊的精確位元組；某個“順手”去掉結尾換行的構建步驟會讓每一個雜湊都失效。請對實際釋出出去的內容生成雜湊，而不是對原始碼生成。
常見問題
如果我把每條指令都列出來了，還需要 default-src 嗎？不需要，但把它當底線留著是好習慣：未來瀏覽器裡新增的抓取指令就會預設走你的基線，而不是預設“允許”。
upgrade-insecure-requests 到底做了什麼？它告訴瀏覽器把頁面要載入的每一個 http:// URL —— 圖片、樣式、fetch —— 在發起請求之前改寫成 https://。它是遷移工具；最終目標應該是頁面上根本沒有 http:// 連結。
用 nonce 還是雜湊？能控制伺服器響應時用 nonce（每次響應一個隨機值，響應頭和每個 script 標籤裡都要有）。HTML 是靜態或被快取時用雜湊。永遠不要用固定 nonce —— 不變化的 nonce 只是繞了遠路的 unsafe-inline。
為什麼策略發出去了卻收不到違規報告？檢查你是不是處於 Report-Only（只上報）；檢查 report-uri 是否指向一個接受 POST 的收集器；還要檢查你是否同時配置了現代 report-to 指令所要求的 Reporting-Endpoints / Report-To 機制。
CSP 能替代其它防護措施嗎？不能。它只是其中一層：繼續轉義你的輸出、繼續給 Cookie 加 HttpOnly 和 Secure、繼續啟用 HSTS。本站的 安全響應頭檢查會對整套防護做評分。
