2026.10.04 セキュリティ

セイコーマートの不正アクセスと57万人の会員情報｜アプリAPIの認可を点検する手順

セイコーマートは2026年9月29日、スマートフォン向けの「セイコーマートアプリ」のサーバーを経由して、会員情報を持つサーバーに第三者が不正にアクセスしたと公表しました。翌30日の第三報では、閲覧が確認された会員を572,022人と確定しています。発覚のきっかけは、ある会員のクラブカードが本人の知らないうちに退会処理されていたことでした。本記事では、公式発表の第一報から第三報までを時系列で整理します。そのうえで、会員アプリのAPIを運営する側が自社で同じことが起きないかを確かめる手順を、手元で動くPythonスクリプトとSQLで示します。

まとめ：セイコーマートの不正アクセスで公表された事実とアプリ運営側の点検

確定しているのは次の事実です。2026年9月24日の22時から23時の間に、1件のアカウントで不正なクラブカードの退会処理が行われました。9月28日の17時過ぎに会員サーバーへの不正アクセスの可能性が判明し、同日20時に接続を停止しています。閲覧されたのはアプリに登録したことのある会員572,022人分で、アプリ会員の49%にあたります。パスワードと購買履歴は漏えいしておらず、クレジットカード情報は同社が保有していません。

不正アクセスの手法は、警察と関係機関との連携を理由に開示されていません。したがって原因は断定できません。それでも、アプリのサーバーを経由して会員サーバーまで届き、他人のアカウントで退会という書き込みまで通った、という公表事実は残ります。会員アプリを運営する側は、他人の会員IDを渡したときにAPIが応答してしまわないか、1つの認証情報が短時間に何人分の会員情報へ触れたかを数えられるか、の2点をまず確かめてください。

項目	公表されている内容
不正な退会処理	2026年9月24日 22時〜23時に1件
不正アクセスの可能性判明	2026年9月28日 17時過ぎ
会員サーバーへの接続停止	2026年9月28日 20時
閲覧を確認した人数	572,022人（アプリ会員の49%）
漏えいしていない情報	パスワード、購買履歴
行政当局への報告	第三報（9月30日）時点で報告済み
手法	非開示

公式発表を時系列で確認する｜9月24日の不正退会から9月30日の第三報まで

9月24日の不正なクラブカード退会1件から会員サーバー停止までの約4日間

セイコーマートの第一報（2026年9月29日）によると、9月24日（木）の22時から23時の間に、不正にクラブカードの退会処理が行われたアカウントが1件見つかりました。これを手がかりに調べた結果、会員サーバーに不正にアクセスされた可能性があると9月28日（月）17時過ぎに判明します。同社は同日20時に当該サーバーへの接続を止めました。

不正な退会から不正アクセスの判明までは約4日、判明から接続停止までは約3時間です。第一報は、他のアカウントで不正な退会などは確認されていないとしています。接続を止めた影響で、新規入会、会員情報の変更、登録カードの変更、退会、マイページへのログインが使えなくなりました。

第三報で確定した572,022人とアプリ会員の49%という影響範囲

第一報の時点では、不正アクセスを受けた可能性のあるユーザーIDは約57万アカウントという表現でした。9月30日の第三報はこれを一歩進め、アプリに登録したことがある会員のうち572,022人分の情報が閲覧されたことを確認したと書いています。アプリ会員の49%です。

49%という割合から逆算すると、アプリ会員は約117万人規模になります。半数近くの会員情報が読まれたことになり、1件ずつ狙ったというより、まとまった量を順に取得された可能性を考えるべき数字です。第三報は、個人情報保護法に基づいて行政当局へ報告したことも明記しました。民間事業者の報告の段取りは個人情報保護委員会への報告義務で整理しています。

漏えいした8項目と含まれない情報・公式通販だけの利用者が対象外の理由

閲覧された可能性がある項目は、姓名、性別、生年月日、住所、電話番号、メールアドレス、クラブカードへの入会年月日、退会年月日の8つです。パスワードは漏えいしておらず、クレジットカード情報はもともと保有していません。

同日の第二報では、購買履歴も漏えいしていないこと、公式通販に登録していても会員証（カードとアプリ）を持たない人は対象外であることが追加されました。第三報は、アプリに登録していない会員も対象外としています。対象は、会員サーバーのうちアプリから到達できた範囲に限られていると読めます。

会員とアプリ利用者が今やること｜セコマを騙るメールとペコママネーの確認

同社は、セイコーマートを騙るメールへの注意を呼びかけています。メールでパスワード、ペコマカードのPIN、クレジットカード情報、預金情報を尋ねることはないと明言しました。氏名、生年月日、住所、電話番号、メールアドレスがそろって読まれているため、本人確認を装った電話やメールは本物らしく見えます。

9月30日時点で、ペコママネーの利用とチャージ、ポイント付与、会員価格での購入、クーポンは店頭で使えます。アプリとWebでの新規入会と会員情報変更は止まっており、店頭で受け付けています。ペコママネーの不正利用は確認されていません。利用者は残高と利用履歴を店頭やレシートで確かめ、同じメールアドレスとパスワードを他のサービスで使い回している場合はそちらを変えておくと安心です。問い合わせ先はお客様相談室（0120-89-8551、月〜土の9時〜17時）です。

アプリサーバー経由で会員サーバーに届いた構図｜公表事実から読める論点

手法は非開示・公表から確定できる事実と推測で埋めてはいけない部分

第三報は、外部調査会社と経緯や影響範囲を調べており、警察や関係機関と連携しているため詳細の開示を控えるとしています。脆弱性の種類、侵入に使われた認証情報、取得の方法はいずれも公表されていません。

公表から確定できるのは三つに限られます。経路がアプリのサーバーを経由していたこと、他人のアカウントで退会という書き込みが通ったこと、アプリ会員の約半数分が閲覧されたことです。本記事はここから先の原因を推測しません。以降で扱うのは、同じ三つの事実が自社のアプリで起こりうるかを確かめる手順です。

他人のアカウントで退会処理が通ったことが示す書き込み系APIの論点

今回の発見は、閲覧ではなく退会という変更操作がきっかけでした。会員本人が知らない退会が記録されていたから気付けたわけです。裏返すと、読み取りだけで済んでいれば発見はさらに遅れた可能性があります。

会員アプリのAPIは、参照、変更、退会、カード登録といった操作を会員IDやカード番号と組み合わせて受け付ける仕組みです。どの操作でも、リクエストを送った本人が対象の会員と一致するかをサーバー側で確かめていなければ、他人のIDを入れるだけで操作が通ります。類似の事案として、アプリの認可実装を扱ったタカラトミーのデュエマアプリ個人情報漏えいの解説も参考になります。

退会年月日まで閲覧対象になった保管設計と退会者データの保管方法

閲覧された項目に退会年月日が入っている点は、見落とせません。退会した会員の氏名や住所が、退会日と一緒に会員サーバーに残っていたことを示すからです。退会者の情報が、現役会員と同じ経路から読める場所にありました。

退会者の情報をいつまで、どこに、どの形で残すかは設計で決められる事項です。ポイントの精算や問い合わせ対応に必要な期間が過ぎたら削除するか、氏名と連絡先を外して別の保管先へ移せば、アプリの経路から読める件数はその分減ります。退会者の画像データまで残していた事例はタイムズカーの不正アクセスと免許証画像160万件の流出で扱っています。

OWASP API Top 10で点検する｜他人のIDを渡して通るかを試す手順

API1:2023オブジェクト単位の認可不備とトークンから会員IDを決める実装

APIの認可不備のうち最も多い型は、OWASP API Security Top 10 2023のAPI1（Broken Object Level Authorization）として整理されています。リクエストに含まれるオブジェクトのIDを書き換えると、他人のデータを読んだり変えたりできてしまう不備です。OWASPは悪用の容易さをEasy、広がりをWidespreadと評価しています。

対策の基本は、操作の対象を「リクエストで渡されたID」ではなく「認証で確かめた本人」から決めることです。会員が自分の情報だけを扱うAPIなら、パスに会員IDを入れず、アクセストークンから会員IDを引けば足ります。管理者のように他人の情報を扱う必要がある場合だけ、IDを受け取ったうえでデータベースを引くたびに権限の照合が必要です。OWASPはあわせて、レコードのIDを推測しにくいランダムな値にすることも挙げています。10項目の全体はOWASP API Security Top 10 2023の全10項目で解説しています。

標準ライブラリで動く認可チェックスクリプトと検証用APIでの実行結果

自社のAPIで、会員Aのトークンを使って会員Bの情報を参照、変更、退会できてしまわないかを確かめるスクリプトです。Python 3の標準ライブラリだけで動きます。パスは自社のAPIに合わせて書き換えてください。他人として使う会員Bは、必ず検証用に作ったテストアカウントにします。bola_check.pyとして保存します。

import sys, urllib.request, urllib.error

BASE, TOKEN, OWN_ID, OTHER_ID = sys.argv[1:5]

def call(method, path):
    req = urllib.request.Request(BASE + path, method=method,
                                 headers={"Authorization": "Bearer " + TOKEN})
    try:
        with urllib.request.urlopen(req, timeout=10) as r:
            return r.status
    except urllib.error.HTTPError as e:
        return e.code

checks = [
    ("GET",    "/members/{id}",            "会員情報の参照"),
    ("PATCH",  "/members/{id}",            "会員情報の変更"),
    ("DELETE", "/members/{id}/club-card",  "クラブカードの退会"),
]

ng = 0
for method, tpl, label in checks:
    own = call("GET", tpl.format(id=OWN_ID))
    other = call(method, tpl.format(id=OTHER_ID))
    ok = other in (403, 404)
    ng += not ok
    print(f"{'OK' if ok else 'NG'} {method:6} {label}: 自分GET={own} 他人={other}")
sys.exit(1 if ng else 0)

2026年10月4日に、手元で立てた検証用のモックAPIに対して実行した結果です。8765番は他人のIDでも応答する不備ありの版、8766番はトークンの本人と一致しないIDに404を返す修正版です。

$ python bola_check.py http://127.0.0.1:8765 tokenA 1001 1002
NG GET    会員情報の参照: 自分GET=200 他人=200
NG PATCH  会員情報の変更: 自分GET=200 他人=200
NG DELETE クラブカードの退会: 自分GET=200 他人=200

$ python bola_check.py http://127.0.0.1:8766 tokenA 1001 1002
OK GET    会員情報の参照: 自分GET=200 他人=404
OK PATCH  会員情報の変更: 自分GET=200 他人=404
OK DELETE クラブカードの退会: 自分GET=200 他人=404

NGが1つでもあれば終了コード1を返すため、CIに組み込んでデプロイのたびに回せます。他人のIDに403と404のどちらを返すかは設計次第ですが、存在の有無を知られたくない会員データなら404に寄せる方が安全です。サーバー側の実装例は認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策にまとめています。

退会や会員情報変更を重要な業務フローとして扱うAPI6:2023の考え方

認可が正しくても、退会やカード変更のような取り消しにくい操作には、もう一段の守りを置けます。OWASPのAPI6:2023は、過度に使われると事業に害が出る業務フローを特定し、自動化された利用を遅らせる仕組みを入れるよう求めています。例として挙げられているのは、人間とは思えない速さの操作の検知や、想定外のクライアントからの拒否です。

会員アプリに当てはめると、実務ではまず退会とメールアドレス変更の2つに絞れば十分です。この2つは、パスワードの再入力か登録済みメールへの確認コードを求め、完了後に登録済みの連絡先へ通知を送ります。通知は、身に覚えのない会員がその場で不正な操作に気付くきっかけです。今回の不正な退会1件が発見の起点になったことを考えると、変更操作の通知は検知の仕組みとしても働きます。

大量閲覧に気付くためのログ設計｜1トークンが触れた会員数を数える検知SQL

1時間に何人分の会員IDへ触れたかを数えるSQLとサンプルログでの出力

認可の不備を突く取得は、1つのトークンが多数の会員IDへ順にアクセスする形になりやすいものです。正規の会員は自分の情報しか見ないため、1つのトークンが1時間に触れた会員IDの数を数えるだけで目立ちます。APIのアクセスログを、トークンの持ち主、対象の会員ID、メソッドに分けて記録しておけば、次のSQLで拾えます（SQLiteの構文です）。

SELECT token_owner,
       strftime('%Y-%m-%d %H:00', ts) AS hour,
       COUNT(DISTINCT member_id) AS members_touched,
       SUM(method <> 'GET' AND member_id <> token_owner) AS writes_to_others
FROM api_access
GROUP BY token_owner, hour
HAVING members_touched > 3 OR writes_to_others > 0
ORDER BY members_touched DESC;

会員1001が自分の情報を1回、他人の情報を300件参照し、他人のカードを1件退会させたという架空のサンプルログで、2026年10月4日に実行しました。自分の情報を1回見ただけの会員3003は出力されません。

1001 | 2026-10-01 10:00 | 302 | 1

触れた会員数が302人、他人への書き込みが1件と、1行で異常が分かります。writes_to_othersの列は、今回の事案で発見の起点になった「他人のアカウントへの変更操作」を直接数えるためのものです。見るべきログの種類と攻撃痕跡の調べ方は不正アクセスのログ確認・解析方法が参考になります。

しきい値の決め方と遮断までの手順・API4:2023のリソース消費制限

しきい値は、正規の利用で起こる最大値から決めます。家族会員を1つのアカウントでまとめて扱う仕様なら、その上限の人数が目安です。運用は次の順で組みます。

通常の1週間分のログで、トークンごとの1時間あたりの会員ID数の最大値を測る
その数を超えたトークンを通知の対象にし、他人への書き込みは1件でも通知する
通知を受けたトークンは失効させ、同じ接続元からの新しいトークンの発行を一時止める
止めたトークンが触れた会員IDの一覧を残し、影響範囲の確定に使う

検知と別に、APIゲートウェイで1トークンあたりのリクエスト数に上限を置いておきます。OWASPのAPI4:2023は、リクエスト数や返す件数の制限が無いAPIを独立した危険として挙げています。上限があれば、認可の不備が残っていても取得できる件数は時間に応じて制限される仕組みです。57万人分を取るのに要する時間が延びれば、それだけ検知と遮断が間に合う余地が生まれます。

会員アプリのAPIを今すぐ点検すべき事業者と後回しでよい事業者の判断基準

会員IDやカード番号をAPIに渡して会員情報を返すアプリの事業者の対応

自社のアプリやWebサービスが、会員IDやカード番号をパスやパラメータに入れて会員情報を返す作りなら、bola_check.pyに相当する点検を今週中に回してください。参照だけでなく、変更と退会のエンドポイントも含めます。今回の事案で発見の起点になったのは書き込みでした。

ポイントカードとアプリを後からつないだ会員基盤は、とくに優先度が高いと考えます。カード番号で会員を引く古いAPIが、アプリ用の認証と別の経路で残っていることがあるためです。点検では、アプリが呼ぶAPIの一覧をまず作り、どの経路で会員サーバーまで届くかを図にしてから一つずつ試します。

外部の会員基盤やSaaSに任せている小規模アプリで過剰になる場面

会員情報を自社のサーバーに持たず、認証と会員管理を外部の会員基盤やSaaSに任せている小規模なアプリでは、自前で検知SQLを組む運用は過剰です。その場合は、サービス側の権限設定で、利用者が自分以外のレコードを読めない設定になっているかを確かめれば足ります。

判断に迷うのは、どのAPIが会員サーバーまで届いているかを社内で把握できていない場合です。アプリのAPIから会員データまでの経路と認可の実装を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、他人のIDによる参照や変更が通らないかを含めて点検できます。

よくある質問

セイコーマートの不正アクセスについて、会員とアプリを運営する担当者から出やすい質問をまとめました。

セイコーマートクラブの会員は全員が対象ですか？

全員ではありません。第三報によると、対象はセイコーマートアプリに登録したことがある会員のうち572,022人で、アプリ会員の49%です。アプリに登録していない会員は対象外とされています。公式通販に登録していても、会員証（カードとアプリ）を持たない人も対象外です。自分が対象かどうかは、お客様相談室（0120-89-8551）で確認できます。

パスワードやクレジットカード情報は漏れていますか？

同社は、パスワード情報は漏えいしていないと説明しています。クレジットカード情報はもともと保有していません。購買履歴も漏えいしていないと第二報で追加されました。閲覧された可能性があるのは、姓名、性別、生年月日、住所、電話番号、メールアドレス、クラブカードの入会年月日と退会年月日の8項目です。

不正アクセスの原因や手法は公表されていますか？

公表されていません。第三報は、外部調査会社と調査を進めており、警察や関係機関と連携しているため詳細の開示を控えるとしています。アプリのサーバーを経由して会員サーバーに届いたこと、他人のアカウントで退会処理が行われたことまでは公表されていますが、どの脆弱性が使われたかは分かっていません。

ペコママネーやポイントは今も使えますか？

9月30日時点で、ペコママネーの利用とチャージ、ポイント付与、会員価格での購入、クーポンは使えます。止まっているのは、アプリとWebでの新規入会、会員情報の変更、退会、公式通販などです。新規入会と会員情報の変更は店頭で受け付けています。9月末で失効するポイントは1か月延長されると第二報で案内されました。

自社の会員アプリで同じことが起きないか、何から確かめればよいですか？

最初に、アプリが呼んでいるAPIの一覧を作ります。次に、テスト用の会員Aのトークンで会員Bの参照、変更、退会を試し、すべて403か404で拒否されるかを確かめてください。最後に、1つのトークンが1時間に何人分の会員IDへ触れたかをログから数えられる状態にします。本記事のスクリプトとSQLはその出発点として使えます。