2026 年 10 月 16 日，91APP 公告 Commerce Cloud 資料庫遭自動化攻擊，部分資訊被未經授權擷取。
四天後，主管機關表示，受影響的個資種類、人數與資料筆數仍待釐清。
對使用第三方購物車的品牌來說，最難回答的往往不是「平台有沒有被攻擊」，而是：
「如果會員資料真的流出，我們怎麼證明資料在品牌端原本是怎麼管理的？」
平台被攻擊，不等於每一家品牌都有責任；但把購物車外包，也不代表品牌管理的所有會員資料和權限都跟著外包了。
91APP 10/16 公告｜數位產業署 10/20 行政檢查說明
一份架站合約，沒有替店家擋下賠償
這種責任問題，法院早就遇過。
臺灣新竹地方法院 112 年度簡上字第 143 號判決中，一名消費者使用訂房網站後遭冒名詐騙，損失 283,115 元，法院最後判店家賠償 84,935 元。
法院查到，業者花了 69,888 元請外部公司架設訂房網站，並使用外部虛擬主機。但完成架站後，後台訂房資料由業者自己管理。
案發時，後台未使用兩段式驗證，部分個資也未適當遮蔽。法院認為，使用外部主機並不能免除業者對自己保有資料的安全維護義務。
花錢請人建系統，與自己有沒有善盡管理義務，是兩件事。
第三方購物車，品牌究竟還管哪些東西？
| 資料環節 | 通常需要釐清的責任與證據 |
|---|---|
| 平台主機、程式與資料庫 | 平台提供什麼服務、事故調查能提出什麼資料 |
| 品牌後台帳號 | 誰可以登入、權限誰核准、離職後何時停權 |
| 會員資料匯出 | 哪些人可以匯出，資料進了哪個系統 |
| CRM、EDM、客服與物流串接 | 品牌是否另有會員副本，交付給誰、用於什麼目的 |
| 雙方契約與事故通知 | 服務範圍、委外監督、調查協作及通知分工 |
這張表不是要把責任全部推給品牌。恰好相反：只有先把各自掌握的系統與紀錄分清楚，才有可能避免不該由自己承擔的問題。
「系統沒異常」為什麼不一定能結案？
假設品牌向平台詢問，平台回覆特定時間內未發現資料庫異常存取。
這份說明可以成為事故調查的一部分，卻不一定能回答品牌自己是否曾從後台匯出會員資料、上傳另一套 CRM，或把名單提供行銷合作廠商。
同樣地，品牌若能提出完整的匯出紀錄，也不能直接證明平台端一定發生了什麼事。
證據的用途是縮小不確定性，不是找一個方便推責任的對象。
出事時，最昂貴的未必是修系統
除了可能的賠償，企業還會投入律師、客服、技術調查、主管協調與品牌溝通。更麻煩的是，最後往往仍要回頭把權限、資料流與委外紀錄重新整理。
法院已有個案判賠 84,935 元。加上法律及案件處理支出，一場爭議可能需要更多預算，而這還不是修補原本管理缺口的費用。
平台是平台，品牌是品牌。真正的問題，不是誰嘴上說自己有負責，而是事情發生時，雙方各自能拿出什麼證據。
延伸閱讀：個資外洩賠償與訴訟成本粗估；品牌端八項查核證據。