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、hash 與 strict-dynamic 擋 XSS
CSP 是 XSS 的第二道防線先把邊界講清楚：Content Security Policy 不能修掉 XSS 漏洞。輸出編碼、HTML sanitization、避免危險 DOM sink 仍是第一道防線；CSP 的工作是限制腳本從哪裡載入、哪些 inline script 能執行，以及能不能使用 eval() 這類字串執行 API，讓注入成功後不一定能跑起來。 攻擊者注入 XSS 時，塞進 DOM 的往往是 <script>alert(document.cookie)</script> 這種直接寫在 HTML 裡的程式碼，或是 onclick="..." 這類行內事件處理器。瀏覽器一旦套上嚴格的 script-src，這些東西就跑不起來——這才是 CSP 的價值所在。 當 script-src 裡的 'unsafe-inline' 真的生效，inline <script>、事件處理器與 javascript: URL 都可能被放行，CSP 對常見 XSS 注入的防護會大幅下降。其他指令仍能限制圖片、連線...
