今天介紹一下 XSS，很實用也很常見。XSS 本質上是「把攻擊腳本塞進網站，讓其他使用者在不知情下執行惡意 JavaScript」，結果可能是竊取 Cookie、竄改頁面、或植入鍵盤記錄器之類的東西。

XSS 三大類型（重點）

• Reflected XSS（反射型）：攻擊程式碼隨請求被伺服器回傳，常見於搜尋或錯誤訊息頁面。攻擊通常靠誘導使用者點開特製 URL。
• Stored XSS（儲存型）：攻擊程式碼被永久存到伺服器（留言板、論壇、評論欄），之後任何人載入該頁面都會執行。傷害最大且最常見。
• DOM-based XSS（DOM 型）：攻擊是由前端 JS 操作 DOM 時將不安全輸入直接插入頁面而造成，伺服器未必看到攻擊內容。

常見利用場景與後果

• 竊取使用者 Session Cookie → 以受害者身份登入。
• 偽造轉帳或表單提交（在使用者已登入的情況下）。
• 植入惡意腳本做瀏覽器指紋、鍵盤紀錄或跳轉釣魚頁面。
  結果可能造成個資外洩、財務損失或品牌信譽受損。

基本防禦措施（實務可立刻做的）

1. 輸出編碼（Output Encoding）：在把使用者輸入放到 HTML 上時，一律做轉義（例如把 < 轉成 <）。框架通常有現成函式要用。
2. 輸入校驗（Input Validation）：不要單靠輸入檢查來防 XSS，但可作為輔助（例如禁止 HTML 標籤）。
3. Content Security Policy（CSP）：設定 CSP 限制可執行的資源來源，能大幅降低攻擊成功率（但需小心配置）。
4. HttpOnly 與 Secure Cookie：把敏感 Cookie 設為 HttpOnly（JS 讀不到）與 Secure（只在 HTTPS 傳輸）。
5. 避免 innerHTML / 不安全的 DOM 操作：前端用 textContent 或安全的 template 方法來插入文字。
6. 輸出的位置不同策略不同：放在 HTML body、屬性、JS context 或 URL 中時，需使用對應的編碼方式。

開發與測試建議

• 在開發環節加入自動化掃描（如 OWASP ZAP、Burp Suite 被動掃描）。
• 測試時模擬攻擊（測試環境），特別是留言/評論/上傳功能要重點檢查。
• 教育前端工程師不要直接把未處理的使用者輸入丟進 DOM。

小結

XSS 看起來像前端的問題，但其實是整個 full-stack 的責任：前端不要亂用 innerHTML，後端要把輸出轉義，系統應配置 CSP 與安全 Cookie。把這幾件事做好，XSS 的風險就能被大幅降低。