CSP 內容安全政策實戰指南：透過 HTTP 標頭防禦 XSS 與資料注入攻擊

XSS 攻擊至今仍是 OWASP Top 10 的常客。CSP（Content Security Policy）透過一行 HTTP 標頭，讓瀏覽器主動攔截惡意資源，是現代 Web 防禦的第一道防線。

CSP 的運作原理

CSP 的核心是伺服器回傳 Content-Security-Policy HTTP 標頭，內含一組「指令（Directive）」白名單。瀏覽器收到後，會依規則判斷每項資源是否允許載入。常見指令包括 script-src（控制 JavaScript 來源）、style-src（控制 CSS）、default-src（作為所有資源的預設規則）。當頁面嘗試執行未列入白名單的腳本時，瀏覽器會直接封鎖並回報違規，無需應用層介入。這使得即便攻擊者注入了惡意 script 標籤，瀏覽器也不會執行它。

關鍵指令與安全設定策略

部署 CSP 時，避免使用 unsafe-inline 與 unsafe-eval 是最重要的原則，這兩個關鍵字會允許內聯腳本與動態程式碼執行，幾乎等同於關閉保護。若需支援內聯腳本，應改用 nonce（每次請求隨機產生的一次性令牌）或 hash（腳本內容的 SHA 雜湊值）來精確授權。此外，report-uri 或 report-to 指令可將違規事件回報至指定端點，協助監控潛在攻擊。建議先以 Content-Security-Policy-Report-Only 標頭進行測試，不封鎖資源只蒐集報告，待規則穩定後再切換為強制執行模式。

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-rAnd0mT0ken';
  style-src 'self' https://fonts.googleapis.com;
  img-src 'self' data:;
  report-uri /csp-violation-report;

💡 重點整理

• default-src 'self' 是最小權限原則的起點，僅允許同源資源。
• 以 nonce 或 hash 取代 unsafe-inline，精準授權內聯腳本。
• 先用 Report-Only 模式蒐集違規報告，再切換為強制執行。
• report-uri 讓你即時掌握攻擊嘗試，形成主動防禦回饋迴圈。

CSP 不是銀彈，但它是目前最有效的 XSS 緩解機制之一。從 Report-Only 模式起步，逐步收緊規則，是將 CSP 導入生產環境最穩健的路徑。

📚 參考文獻

1. MDN Web Docs — Content Security Policy (CSP)：最完整的 CSP 指令說明與瀏覽器相容性參考。
2. Google CSP Evaluator & 指南：Google 提供的 CSP 最佳實踐與 nonce-based 策略建議。

⚠️ 本文內容基於撰寫時的最新資訊，實際應用時請參考官方文件的最新版本。