大家好，我是TIMEWELL的濱本隆太。
2026年10月15日，日本軟體公司Sourcenext公告，其管理會員資料的系統遭到未經授權存取，最多22,519,960筆資料可能外洩。姓名、地址、電話都在其中，連密碼也包含在內。經營會員制服務的公司，大概都會把它當成「自己也可能遇到」的事件。
這篇文章先把已公布的事實，與尚未釐清的部分分開。接著依據OWASP與日本個人情報保護委員會的資料，整理營運會員資料API的業者該檢視的項目，以及事發時的處理方式。這不是要找特定公司的過失，而是用該公司願意公布的事實為材料，思考自家該做哪些準備。
已公布的事實，與尚未釐清的部分
先整理能從Sourcenext官方公告與FAQ確認的範圍。12
| 項目 | 已公布的內容 |
|---|---|
| 未經授權存取的開始 | 2026年10月9日（週五）上午10點左右（事後調查查明） |
| 手法 | 不當利用會員資料擷取API，取得會員資料 |
| 確認 | 10月13日（週二）上午9點左右 |
| 封鎖 | 10月13日（週二）下午1點36分前完成 |
| 公告 | 10月15日（週四） |
| 向個人情報保護委員會通報 | 10月15日完成 |
| 警方 | 預定10月16日洽詢 |
| 資料筆數 | 22,519,960筆（「可能外洩」的筆數） |
| 對象範圍 | 截至10月13日下午1點36分，已完成註冊的客戶 |
| 項目 | 電子郵件、密碼、姓名、姓名假名、地址、性別、電話、傳真號碼、出生日期、公司名稱、職稱、部門，以及已加入的服務、註冊日、登入日等識別資訊（並非每個人的所有項目） |
| 信用卡資料 | 未保存在對象系統中，不在外洩範圍內 |
| 對使用者的處理 | 已讓全部密碼失效，請使用者重新設定；並請使用者一併更換在其他服務重複使用的密碼 |
從未經授權存取開始到確認，約隔了4天：10月9日上午10點左右開始，10月13日上午9點左右確認。
另一方面，公告與FAQ沒有寫出下列事項。
- API的哪裡、有什麼缺失。FAQ寫到「已修正造成此事的系統弱點」，但沒有具體內容。2
- 密碼是怎麼保存的（是否雜湊、用什麼方式）。
- 從開始到確認的約4天之間，發生了什麼事。
- 個別的產品與服務（例如Pocketalk）是否在範圍內。公告與FAQ都把對象寫成「有註冊會員的客戶」，沒有列出產品名稱。要確認自己是否受影響，最可靠的方法是看陸續寄出的個別通知郵件。
作為防止再發的對策，公司列出了全系統的緊急檢查、與外部專業機構的詳細調查、持續監控未經授權的存取，以及徹底檢討安全對策、監控體制與資訊管理體制。具體對策的內容與時程，並未寫出。1
因此，目前能說的是：回傳會員資料的API遭到不當利用，從開始到確認約隔了4天，可能有大量資料被取走。為什麼會發生，只能等後續公告。
會員資料API容易出現的缺失：以一般情形來看
從這裡開始，是一般性的背景說明，並不是對這起事件原因的推測。OWASP的API安全Top 10（2023年版），把API常見的缺失整理成10項。以下是與「回傳會員資料的API」相關的項目。3
- API1 物件層級授權失效： 處理使用者所指定ID的程序，授權確認不足，導致能碰到別人的資料
- API2 驗證失效： 驗證的實作有漏洞，權杖被盜，或被冒充成其他使用者
- API3 物件屬性層級授權失效： 回傳了不該回傳的欄位，或能改寫不該改寫的值
- API4 無限制的資源消耗： 擷取的次數與數量沒有上限，可以大量取出
- API5 功能層級授權失效： 管理功能與一般功能的界線模糊，能碰到本不該使用的功能
- API6 對重要業務流程的無限制存取： 沒有針對自動化過度使用的對策
- API9 清單管理不當： 舊版本或測試用的API沒有盤點，持續對外開放
想想回傳會員資料的API被不當使用的情境，這些項目都可能相關。不過，這次是哪一項，並未公布。
營運者該檢視的6個項目
營運會員資料API的業者，可以從下面6個地方著手。
1. 列出會回傳會員資料的API。
OWASP在API9所指的，就是缺少盤點。3 把回傳會員資料的API全部寫出來，包括對外公開的、內部使用的、舊版本的。然後逐一確認：這個API是誰在呼叫、為了什麼目的？沒有人呼叫的API，關掉最安全。
2. 在伺服器端確認，誰的資料可以給誰。
驗證（你是誰）與授權（你能做什麼）是兩回事。檢查在所有會回傳會員資料的路徑上，「只回傳登入者本人的資料」「管理功能只有管理者能呼叫」這些規則是否都有生效。OWASP的API1、API3、API5所指的，就是這類確認的疏漏。3 只在畫面上把按鈕藏起來，不算做了確認。
3. 只回傳必要的欄位，並減少保存的項目。
會員資料API真的需要同時回傳姓名、地址、電話、出生日期與密碼嗎？把回應限制在畫面所需的欄位，API被突破時的損害大小就會不同。像密碼這種根本不需要回傳的欄位，要在設計上就不放進回應。
保存的項目也一樣。不再使用的傳真號碼，或已退會會員的資料，要決定保存多久。這與我們在先前文章中談的、身分證明文件的保管想法相通。請參考從日本接連發生的入侵事件學到的事（上）。
4. 偵測並阻擋大量擷取。
這次公告中，最引人注目的數字是2,252萬筆的規模。正常使用時，一位會員不會擷取數百萬筆會員資料。OWASP在API4與API6所列的，就是擷取次數與數量沒有上限，以及缺少針對自動化大量使用的對策。3
對每個帳號、每個IP、每個權杖的擷取筆數設定上限。短時間內發生大量擷取時，自動阻擋並通知負責人。沒有先定義「正常使用的範圍」，就看不出異常。
5. 留下紀錄，並盯著看。
從未經授權存取開始到確認，約隔了4天。要縮短這個間隔，需要API存取紀錄，以及監看總量與目的地異常的機制。該看的是：回傳會員資料的API的呼叫次數、一次回傳的筆數，以及不尋常的時段或地點的存取。只留紀錄並不夠，要決定警示由誰接收、幾分鐘內採取行動。
6. 確認密碼的儲存方式。
這次的密碼儲存方式，官方公告與FAQ都沒有寫。以一般情形來說，OWASP的密碼儲存速查表禁止明文儲存，並把Argon2id列為首選演算法（最低參考值為記憶體19 MiB、反覆2次、平行度1）。對SHA-256或MD5這類高速雜湊，則表示不適合用來儲存密碼。4
請確認自家的密碼用的是哪一種方式。如果還是舊方式，可以在使用者登入時，逐步更新成新的方式。
事發時的處理方式
不論準備得多周全，風險都不會歸零。事先決定好怎麼行動，會左右災情擴大的程度。從這次的公告，可以學到3件事。
讓全部密碼失效的決定。 Sourcenext表示，已讓全體會員的密碼失效。1 另一方面，密碼重設的網站湧入大量流量，使用者被請求稍後再試。請所有人重設，是有效的做法。不過，數百萬人同時湧入時撐不撐得住，事前不測試就不會知道。事先測試重設流程的負載，是值得做的。
向個人情報保護委員會通報。 該委員會把需要通報外洩等事態，分成4類：含需特別留意的個人資訊、有財產損害之虞、有惡意目的之虞、超過1,000人。符合時，要在得知事態後盡速提出快報，一般以3至5日內為參考；並在30日內（疑有惡意目的時為60日內）提出確報。5 這次Sourcenext在10月13日確認，15日完成通報，也就是確認後2天，落在這個參考範圍內。
對使用者通知的寫法。 通知要包含4件事：發生了什麼事、哪些資料是對象、希望使用者做什麼、洽詢窗口在哪裡。除了請使用者重設密碼，Sourcenext也請使用者一併更換在其他服務重複使用的密碼。1 密碼可能外洩時，對本人其他服務的損害，是二次災害的主軸。請準備好把這句話放進自家的通知中。
該告訴使用者與員工的事
除了對自家會員的通知，也要把同樣的事告訴自家員工。
許多員工會用公司的電子郵件，註冊外部服務。如果那個服務發生外洩，而密碼又重複使用，就可能連鎖到公司內部系統。公司帳號的密碼不要在其他服務重複使用；使用密碼管理工具；開啟多因素驗證。把這3點寫成公司內部規則，其他公司發生外洩時，就能把影響降低。
另外，外洩公告之後，可能會收到冒充該公司的詐騙郵件。Sourcenext也呼籲，不要點開不認識的郵件或簡訊裡的連結。1 請再向員工宣導一次這條規則：官方公告，要從公司自己的網站確認。
總結
從Sourcenext的事件，能確認的是：回傳會員資料的API遭到不當利用，從開始到確認約隔了4天，最多約2,252萬筆資料可能被取走。原因的實質內容，尚未公布。
即使如此，擁有會員資料API的營運者該檢視的項目，已經很清楚：API的盤點、伺服器端的授權、縮減回傳欄位、大量擷取的偵測、紀錄的監看、密碼的儲存方式；以及事發時通報與通知的步驟。
我認為，差距最大的是偵測所需的時間。防禦無法做到完美，但從出事到察覺之間的時間，可以靠設計縮短。這個星期，先從列出回傳會員資料的API開始吧。如果想討論公司內部的檢查或教育訓練，歡迎透過WARP SECURITY的個別諮詢與我們聯絡。
