XSS 會讓不受信任的內容在網站來源下執行；使用者應降低曝險，維護者則必須依輸出情境編碼、避免危險 DOM API，並以 CSP 作為第二道防線。
先分清楚：XSS 不是只有彈出視窗
跨站腳本攻擊（XSS）是網站把不受信任的資料當成可執行內容交給瀏覽器。真正的影響不只是一個測試用對話框；攻擊程式可能讀取頁面資料、代替使用者送出操作、改寫登入畫面，或把人導向仿冒流程。
反射型 XSS 通常由網址或表單輸入立即觸發；儲存型 XSS 會把惡意內容留在留言、個人資料或後台資料；DOM 型 XSS 則發生在前端 JavaScript 將網址、訊息或儲存資料送進危險的 DOM API。分類有助於追查來源，但修補核心都是：不要讓資料變成程式。
使用者看到哪些跡象要停下來
- 陌生人要求把程式碼貼進瀏覽器主控台、書籤或網址列。
- 網址帶有很長、看不懂的參數，開啟後頁面突然要求重新登入或授權。
- 正常網站出現與原本風格不一致的付款、驗證碼或下載提示。
- 點擊連結後帳號自行執行操作、頁面內容異常變動或跳往不同網域。
這些現象不一定都是 XSS，但足以先停止輸入密碼與驗證碼。請從書籤或手動輸入官方網址重新進入，不要延續可疑頁面的操作狀態。
使用者已經點開或操作後
先保留完整網址、發生時間與畫面，再關閉可疑分頁。若曾輸入密碼或執行陌生程式碼，應使用可信裝置變更密碼、撤銷其他工作階段、檢查帳號活動並重新設定第二因素。不要只清除瀏覽紀錄就當作問題已消失。
回報時避免把真實 Cookie、Token、密碼或他人資料貼進郵件。Kaelith 的技術問題可寄到 support@kaelith.tw，提供受影響網址、重現步驟與必要的遮蔽畫面。
維護者先追資料流，而不是只過濾關鍵字
先找出資料來源與輸出位置：查詢字串、表單、資料庫、postMessage、localStorage 與第三方 API 都可能是來源；HTML 文字、屬性、URL、CSS 與 JavaScript 字串則是不同的輸出情境。每種情境需要正確的編碼，不能靠刪除 <script> 或封鎖幾個字串。
模板預設應採自動 HTML escaping。若業務確實允許有限 HTML，使用經維護的白名單型 sanitizer，明確限制標籤、屬性與 URL 協定，並在資料進入最終輸出情境時再次處理。
前端程式選安全的 API
顯示純文字時使用 textContent；建立節點時使用 createElement 與明確屬性。避免把外部資料送進 innerHTML、outerHTML、insertAdjacentHTML、document.write、eval 或字串型計時器。URL 也應解析後限制允許的協定與目的地。
事件處理器應由程式碼註冊，不把使用者輸入拼進 onclick 等 HTML 屬性。若框架提供危險逃生口，例如「信任這段 HTML」，每個使用點都應列入安全審查。
CSP 是第二道防線，不是修補替代品
嚴格 CSP 可以限制腳本來源、禁止行內事件屬性、阻止外掛與框架嵌入，降低漏網輸入變成程式的機會。靜態網站可使用外部腳本加上明確雜湊；動態網站則可採每次回應產生的 nonce，並搭配 strict-dynamic 評估相容性。
驗證時要同時做單元測試、瀏覽器整合測試與 CSP 違規觀察。確認惡意邊界字元只會以文字顯示、沒有未覆蓋的行內腳本，也不要為了消除錯誤而加入 unsafe-inline 或過寬的萬用來源。