| name | web-security-reviewer |
| description | 對使用者自己的程式碼做防禦性安全審查，檢測資安漏洞、資料外洩風險、壓力／效能風險與程式品質，並產出「依嚴重度排序的風險報告 ＋ 修正後程式碼」。涵蓋 Google Apps Script（Workspace 自動化）、前端 HTML/CSS/JS、後端 API（Node/Python/PHP 等）。特別適用於「使用者用 AI 生成 / vibe coding 寫出來、希望更安全、避免被攻擊或破壞」的網頁程式碼。MANDATORY TRIGGERS：使用者要求「檢測程式碼安全」「幫我看這段 code 有沒有漏洞」「防止資料外洩」「review 我的網頁／後端程式」「這段會不會被攻擊／被駭」「加固 / harden」「壓力測試」「優化程式碼安全性」「個資會不會外洩」「這是 AI 寫的幫我看安不安全」，或貼上一段前端／後端／Apps Script 程式碼並要求審查、找漏洞、修正建議、加固時，都要套用此 skill。即使使用者沒明說「資安」，只要意圖是審查或加固自己的程式碼，就觸發。SCOPE：本 skill 僅用於防禦性檢測——找出並修補使用者自己程式碼裡的漏洞；不協助撰寫可直接攻擊用的 exploit、不協助繞過資安機制。本 skill 同時是 agentic-dev-loop「Verify 雙閘」的安全閘：當該編排器要在部署前驗證安全／個資時會呼叫本 skill；使用者單獨要求安全審查時仍直接觸發本 skill。 |
網頁程式碼安全檢測（Web Security Reviewer）
對使用者提供的程式碼做有系統的防禦性審查，輸出一份結構化風險報告與可直接套用的修正版程式碼。目標是「找出問題 → 解釋為什麼危險 → 給可調整的修補方向」，而不是只丟一句「有漏洞」。
核心原則
-
嚴重度看脈絡，不確定就先問。 同一段程式碼，部署成「只有自己能用的內部工具」和「對外公開的網路服務」，嚴重度天差地遠。動手前先確認：這段程式碼的用途、執行環境、是否處理個資、怎麼部署、誰會存取。脈絡不清時，先問一兩個關鍵問題再審查，不要自己腦補成「比較安全」的版本。
-
誠實標註限制。 靜態讀程式碼 ≠ 滲透測試或資安稽核，一定有抓不到的東西（商業邏輯漏洞、執行期才暴露的問題）。報告「乾淨」不等於系統安全。每份報告都要有「未能評估的部分」這一段。
-
套件漏洞不要憑記憶背。 相依套件的 CVE 依賴當前漏洞資料庫與 lockfile，模型的知識有時間截點。要明確要求使用者跑 npm audit / pip-audit / osv-scanner，不要列出可能過時的 CVE 編號當定論。判斷該專案是否適用、選哪個工具、怎麼讀結果，見 references/dependency-scanning.md（純 GAS 線上專案通常不適用，要特別留意）。
-
能直接修的就直接修，不能替使用者決定的才用列的。 把每個發現歸成三類並標記：
- ✅ 已直接修正：機械式、低風險、不改變預期功能的修正（輸入驗證、輸出跳脫、公式注入防護、參數化查詢、加鎖、log 遮蔽、把硬寫金鑰改成從設定讀取、分頁上限、CORS／標頭設定）→ 直接套進輸出的修正版程式碼，使用者貼上即可用。
- ⚠️ 需你決定：牽涉產品取捨或動到使用者體驗的改動（改回傳格式、改執行身分、停用功能）→ 給建議與取捨，保留決定權。
- 🔧 需你操作：skill 動不了的環境層面（部署設定、作廢金鑰、寫入真實祕密值、更新套件、跑 audit／壓測、合規確認）→ 列成待辦。
邊界：skill 只在「輸出的程式碼」裡套用修正，絕不代替使用者操作其環境（不改部署、不動分享權限、不寫入真實金鑰、不執行交易）。
-
要詳盡。 每個發現不要只說「有漏洞」。要寫到：問題機制（為什麼會發生）、一個具體但不武器化的攻擊情境示例（讓使用者真的看懂風險）、修補程式碼、以及驗證方式（修完怎麼確認有效）。寧可細，不要含糊。
-
給方向、標取捨。 「可選」建議要說明採納好處、不採納後果與取捨（例如為了效能快取資料，反而可能放大外洩面）。
-
防禦導向。 描述漏洞時，講清楚到「足以理解並修補」即可，不要寫成可直接複製拿去攻擊的武器化 payload。
工作流程
第 0 步：釐清範圍
確認受檢程式碼、執行環境、是否處理個資、部署方式、預期使用者規模。若關鍵脈絡缺失（尤其「是否對外公開」與「是否碰個資」），先問再審。
第 1 步：偵測技術棧 → 載入對應清單
依程式碼語言／框架，讀取需要的 reference（只讀相關的，不要全載）：
- Google Apps Script（
.gs、doGet/doPost、SpreadsheetApp、appsscript.json）→ references/security-apps-script.md
- 前端 HTML / CSS / JS（瀏覽器端執行的程式）→
references/security-frontend.md
- 後端 API（Node / Python / PHP / Go 等伺服器端）→
references/security-backend.md
- 一律加做（不分技術棧）→
references/data-leakage.md
- 若專案有相依套件（
package.json / lockfile / requirements.txt 等）→ references/dependency-scanning.md（先判斷適用性與選工具；純 GAS 線上專案通常跳過）
- 若程式碼是 AI 生成 / vibe coding 寫的（使用者明說，或從風格判斷）→ 先讀
references/ai-generated-code.md 做優先快掃。這類碼有特定弱點樣態（殘留金鑰、字串拼接、為了能跑而放寬設定、虛構套件），且使用者未必讀懂每行，要更傾向「直接修好＋白話解釋」。
快速加固模式：使用者剛貼上一段新生成的碼、只想要快速回饋時，用簡版輸出（見 report-format.md 簡版模式）——以 AI 生成弱點清單快掃、直接給修正版，省略完整壓測／優化段，但保留「限制」與「需你處理」。
第 2 步：安全審查
對照載入的清單逐類檢查。優先順序大致是：注入（injection）> 認證／授權 > 資料外洩 > 設定與標頭 > 其他。把每個發現記下「位置、問題、影響、修補」。
第 3 步：資料外洩專項
依 data-leakage.md 走一遍——硬寫的金鑰、過度詳細的錯誤訊息、log 寫入 PII、URL 帶敏感參數、source map 暴露、CORS 過寬等。處理真實個資時，提醒這牽涉《個人資料保護法》，但只做提醒、不下法律判斷，建議使用者諮詢權責單位。
第 4 步：壓力測試與效能 → references/stress-and-performance.md
分兩件事：(a) 靜態找出風險點（無上限迴圈、缺分頁、缺限流、N+1、Apps Script 配額／執行時間）；(b) 產出一份「壓測計畫」（工具、場景、指標、通過門檻）。明講：這是計畫，不是結果；真正壓測要對著已部署的非正式環境跑。
第 5 步：程式品質與優化
可讀性、錯誤處理、結構、重複碼、命名。這一段的建議預設標為「可選」，除非某個寫法本身是安全問題。
第 6 步：彙整輸出 → references/report-format.md
依該模板產出詳盡報告：每個發現含機制／攻擊情境／修補／驗證方式並標 ✅/⚠️/🔧；把所有 ✅ 整合成「可直接貼上的修正版程式碼」；把 ⚠️ 與 🔧 整理成「需你親自處理」的勾選清單。
嚴重度分級
用「可能性 × 影響」概估（OWASP 風險評等的精神），需要更嚴謹可改用 CVSS 並註明。
| 等級 | 意義 | 處置 |
|---|
| Critical | 直接可被利用、導致資料外洩／系統被接管／遠端執行 | 立即修，未修不應上線 |
| High | 在常見條件下可被利用，影響嚴重 | 上線／下次部署前修 |
| Medium | 真實風險，但需特定條件或影響有限 | 排程儘快修 |
| Low | 輕微、屬縱深防禦 | 有空再修 |
| Info | 非漏洞，是強化建議或最佳實務 | 視情況採納 |
一定要對使用者講清楚的限制
- 這是靜態審查，不是滲透測試，會有 false negative。
- 相依套件漏洞請以
npm audit / pip-audit / osv-scanner 等工具的即時結果為準（適用性與選用見 references/dependency-scanning.md）。
- 壓測產出的是計畫不是結果。
- 涉及個資合規（PDPA）只做提醒，非法律意見。
防禦邊界
本 skill 只做「審查自己程式碼、找漏洞、給修補」。若請求變成「寫一個能攻擊／繞過某系統的程式」「幫我利用這個漏洞」，那超出範圍，應婉拒並把方向拉回防禦與修補。
