本卡屬 module_frame 資安掃描母案（見母卡），第 B5 棒。只掃不修。範圍 3 檔／1376 行。盤點檔：docs/features/FR-113-2609-oscal-host-wiring-security-scan/module-frame-scan-inventory.md

這一棒在做什麼（白話）

掃「範本的控制項清單，可以下載成 Excel、填好再上傳回來」這條功能的 3 支檔、1,376 行。一共 6 個網址入口：下載空白範本、下載匯出檔、上傳填好的檔、驗證上傳的檔、驗證資料、存檔。找出誰能打這些入口、打了能改到誰的範本，產出一份報告。只找問題、不修問題。

🔴 為什麼這一棒排全批第一順位

兩個訊號疊在一起，是這批裡最強的：

• 權限關鍵字 0 次命中：app/module_frame/service/module_frame_template_import_service.py（1,011 行、6 支公開方法）整支檔 grep require_／authz／permission／Forbidden，一個字都沒有。這個訊號跟 FR-113 的 O2 當初鎖定、後來確認真的有洞的 resource_library_app_service.py 是同一種強度。
• 同時含下載與批次寫入兩種高風險路徑：跨 arc 總表第 128 項（下載，能把別家公司整份系統安全計畫下載成 Excel）已經證實下載是最容易漏掉歸屬檢查的形狀；而這支還有 save_import 這種會批次改動範本底下控制項實施記錄的寫入路徑，比純讀的清單風險更高。

重點看什麼

**最重要的一件事：路由層已經有角色權限檢查了，但那不能回答「這份範本是不是你家的」。**盤點時已經抽查過，module_frame_template_import_route.py 的 6 個入口都掛了 @jwt_required ＋ @require_capability("module-frame.read" 或 "module-frame.create")——那是角色權限檢查，只問「你這個角色能不能用這個功能」，不問「這份範本是不是你們公司的」。所以重點在下一層。

• 🔴 逐支核對 module_frame_template_import_service.py 的 6 支公開方法：每一支在拿到 module_frame_uid 之後，有沒有用 assert_scope_writable 這類方式、或比對「範本的 tenant_id 對呼叫者的 tenant_id」來確認歸屬？還是只確認「這個 uid 查得到」就往下動？（B2 那邊看到的模式是 verify_module_frame_exists_by_uid，只確認存在、不確認屬於誰——這裡要確認是不是同一種寫法。）
• 🔴 兩條下載／匯出路徑（下載空白範本、下載匯出檔）：能不能拿別人的範本編號下載到別家公司的內容？這正是總表第 128 項的形狀。
• 🔴 save_import 這條存檔路徑：它會批次改動範本底下的控制項實施記錄。查「檢查 A、動手改 B」——檢查的是網址上那個範本，實際寫進去的是不是使用者另外送上來的編號？
• 上傳與驗證那幾支：使用者上傳的 Excel 內容會被怎麼處理——有沒有欄位數／列數上限、有沒有把儲存格內容直接當成系統內的編號來用、= + - @ 開頭的儲存格內容有沒有被中和（公式注入）。

範圍與邊界

本棒 3 檔／1,376 行：路由入口 260 行、序列化 105 行、商業邏輯 1,011 行，一條完整路徑，不用往別棒補。

不在本棒：產生 Excel 檔案的底層機制（app/module_frame/excel_template/ 那 7 支）在 B6；匯出整份 SSP 那條不同的路在 B4。看到程式呼叫 excel_template 的地方，只看「傳進去的是不是使用者可控」，不要追進去看它自己怎麼做。

盤點檔在 docs/features/FR-113-2609-oscal-host-wiring-security-scan/module-frame-scan-inventory.md，裡面有完整的範圍界定、八棒切法與推導。有疑問先翻盤點檔，但範圍以本卡為準。

🔴 先更正一件事：不要拿「完全沒有權限檢查」去掃

跨 arc 總表曾寫「這部分的功能入口只驗證有沒有登入、完全沒有功能權限檢查」。這句話經首腦實際查過程式碼，不成立，照抄去掃會掃出一整棒誤報。實際情況是：系統安全計畫（SSP）那條線的權限是有守的，只是守在下一層——網址入口那層只驗「有沒有登入」，真正判斷「你是不是這個專案的人、是不是負責人」寫在下一層的商業邏輯程式（app service）裡。這種「入口只驗登入、權限守在下一層」的寫法，是本專案 CLAUDE.md 明文允許的正規做法（原文：資源域守門維持 app service 層），不是漏洞。

所以這批掃描要問的問題是「逐支公開方法核對守門是不是齊全」，不是「找沒有守門的端點」。