AI 篤定說 CSP 的 style-src unsafe-inline 拿不掉，我追問一句後它道歉了
2026-06-01 早上，甲方把一份 ZAP 弱掃報告丟過來，四條中風險全是 CSP（Content Security Policy，瀏覽器用來限制頁面能載入哪些來源的一層 HTTP header 防護）相關，附帶一句「中風險都要修」。最難纏的一條是 style-src 'unsafe-inline'。 我把報告丟給 Claude Code，請它評估。那天它給的結論是：這條技術上修不乾淨，只能寫一封信去說服甲方接受。兩天後，我們把它從正式機完全拿掉了，全站 94 個頁面實測零影響。 中間發生的事，比結論本身有意思——因為它一開始錯得很徹底，而我差點就照單全收了。 先搞清楚 V3 到底還剩幾條Claude Code 先把我們 Vue 3 專案正式機的 Web.config 拉出來對。弱掃報告裡那串髒兮兮的 CSP 其實是同台 server 上舊版 AngularJS 站台的，不是 V3 的。V3 的狀況比我以為的好： 1234script-src 'self' 'wasm-unsafe-eval'style-src &#x...
Content Security Policy 設定指南：nonce 才是正解，unsafe-inline 是最後手段
CSP 擋 XSS，靠的是禁止執行 inline script先把一件事講清楚，後面整篇都建立在這上面：Content Security Policy 能擋跨站腳本（XSS），核心機制就是禁止頁面執行行內（inline）的 script。 攻擊者注入 XSS 時，塞進 DOM 的往往是 <script>alert(document.cookie)</script> 這種直接寫在 HTML 裡的程式碼，或是 onclick="..." 這類行內事件處理器。瀏覽器一旦套上嚴格的 script-src，這些東西就跑不起來——這才是 CSP 的價值所在。 所以當你在 script-src 加上 'unsafe-inline'，等於告訴瀏覽器「行內 script 全部放行」。攻擊者注入的那段也一起放行了。這時候 CSP 對 XSS 的防護等於拆掉，剩下的 default-src 'self'、白名單域名都救不回來。 配置 CSP 的目標因此很單純：讓網站不靠 'unsafe-inline' 也能正常...
