ソースネクスト2,252万件の漏えいから学ぶ、会員情報APIの守り方

こんにちは、株式会社TIMEWELLの濱本です。

2026年10月15日、ソースネクストが、会員情報を管理するシステムへの不正アクセスで、最大22,519,960件の情報が流出した可能性があると公表しました。氏名や住所、電話番号に加えて、パスワードも対象に含まれます。会員向けのサービスを持つ会社なら、どこでも起こりうる事案として受け止めた方が多いのではないでしょうか。

この記事では、公表された事実と、まだ分かっていないことを分けます。そのうえで、会員情報を扱うAPIを持つ運営者が見直すべき項目と、起きてしまったときの動き方を、OWASPと個人情報保護委員会の資料に沿って書きます。特定の会社の落ち度を探す記事ではありません。公表してくださった事実を材料に、自社で何を備えるかを考えるための記事です。

公表されている事実と、まだ分かっていないこと

ソースネクストの公式のお知らせとFAQから、確認できる範囲をまとめます。¹²

項目	公表されている内容
不正アクセスの開始	2026年10月9日(金)10時ごろ(その後の調査で判明)
手口	会員情報取得APIを不正に利用し、会員情報を取得
確認	10月13日(火)9時ごろ
封じ込め	10月13日(火)13時36分までに完了
公表	10月15日(木)
個人情報保護委員会への報告	10月15日に完了
警察への相談	10月16日に予定
対象件数	22,519,960件(流出した「可能性のある」件数)
対象範囲	10月13日13時36分までに登録のある顧客
項目	メールアドレス、パスワード、氏名、氏名カナ、住所、性別、電話番号、FAX番号、生年月日、会社名、役職名、部署名、加入サービスや登録日・ログイン日などの識別情報(全員が全項目ではない)
クレジットカード情報	対象システムに保存しておらず、流出の対象に含まれない
利用者への対応	全員のパスワードを無効化。再設定を案内。同じパスワードを使い回している他のサービスの変更も依頼

不正アクセスの開始から確認まで、およそ4日です。10月9日10時ごろに始まり、13日9時ごろに確認されています。

一方で、公式の告知とFAQには、次のことが書かれていません。

• APIのどこに、どんな不備があったのか。FAQには「原因となったシステムの脆弱性を修正した」とありますが、具体的な中身は書かれていません。²
• パスワードをどう保存していたのか(ハッシュ化の有無や方式)。
• 開始から確認までの約4日間に、何が起きていたのか。
• ポケトークなど、個別の製品やサービスが対象かどうか。公式の告知もFAQも、対象を「会員登録のある顧客」とし、製品名を挙げていません。自分が対象かどうかは、届く個別の案内メールで確かめるのが確実です。

再発防止策として、全システムの緊急点検、外部専門機関による詳細な調査、不正アクセスの監視の継続、セキュリティ対策や監視体制、情報管理体制の抜本的な見直しが挙げられています。具体的な施策の中身と時期は、書かれていません。¹

つまり、現時点で言えるのは「会員情報を返すAPIが不正に使われ、開始から確認までに約4日あり、大量の情報が取得された可能性がある」というところまでです。なぜそうなったのかは、公表を待つしかありません。

会員情報APIで起きやすい不備。一般論として

ここから先は、この事案の原因の推測ではなく、一般論です。OWASPのAPIセキュリティTop 10(2023年版)が、APIの代表的な不備を10項目に整理しています。会員情報を返すAPIに関わる項目を挙げます。³

• API1 オブジェクト単位の認可の不備: ユーザーが指定したIDを受け取る処理で、認可の確認が足りず、他人のデータに届いてしまう
• API2 認証の不備: 認証の実装に穴があり、トークンを奪われたり、他の利用者になりすまされたりする
• API3 オブジェクトの属性単位の認可の不備: 返してはいけない項目まで返してしまう、書き換えてはいけない値を書き換えられる
• API4 無制限の資源消費: 取得の回数や量に上限がなく、大量に引き出せる
• API5 機能単位の認可の不備: 管理用の機能と一般向けの機能の区別があいまいで、本来使えない機能に届く
• API6 重要な業務フローへの無制限のアクセス: 自動化された過剰な利用への対策がない
• API9 在庫管理の不備: 古いバージョンや試験用のAPIが、棚卸しされないまま公開されている

会員情報を返すAPIが不正に使われる場面を考えると、どれも関係しうる項目です。ただし、今回どれに当たるのかは、公表されていません。

運営者が見直す6つの項目

自社の会員情報APIを持つ運営者が、見直せる項目を6つに分けます。

1. 会員情報を返すAPIの一覧を作る。

OWASPがAPI9として挙げているのは、APIの棚卸しの不足です。³ 会員情報を返すAPIを、公開しているもの、社内向けのもの、古いバージョンも含めて書き出します。そのうえで、「このAPIは、誰が、何のために呼ぶのか」を一つずつ確かめます。呼び手のいないAPIは、閉じるのがいちばん安全です。

2. 誰の情報を、誰に返してよいかを、サーバー側で確かめる。

認証(誰であるか)と認可(何をしてよいか)は別のものです。会員情報を返す処理で、「ログインしている本人の情報だけを返す」「管理者の機能は管理者だけが呼べる」という確認が、すべての経路で働いているかを点検します。OWASPのAPI1、API3、API5が指しているのは、この確認の抜けです。³ 画面上でボタンを隠すだけでは、確認したことになりません。

3. 返す項目を、必要なものだけに絞る。保存する項目も減らす。

会員情報取得APIが、氏名、住所、電話番号、生年月日、パスワードのすべてを返す必要が、本当にあるでしょうか。画面に出すのに必要な項目だけに絞れば、APIが突破されたときの被害の大きさが変わります。パスワードのように、返す必要がそもそもない項目は、APIの応答に含めない設計にします。

保存する項目についても同じです。使っていないFAX番号や、利用が終わった会員の情報を、いつまで持つかを決めておきます。前編の記事で書いた、本人確認書類の持ち方の考え方と重なります。相次ぐ不正アクセスから学ぶ【前編】も参考にしてください。

4. 大量の取得を、検知して止める。

今回の公表で、数字として目を引くのは、2,252万件という規模です。通常の利用では、一人の会員が、数百万件の会員情報を取得することはありません。OWASPがAPI4とAPI6で挙げているのは、取得の回数や量に上限がないことと、自動化された大量の利用への対策がないことです。³

一つのアカウント、一つのIP、一つのトークンあたりの取得件数に上限を設けます。短時間に大量の取得が起きたら、自動で止めて、担当者に通知します。「正常な利用の範囲」を決めておかないと、異常は見つかりません。

5. ログを残して、見張る。

不正アクセスの開始から確認まで、およそ4日でした。この間隔を縮めるには、APIのアクセスログを残し、総量や宛先の異常を見張る仕組みが要ります。見るべきなのは、会員情報を返すAPIの呼び出し回数、一度に返した件数、普段と違う時間帯や場所からのアクセスです。ログを取るだけでは足りず、アラートを誰が受けて、何分以内に動くかまで決めておきます。

6. パスワードの保存方式を確かめる。

今回、パスワードの保存方式は、公式の告知にもFAQにも書かれていません。一般論として、OWASPのパスワード保存のチートシートは、平文での保存を禁じ、第一選択のアルゴリズムとしてArgon2idを挙げています(最小の目安は、メモリ19MiB、反復2回、並列度1)。SHA-256やMD5のような高速なハッシュは、パスワードの保存に向かないとしています。⁴

自社のパスワードがどの方式で保存されているかを、確認してください。古い方式のままなら、ログインのタイミングで新しい方式に更新していく方法があります。

起きてしまったときの動き方

どんなに備えても、ゼロにはなりません。起きたときの動きを、事前に決めておくことが、被害の広がりを左右します。今回の公表から学べることを、3つ書きます。

全員のパスワードを無効化する判断。 ソースネクストは、すべての会員のパスワードをすでに無効化したと案内しています。¹ 一方で、パスワード再設定のサイトにはアクセスが集中し、時間をおいて再設定するよう案内されています。全員に再設定を求める対応は、有効です。ただ、数百万人が一斉に再設定に来たときに耐えられるかは、事前に確かめておかないと分かりません。再設定の仕組みへの負荷を、あらかじめ試しておく価値があります。

個人情報保護委員会への報告。 個人情報保護委員会は、漏えい等の報告が必要な事態を、要配慮個人情報が含まれる、財産的被害のおそれがある、不正の目的によるおそれがある、1,000人を超える、の4類型としています。該当するときは、事態を知った後、速やかに、概ね3〜5日以内を目安に速報を出し、30日以内(不正の目的によるおそれがある場合は60日以内)に確報を出します。⁵ 今回のソースネクストは、10月13日に確認し、15日に報告を済ませています。確認から2日で、速報の目安の範囲に収まっています。

利用者への案内の文面。 案内に入れる中身は、何が起きたか、どの情報が対象か、利用者に何をしてほしいか、問い合わせ先はどこか、の4点です。ソースネクストは、パスワードの再設定に加えて、「同じパスワードを使っている他のサービスも変更してほしい」と求めています。¹ パスワードが流出した可能性があるとき、本人の他のサービスへの被害が、二次被害の中心になります。この一文を、案内に入れる準備をしておきます。

利用者と社員に伝えておくこと

自社の会員向けの案内とは別に、社員にも、同じことを伝えておきます。

会社のメールアドレスで、外部のサービスに登録している社員は多いはずです。そのサービスで漏えいが起きると、パスワードの使い回しをしていれば、社内のシステムにも連鎖します。会社のアカウントのパスワードは、他のサービスと使い回さないこと。パスワードマネージャーを使うこと。多要素認証を有効にすること。この3つを、社内のルールとして書いておくと、他社の漏えいが起きたときの影響を小さくできます。

また、漏えいの公表のあとには、公表した会社を装った詐欺メールが届くことがあります。ソースネクストも、身に覚えのないメールやSMSのリンクを開かないよう呼びかけています。¹ 社員向けに、「公式のお知らせは、会社のサイトから確認する」というルールを、あらためて周知します。

まとめ

ソースネクストの事案で確認できるのは、会員情報取得APIが不正に使われ、開始から確認までに約4日あり、最大約2,252万件の情報が取得された可能性がある、というところまでです。原因の中身は、まだ公表されていません。

それでも、会員情報を返すAPIを持つ運営者にとって、見直すべき項目ははっきりしています。APIの棚卸し、サーバー側での認可、返す項目の絞り込み、大量取得の検知、ログの監視、パスワードの保存方式。そして、起きたときの報告と案内の段取りです。

私は、いちばん差が出るのは、検知までの時間だと考えています。守りを完璧にすることはできませんが、異常に気づくまでの時間は、設計で縮められます。まず今週、会員情報を返すAPIの一覧を作るところから始めてみてください。社内の点検や教育の設計について相談したい方は、WARP SECURITYの個別相談からお声がけください。

参考

Footnotes

1. 当社サイトへの不正アクセスによるお客様情報流出のお詫びとお知らせ — ソースネクスト — 2026年10月15日 ↩ ↩² ↩³ ↩⁴ ↩⁵

2. 情報漏洩に関するよくあるご質問 — ソースネクスト — 2026年10月15日 ↩ ↩²

3. OWASP API Security Top 10 2023 — OWASP ↩ ↩² ↩³ ↩⁴

4. Password Storage Cheat Sheet — OWASP Cheat Sheet Series ↩

5. 漏えい等の対応とお役立ち資料 — 個人情報保護委員会 ↩