デニーズアプリの不正アクセス：旧アプリ移行処理で作られた認証情報と移行APIの点検

株式会社デニーズジャパンは2026年11月3日、旧デニーズアプリから新アプリへの移行に関するシステム処理で、第三者が認証情報を不正に作成し、一部のお客様のアカウントにアクセスできる状態になっていたと公表しました。漏えいした可能性があるのは会員コード・メールアドレス・生年月日など7項目で、対象人数は調査中です。前半では利用者が気にする対象・再ログイン・不審メールを第一報の文言で整理し、後半では会員移行の処理で認証情報を不正に作らせない設計と、本人の操作と第三者の操作を後から見分けるログの実装を示します。

まとめ：デニーズアプリの不正アクセスで判明した事実と利用者・開発者が先にやること

デニーズジャパンの第一報で確定しているのは、旧アプリに関する認証情報が不正に作られていたこと、10月30日に新規作成を防ぐ改修を入れたこと、10月31日と11月2日に不正な認証情報を無効化したことです。個人情報を取得するシステム処理が実行された履歴はあるものの、第三者の操作か本人の操作かを区別できておらず、取得の有無・内容・人数はまだ分かっていません。

漏えいの可能性がある情報と、同社がそもそも持っていない情報を分けると次のとおりです。

利用者が先にやることは2つです。アプリが初期画面に戻ったら、公式アプリから再ログインする。デニーズや関係機関を名乗るメールのURLを開かず、個人情報を入力しない。開発者は、自社の会員移行やアカウント引き継ぎの窓口が、他人でも知り得る値だけで新しい認証情報を発行していないかを点検します。

デニーズアプリの利用者向け：漏えいの可能性がある7項目と再ログイン・不審メールへの備え

旧アプリを使っていた会員の一部が対象で、会員コードやキッズバースデーが候補

対象となる可能性があるのは「旧デニーズアプリをご利用されていたお客様の一部」です。新アプリから入会した人は、第一報の書き方では対象に含まれていません。人数は確定しておらず、同社は対象者を特定でき次第、個別に連絡するとしています。

7項目のうち実害につながりやすいのは、メールアドレスと生年月日の組み合わせです。キッズバースデーは子どもの誕生日を登録して特典を受ける機能なので、家族構成の手がかりにもなります。氏名や電話番号が無いぶん、なりすましの電話より、メールでのフィッシングに使われる形を警戒します。

アプリ起動時に初期画面が出て再ログインを求められる理由と、偽メールの見分け方

第一報によると、今回の対策に伴い、一部の利用者はアプリを起動した際に初期画面が表示され、再度ログインが必要になる場合があります。不正な認証情報を無効化した影響と読めます。アプリストアから入れた公式アプリの中でログインし直すぶんには問題ありません。

注意が要るのは、同じ時期に届く「アカウントの確認」「ポイント失効」をうたうメールです。同社は、当社や関係機関を装った不審なメールが送られる可能性を否定できないとして、身に覚えのないメールのURLへのアクセスと、個人情報の入力をしないよう求めています。メール内のリンクではなく、端末のアプリから直接開くのが確実です。

問い合わせフォームと個別連絡の流れ、人数が確定していない段階での待ち方

利用者からの問い合わせはデニーズアプリカスタマーセンターのお問い合わせフォームで受け付けています。現在確認できているのは2026年10月7日のアクセス記録の調査結果で、そのほかの期間は調査中です。対象かどうかを今すぐ判定する手段は公表されていないため、個別の連絡と続報を待つ形になります。

同社は10月31日に個人情報保護委員会へ速報を出しました。個人情報保護法ガイドライン（通則編）では、不正アクセスによる漏えいは「おそれ」の段階から件数にかかわらず報告対象で、確報は知った日から60日以内です。本人への通知も同じく義務になります。流れは個人情報保護委員会への報告義務の実務にまとめました。

第一報で判明した経緯：7月の会員移行開始から11月2日の追加無効化までの時系列

7月16日のリニューアルで始まった会員移行と、10月30日に判明した不正な認証情報

デニーズアプリは2026年7月16日にリニューアルされました。同社のリニューアル告知は、既存会員は新しいアプリにログインし、案内に従ってメールアドレスを登録すれば移行できると案内しています。移行時の本人確認の手順は、告知にも第一報にも書かれていません。

入口は旧アプリそのものではなく、旧アプリから新アプリへ会員を移す処理でした。リニューアルから判明まで約3か月半あり、10月7日以外の期間がどこまで遡るかが続報の焦点になります。

本人の操作と第三者の操作を区別できず、取得の有無と人数が調査中のままの理由

第一報で目を引くのは、個人情報を取得するシステム処理の実行履歴は残っていたのに、それが第三者によるものか本人によるものかを区別できていない、という一文です。移行処理は本来、本人が自分の情報を新アプリへ引き継ぐためのものです。正規の移行と不正な作成が同じ処理・同じ記録で残っていれば、見分けるには別の手がかりが要ります。

人数が確定しないのはこのためです。同社は専門部署とシステム開発会社と連携して原因を調べるとしており、どのような不備があったかは公表されていません。以下の章は本件の手口の再現ではなく、会員移行を設計する側が同じ種類の抜けを作らないための一般的な設計です。

会員移行APIで認証情報を不正に作らせない設計：照合項目と1回限りの移行コード

会員コードや生年月日など、他人が知り得る値だけで認証情報を発行する設計の危うさ

アプリの載せ替えでは、旧アプリの会員を新しい認証基盤へ移すための専用の窓口を一時的に作ることが多くあります。この窓口は「まだ新しい認証情報を持っていない人」に認証情報を発行する機能なので、実質的にはパスワード再設定と同じ重さの機能です。会員証のバーコードに載る会員コードや、生年月日のように他人でも知り得る値だけで発行すると、それを知った第三者が本人の代わりに認証情報を作れてしまいます。

OWASP API Security Top 10 2023のAPI2（認証の不備）は、APIへの認証フローをすべて洗い出すこと、資格情報の回復に使うエンドポイントもログインと同じくブルートフォース対策・レート制限・ロックアウトの対象にすることを求めています。移行窓口は期間限定の機能で、この洗い出しから漏れやすい種類です。OWASP Top 10:2025のA07（認証の失敗）も、自動化された試行をすぐに止められない状態を弱点に挙げています。

旧アプリのログイン状態に紐付けた1回限りの移行コードをPythonで発行・検証する例

旧アプリにまだログイン状態が残っている会員なら、そのセッションを本人確認の根拠にできます。旧アプリ側で短い期限の移行コードを発行し、新アプリで1回だけ引き換えさせる方式です。OWASP Forgot Password Cheat Sheetがトークンに求める「暗号論的に安全な乱数」「十分な長さ」「安全な保存」「1回限りと期限」「ユーザーへの紐付け」を、そのまま移行コードに当てはめました。乱数はPythonのsecretsモジュールで作ります。

# 会員移行：旧アプリのログイン中セッションに紐付けた1回限りの移行コードを発行・引き換える（Python 3.9以上・標準ライブラリのみ）
import hashlib
import secrets
from datetime import datetime, timedelta

TTL = timedelta(minutes=10)          # 移行コードの有効期限
old_sessions = {"sess-7f3a": "M0001"}  # 旧アプリでログイン中のセッション → 会員ID
codes = {}                           # sha256(移行コード) → 発行情報（平文は保存しない）
migrated = set()                     # 新アプリの認証情報を発行済みの会員ID
log = []                             # 認証情報の作成ログ（作成経路と端末を残す）

def h(code):
    return hashlib.sha256(code.encode()).hexdigest()

def issue(old_session, now):
    """旧アプリから呼ぶ。会員コードや生年月日では発行しない。"""
    member = old_sessions.get(old_session)
    if member is None or member in migrated:
        return None
    code = secrets.token_urlsafe(32)
    codes[h(code)] = {"member": member, "exp": now + TTL, "used": False}
    return code

def redeem(code, device_id, src_ip, now):
    """新アプリから呼ぶ。成功時だけ新しい認証情報を作る。"""
    rec = codes.get(h(code))
    if rec is None or rec["used"] or now > rec["exp"] or rec["member"] in migrated:
        return "NG"
    rec["used"] = True
    migrated.add(rec["member"])
    log.append((now.isoformat(timespec="seconds"), rec["member"], "migration", device_id, src_ip))
    return "OK " + rec["member"]

t0 = datetime(2026, 11, 4, 10, 0, 0)
c = issue("sess-7f3a", t0)
print("1 正規の引き換え    :", redeem(c, "dev-A", "192.0.2.10", t0 + timedelta(minutes=2)))
print("2 同じコードを再利用:", redeem(c, "dev-X", "203.0.113.7", t0 + timedelta(minutes=3)))
print("3 移行済みに再発行  :", issue("sess-7f3a", t0 + timedelta(minutes=4)))
c2 = secrets.token_urlsafe(32)
print("4 推測したコード    :", redeem(c2, "dev-X", "203.0.113.7", t0 + timedelta(minutes=5)))
old_sessions["sess-9b21"] = "M0002"
c3 = issue("sess-9b21", t0)
print("5 期限切れ          :", redeem(c3, "dev-B", "192.0.2.22", t0 + timedelta(minutes=11)))
print("作成ログ:", log)

Python 3.14.7（Windows）で2026年11月4日に実行した結果です。デニーズアプリの仕様を再現したものではありません。

1 正規の引き換え    : OK M0001
2 同じコードを再利用: NG
3 移行済みに再発行  : None
4 推測したコード    : NG
5 期限切れ          : NG
作成ログ: [('2026-11-04T10:02:00', 'M0001', 'migration', 'dev-A', '192.0.2.10')]

通るのは1だけです。移行コードはハッシュで保存しているので、データベースが読まれてもそのまま使われません。旧アプリのセッションが切れている会員には、この方式は使えません。その場合は登録済みメールアドレスへ確認リンクを送り、リンクにも同じ5条件を課します。旧アプリの認証トークンを新アプリでそのまま受け入れる設計は、期限と失効の管理が二重になるので避けます。トークンの寿命の決め方はリフレッシュトークンのローテーションと寿命設計で扱いました。

移行窓口を期間で閉じ、移行済み会員への認証情報の再発行を断る運用ルール

移行窓口は、移行が進むほど正規の利用が減り、相対的に不正な利用の比率が上がります。リニューアル直後の数週間は移行が集中し、その後は件数が減っていく傾向です。件数が落ちた時点で窓口を閉じるか、本人確認を強めた別経路（メール確認リンク、店頭での手続き）に切り替える判断を、公開前に決めておきます。

上のコードの3番目のように、すでに移行を終えた会員への再発行は断ります。認証情報を持っている人が移行窓口を使う理由は無いからです。送信元ごと・会員ごとの回数制限は、API不正アクセス対策の実装手順のレート制限の章と同じ考え方で入れます。

本人操作と第三者操作を後から区別できるログ設計と、作成済み認証情報の棚卸し

OWASP Logging Cheat Sheetの作成経路・端末識別子・送信元の記録

本件で人数が確定しない原因は、正規の移行と不正な作成を後から見分けられないことでした。OWASP Logging Cheat Sheetは、記録すべき出来事に認証の成功と失敗、ユーザーの追加などの管理操作を挙げ、「誰が」の属性として利用者の端末識別子とIPアドレス、利用者の識別子を挙げています。認証情報の作成はユーザーの追加にあたるので、毎回これを残します。

実務で最低限残すのは4つです。作成した日時、対象の会員ID、作成経路（新規登録・移行・パスワード再設定など）、作成要求を送ってきた端末の識別子と送信元IPです。作成経路の列が無いと、移行で作られたものと新規登録で作られたものを分けられません。旧アプリ側でも、会員ごとに最後に使われた端末の識別子を移行期間中は消さずに残します。

移行経路で作られた認証情報を、端末と送信元で絞り込むSQLの棚卸し例

上の属性が残っていれば、移行で作られた認証情報のうち、旧アプリで使われていた端末と一致しないもの、または1つの送信元から多数の会員分が作られたものを拾えます。Pythonのsqlite3で試せる形にしました。

# 移行経路で作られた認証情報のうち、本人の端末と結び付かないものを洗い出す（Python 3.9以上・標準ライブラリのみ）
import sqlite3

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE old_app_devices (member TEXT, device_id TEXT, last_seen TEXT);
CREATE TABLE credential_events (ts TEXT, member TEXT, path TEXT, device_id TEXT, src_ip TEXT);
INSERT INTO old_app_devices VALUES
 ('M0001','dev-A','2026-07-20'), ('M0002','dev-B','2026-08-02'),
 ('M0003','dev-C','2026-09-15'), ('M0004','dev-D','2026-06-30');
INSERT INTO credential_events VALUES
 ('2026-07-21T08:10:00','M0001','migration','dev-A','192.0.2.10'),
 ('2026-09-12T02:14:05','M0002','migration','dev-X','203.0.113.7'),
 ('2026-09-12T02:14:41','M0003','migration','dev-X','203.0.113.7'),
 ('2026-09-12T02:15:20','M0004','migration','dev-Y','203.0.113.7'),
 ('2026-09-13T19:30:00','M0003','password_reset','dev-C','198.51.100.4');
""")

SQL = """
WITH m AS (
  SELECT e.*, (SELECT COUNT(DISTINCT e2.member) FROM credential_events e2
               WHERE e2.path = 'migration' AND e2.src_ip = e.src_ip) AS members_per_ip
  FROM credential_events e WHERE e.path = 'migration'
)
SELECT m.ts, m.member, m.device_id, m.src_ip, m.members_per_ip,
       CASE WHEN d.device_id IS NULL THEN 'unknown-device' ELSE 'known-device' END AS device
FROM m LEFT JOIN old_app_devices d ON d.member = m.member AND d.device_id = m.device_id
WHERE d.device_id IS NULL OR m.members_per_ip >= 3
ORDER BY m.ts
"""
for row in db.execute(SQL):
    print(*row)

同じ環境での実行結果です。データは説明用に作ったもので、デニーズジャパンの記録ではありません。

2026-09-12T02:14:05 M0002 dev-X 203.0.113.7 3 unknown-device
2026-09-12T02:14:41 M0003 dev-X 203.0.113.7 3 unknown-device
2026-09-12T02:15:20 M0004 dev-Y 203.0.113.7 3 unknown-device

5件の作成記録のうち、旧アプリで使っていた端末から移行したM0001と、移行ではないパスワード再設定は出ません。1つの送信元から1分あまりの間に3人分が作られた記録だけが残ります。機種変更と同時に移行した正規の会員も「unknown-device」になるため、これは無効化の対象ではなく、本人確認の連絡先リストとして使うためのものです。絞り込みの条件は、端末と送信元に加えて、作成直後に会員情報を読む処理が続いたかどうかも足すと精度が上がります。

会員移行を控える事業者の判断：移行窓口を残す期間と公開前に診断する範囲

移行窓口を公開し続ける条件と、旧アプリのセッションが無い会員を店頭へ回す場面

移行窓口を開けておいてよいのは、旧アプリのセッションか登録済みメールアドレスで本人を確かめられ、作成経路と端末を記録できている間だけです。どちらかが欠けるなら、窓口は閉じます。会員コードと生年月日だけで移行させる簡易経路は、利用者の手間が減っても採用しません。会員コードは会員証として店頭で画面に出す値で、秘密ではないからです。

旧アプリのセッションが切れていて、登録メールアドレスも使えなくなった会員は、オンラインの移行を諦めてもらい、店頭やカスタマーセンターでの手続きに回します。ポイントの引き継ぎで救える会員は減りますが、第三者に認証情報を作られる経路を残すよりは損失が小さい判断です。会員アプリの認証と認可の点検項目は会員サイトのセキュリティ対策の設計チェック項目に、アプリAPIの認可の点検はセイコーマートの事案でのアプリAPIの認可点検にまとめています。

リニューアル時の移行処理を、本番公開前に第三者の脆弱性診断で確かめる範囲

リニューアルの診断では、新アプリのログインや会員画面は対象に入っても、期間限定の移行窓口は外れがちです。診断範囲には、移行窓口と、そこで作られる認証情報で何が見えるかまでを入れます。具体的には、他人の会員コードで移行を試みたときの応答、移行済みの会員への再発行、短時間の大量試行、作成ログに経路と端末が残るかの4点です。

移行を終えた後に残る旧基盤のデータも、同じく点検の対象です。移行済みEC基盤に残る旧データの扱いも参考になります。会員移行の処理を公開前に第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

デニーズアプリの不正アクセスについて、利用者と、会員アプリを運営する側から出やすい質問をまとめました。

デニーズアプリの不正アクセスで、自分が対象かどうか確かめる方法はありますか？

2026年11月3日の第一報の時点では、対象かどうかを利用者が自分で確かめる手段は公表されていません。対象となる可能性があるのは旧デニーズアプリを使っていた会員の一部で、同社は対象者を特定でき次第、個別に連絡するとしています。それまでの問い合わせは、デニーズアプリカスタマーセンターのお問い合わせフォームで受け付けています。

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

デニーズジャパンは、氏名・住所・電話番号・パスワード・クレジットカード情報をそもそも保持していないとしています。漏えいした可能性があるのは、アプリ会員コード、メールアドレス、生年月日、性別、お住まいの都道府県、お気に入り店舗、キッズバースデーの7項目です。第三者が実際に取得したかどうかは調査中です。

アプリを開いたらログイン画面に戻りました。乗っ取られたのでしょうか？

第一報は、今回の対策に伴い、一部の利用者でアプリ起動時に初期画面が表示され、再ログインが必要になる場合があると説明しています。不正な認証情報を無効化した影響で起きるもので、ログイン画面に戻ったことだけで乗っ取りとは言えません。アプリストアから入れた公式アプリの中でログインし直してください。

デニーズを名乗るメールが届いたらどうすればよいですか？

同社は、当社や関係機関を装った不審なメールが送られる可能性を否定できないとして、身に覚えのないメールのURLを開かず、個人情報を入力しないよう求めています。漏えいの可能性がある情報にメールアドレスと生年月日が含まれるため、それらを本文に入れ、本物らしく見せかけたメールにも注意が必要です。確認はメール内のリンクではなく、端末のアプリから行います。

デニーズアプリの不正アクセスの原因は何ですか？

旧デニーズアプリから新アプリへの移行に関するシステム処理で、第三者が認証情報を不正に作成できたことが原因です。具体的な不備や攻撃の手法は、第一報では公表されていません。同社は専門部署とシステム開発会社と連携して原因の究明と再発防止に取り組むとしており、新しい事実は同社ホームページ等で知らせるとしています。

関連記事

• タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか：会員アプリの認証・認可の抜けを扱った同型の事案
• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：他人の会員データへ届く抜けをサーバ側で止める方法
• 多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説：移行後のログインに追加する認証方式の選び方
• ferret Oneの不正アクセス：問い合わせ情報1万6,970件の範囲と管理画面の点検：同時期に公表された、認証の手前の窓口が狙われた事案
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えいの「おそれ」段階での速報と確報の期限