這張卡只改 docs/security-report/M02-file-upload.md 一個檔，改完重 build。不碰需求中心的原始技術報告，不碰其他模組頁。母案 CM-1651（FR-086 檔案上傳資安掃描）。

這張卡在做什麼

資安總報告的 M02 頁已經寫好，但那是「工具查到什麼」的整理版。講者（決策者）逐條讀過、回程式碼查證過，過程中發現三條寫錯、若干條描述會誤導，並對七件事下了判斷。這張卡把那些更正與判斷寫進文件。

為什麼要做：這份報告會被當成稽核證據拿給客戶與老闆看。裡面有一條寫錯，稽核方查一下就知道，整份報告的可信度都會被問。三條事實錯誤是最急的部分。

一、三條事實錯誤（最急，經不起查）

E1 — 第 10 條「上傳沒有大小上限」是錯的

實際上後端有 50MB 上限，而且是請求進來就擋、不是傳完才發現（設定值 MAX_REQUEST_BODY_MB，預設 50，config/config.py:105 → core/app_factory.py:104 套用、:404-429 提前擋）。前端各上傳元件另有各自的限制（10MB～50MB 不等）。nginx 那層確實沒擋（FE repo nginx.onprem.conf:83 client_max_body_size 0），但設定檔註解明寫是刻意交給後端把關，不是疏漏。

• 屬實的只有「數量沒有上限」這半句——但整包請求受 50MB 頂著，多檔時總和仍被擋。
• 改法：這條從「缺陷」改為「不成立」；數量未限降級為改善建議，不列為資安問題。

E2 — 第 11 條措辭不準，而且要澄清與 Google Drive 無關

報告寫「設定沒特別填的話會走明文」。實查 DEV 資料庫，七筆儲存設定全部都填了、而且全部填成不加密。差別很重要：不是大家忘了填（疏忽），是目前的實際設定就是不加密（現況）。

另外要明確寫出：這條講的是我們自己裝在客戶機房的物件儲存（MinIO／SeaweedFS）連線，與 Google Drive 無關——Drive 走 Google 官方工具，底層固定加密，連「要不要加密」這個開關都沒有。目前讀者很容易誤會成 Drive。

• 修法也要跟著改：不能只改預設值（現有環境都明確填了 false，改預設對它們無效）。真正要做的是出貨裝機時預設開啟加密，現有環境另外評估切換。

E3 — 第 8 條整條要重寫（性質判斷錯了）

報告把它寫成「要先做產品決策：客戶之間共用儲存空間是不是刻意的設計」。查證結果不是——它是 2026-07-29 commit d20ac604 修「背景工作把檔案存錯租戶」時加的讀取端過渡措施，commit message 原話是「搬家完成前與未來零星錯位的讀取保底」。那次已經把寫入端治本（背景工作改用該工作所屬租戶解析），這段只是讓已經存錯的舊檔還讀得到。搬家從來沒做，所以它留到現在。

而且它不是「借系統預設」——系統層設定確實存在（ROOT 租戶 id=1 那一列），但正規取系統預設的程式都寫死 tenant_id=1，只有這段沒有任何租戶條件、是撈全部 ORDER BY id 取第一筆。實際資料上 ROOT 那列 id=60 排在業務租戶 id=23 後面，所以它永遠撈不到系統那列，實際借到的是最早建立的那家客戶。

• 現在會走到的三種情況：①租戶完全沒有儲存設定（DEV 有 3 個租戶是這樣，自動複製機制 CM-1282 只對之後新建的生效，先前建的沒回頭補）②租戶換過儲存後端（舊檔記著舊型別）③當初那批錯位的舊檔。
• 要一併寫進文件的觀察：DEV 那六筆儲存設定的位址、空間名、帳號完全相同，所以開發環境借到誰的都看不出差別——要等客戶各自接自有儲存才會現形。這是典型的「驗收環境打折掩蓋缺口」。

二、描述要修正（不是錯，是不夠準或會誤導）

D1 — 第 2 條（免登入下載通行證）