先界定業務真正需要甚麼檔案
即使發送者是多年客戶，附件仍屬未經信任的輸入。報價表格可能需要圖則和相片，保養申請可能需要收據。先逐一寫明每個上載欄位的用途，以及完成工作真正需要的檔案類型。沒有明確用途的欄位就應刪除。這樣可減少系統必須解析、儲存和展示的內容。OWASP 建議只容許業務所需的副檔名，而不是概括接受所有文件。
給客戶的說明應具體列明可接受格式、文件須顯示哪些資料，以及無法上載時的處理方法。表格拒收附件後，不應悄悄叫客戶把同一份敏感文件寄到無管理的共用郵箱。應設立人工協助渠道，並沿用相同的存取、保存及處理規則。限制大小也是產品決定：過小可能擋住清晰圖則，容許龐大壓縮檔則令審查及容量規劃困難。上線前要用具代表性的客戶檔案測試。
容許提交檔案與容許讀取檔案，是兩個不同權限。公開查詢表格或許要讓未註冊人士上載，但不代表收到的檔案應成為公開網頁資產。系統應給上載檔案一個私有個案編號，讓獲授權的負責團隊經應用程式取得。給客戶的確認訊息應確認個案已收到，而非暴露儲存網址。流程亦須決定哪些附件屬可選，免得上載失敗時連原本有用的查詢也一併消失。
檢查不能只看檔名
檔名及瀏覽器提供的內容類型，只是上載者的聲稱，不能證明檔案安全。伺服器應先解碼和標準化檔名，再檢查副檔名，拒絕含糊或危險名稱，並在可行情況下核對檔案結構與聲稱格式。OWASP 指出連檔案特徵檢查也可以被繞過，因此不能單靠任何一項測試。若員工需要看原檔名，只宜把它當成經適當轉義的資料；實際儲存名稱應由系統另行產生。絕不能讓客戶提供的路徑決定檔案存放位置。
每個耗用資源的階段都要設定限制，包括接收要求、解壓、掃描、產生縮圖和其後下載。壓縮檔到達時可能很小，展開後卻佔用大量資源。若業務不需要壓縮檔，就不要接受；若必須接受，便要訂明誰可提交、可包含甚麼內容，以及展開過大或層數過深時怎樣處理。掃描失敗或解析器不支援時，檔案必須維持不可供一般員工取用，不能因掃描器逾時就悄悄當作成功。
病毒掃描和內容清除重建可降低某些格式的風險，但都不是萬能保證。要先決定哪些文件格式需要這些步驟，以及處理期間客戶看見甚麼狀態。例如可顯示「已收到，檢查中」，若檔案不能使用再另行通知。對接近提交期限的客戶，這個區別尤其重要。營運紀錄應保留拒收原因，但不要把可疑字串原樣顯示於瀏覽器錯誤訊息，也不要把可疑附件寄回客戶。
接收區與員工使用區分開
依 OWASP 建議，新上載檔案應存放在公開網站根目錄以外，或獨立儲存服務中。接收紀錄應連繫私有檔案編號、個案、提交者、驗證狀態及獲准讀取的人員。員工每次點開附件都應重新檢查權限；複製出來的直接連結不應成為永久繞過個案權限的捷徑。下載時應使用受控回應，並按格式設定合適的下載處理方式。避免在具高權限的管理頁面內直接嵌入可執行的上載內容。
應把放行條件寫成團隊可觀察的狀態：完成所需驗證、設好個案權限，並在員工介面清楚顯示狀態後，檔案才可使用。任何一步失敗，都應告訴個案負責人下一步怎樣做，而不暴露可疑檔案。主管可要求客戶改交較安全格式，或經獨立、受限制程序處理例外。例外必須記錄批准者、標準途徑失敗原因及暫時保障，否則例外很快會變成慣常做法。
檔案保存亦需要負責人。應按機構實際紀錄政策，決定何時刪除拒收檔案、未完成上載和已結案附件。刪除須同時處理儲存物件及應用程式引用，否則「已刪除」個案仍可能留下可取得的檔案。相反，若爭議或法律保留要求保存，流程必須暫停例行清理，直至保留解除。本文不能為所有香港客戶文件定出劃一保存期；期限取決於紀錄性質和適用責任。
以保養申請作一次演練
假設零售商的保養表格接收收據相片和簡短描述。客戶提交一張普通檔名的照片；服務先建立申請，按容許的圖像格式及大小限制檢查，再私下儲存，在可用時掃描，最後標記為可供服務團隊使用。這只是示範流程，不是聲稱有某零售商實際這樣運作，更不表示掃描可令檔案絕對安全。客戶收到個案編號及清楚狀態，職員則經個案開啟影像，而非公開網址。
再於測試環境試三種不利情況。第一，把不支援的文件改成容許的圖像副檔名；接收流程應拒收，而非相信副檔名。第二，提交超出已公布大小限制的真實圖片；客戶應得到可行的修正途徑，而產品若容許，文字申請也應保留。第三，中斷掃描或儲存；檔案應維持待處理或失敗，不能靜靜變成可用。適當的營運人員必須看見結果，免得客戶一直等待其實無法開始的審查。
找一位不參與項目的同事，以較低權限測試帳戶走一次員工流程。他不應能透過修改編號、重用複製連結或查看拒收項目來取得其他申請的檔案。再請個案負責人找出可用附件，並在不依賴開發員的情況下說明狀態。這同時檢查保安和操作清晰度。把觀察結果記為驗收證據，列明測試環境及格式；單靠流程圖不能證明已部署系統的行為。
先議定可驗收的界線
委託開發或修改上載功能前，先寫一份簡短接收規格：容許格式、大小及數量限制、存取角色、驗證狀態、給客戶的訊息、保存負責人和例外路徑。請開發員展示檔案由接收至刪除的整段旅程。業務負責人決定便利與處理成本的取捨，工程人員則交代哪些檢查已真正實作。「安全上載」過於含糊，不能驗收。這份規格可直接成為供應商或內部團隊的精簡驗收清單。
第一版應只涵蓋最小而足夠的格式集合。上線後檢視失敗提交及支援要求，先區分真實客戶需要與惡意或格式錯誤流量，再決定是否調整限制。多人要求新增格式，或許值得設計新處理途徑，但不應因此叫員工繞過檢查，改開電郵附件。新增解析器或預覽工具會擴大處理範圍，也要另行測試。員工指引與客戶說明應同步更新，讓公開承諾與實際處理一致。
對中小企而言，眼前決定是現有表格有沒有清楚可靠的界線。測試一個有效檔案、一個偽裝檔案、一個過大檔案及一次處理中斷，再查看客戶和低權限員工各自看見甚麼。若機構說不清檔案放行前在哪裏等候、誰可開啟、拒收時如何處理，就應先補足這些缺口，再擴大可接受格式。這會建立日後改進的基線，同時不會假裝單一措施可以消除所有上載風險。
進行前先確認
- 客戶能否分辨「已收到」與「可處理」？
- 低權限員工是否只能取得獲分派個案？
- 掃描失敗後檔案是否仍不可使用？
