事件經過
背景： Base44 是一個讓使用者用自然語言就能生成應用程式的平台（後來被 Wix 收購）。許多企業利用它來建立內部專用工具，例如員工聊天助手、公司知識庫，甚至存放敏感的員工紀錄與個人資料。
發現漏洞： 資安研究團隊 Wiz Research 在檢查 Base44 對外開放的普通網頁（如說明文件、行銷網站）時，發現其中兩個頁面藏有可以直接送出系統請求的接口。這些接口允許任何人任意發送「替某個應用程式建立新帳號」以及「發送驗證碼到信箱」的指令。
測試駭入： 每個建在 Base44 上的應用程式都有一串識別碼，這串代碼大方地顯示在網址列和公開檔案中。Wiz 團隊找了一個不屬於他們、且隱私設定為最嚴格的「僅限受邀員工使用公司帳號登入」的私有應用程式。他們複製了該應用程式的識別碼，透過上述的漏洞接口成功替自己註冊了帳號、收取驗證碼完成驗證，最後竟然順利從正常的登入畫面，登進了這家公司的私有系統。
通報與修復： Wiz 證實這種手法能輕易攻破多個企業的私有應用程式（包含知識庫與人事系統），隨即在 7 月通報 Base44 和 Wix。Wix 在 24 小時內迅速完成了修補，徹底封鎖了這個不正常的註冊管道。
後續影響： Wix 隨後確認漏洞已解決，Base44 也發表聲明指出，經過調查，目前並未發現有任何客戶因駭客利用此漏洞而受害。Wiz 建議受影響的企業不需恐慌採取額外行動，但應該回頭檢查自家應用程式的系統紀錄，留意是否有異常的瀏覽與註冊活動。
主要來源——S1：https://www.wiz.io/blog/critical-vulnerability-base44存檔快照
損失成因
- 誤把「公開地址」當作「通行證」這串識別碼從來就不是機密，它大方地顯示在瀏覽器網址列裡。然而，系統的註冊與驗證機制卻把「知道識別碼」當成了加入該應用程式的唯一資格。在缺乏其他核對機制的情況下，光是抄下網址，就足以成為進入私有系統的鑰匙。技術名稱：可直接存取的物件參考（IDOR）（insecure direct object reference）
- 註冊大門不設防「建立帳號」和「驗證帳號」這兩個步驟，發生在真正的「登入」之前，因此完全不受應用程式隱私設定的管轄。有心人士只要送出夾帶信箱、密碼與識別碼的請求，就能憑空產生一個已驗證的帳號。接著，正常的登入流程就會把這個帳號誤認成「受邀員工」而直接放行。技術名稱：未經身分驗證的存取（unauthenticated access）
- 共用平台的系統盲點受影響的企業即使選擇了最嚴格的「僅限受邀員工」設定，這個設定也只能在「登入」那一關發揮作用。由於註冊和驗證功能是整個平台統一制定的底層規則，個別客戶無法自行修改。只要平台底層的規則有漏洞，平台上所有企業的私有應用程式就會跟著門戶洞開。技術名稱：生產與開發共用基礎設施（shared prod-dev infrastructure）
預防方式
應用程式的識別碼是地址，不是門鎖
這串代表你應用程式的字元既然寫在網址裡，就必須將其視為公開資訊。請向你的平台供應商確認：系統絕不能允許訪客僅憑一串識別碼，就在你的應用程式裡建立帳號。同時，確認身分驗證機制有徹底涵蓋註冊、信箱驗證、邀請與密碼重設等所有路徑。
盤點所有建立新帳號的途徑
你必須在應用程式平台上釐清兩件事：你的系統究竟有哪幾條路徑可以產生新使用者？每一條路徑又設立了哪些檢查關卡？你必須有能力隨時確認，私有應用程式裡新建的每一個帳號，都確實是你的員工。
供應商的資安水準，就是你的資安水準
在共用平台上，整個管理規則都是由平台商設計與制定的。在確認上述安全機制完備之前，請不要將員工紀錄、客戶個資等機密敏感文件放上共用平台。同時，你應要求供應商承諾，一旦發現並修復底層漏洞時，必須直接且迅速地通知你。
核心觀念： 你自己的隱私設定得再嚴，也只擋得住「登入」這一關；它防不了共用平台從底層大開的後門。