---
title: "宝くじ公式サイト不正アクセス：4,436名の対象確認とパスワード再設定、変更された仕組み"
url: "https://www.issoh.co.jp/tech/details/19727/"
published: 2026-11-13
updated: 2026-11-13
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# 宝くじ公式サイト不正アクセス：4,436名の対象確認とパスワード再設定、変更された仕組み

宝くじ公式サイトと公式アプリで、4,436名の会員アカウントに不正ログインがあり、そのうち4,133名のパスワードが変えられました。発売元である全国都道府県及び全指定都市が2026年11月13日に公表した数字で、手口は他のサービスから漏れたメールアドレスとパスワードを使う「リスト型攻撃」とみられています。前半では、自分は対象か、届いた再設定メールは本物か、口座やカードの情報はどうなるかに公式の文言で答える構成です。後半は会員サイトを運営する事業者の開発者に向けて、ログインの直後にパスワードまで変えられる構造を読み解き、その変更を検知するコードと、変更を止める追加認証の実装を実行結果つきで示します。

## まとめ：宝くじ公式サイトの不正ログインで会員が11月13日以降に確かめること

会員全員がすることは、パスワードの再設定です。不正ログインの対象かどうかに関係なく、全ての会員のパスワードがリセットされました。サイトとアプリは11月13日午前8時に再開しています。

| 確かめること   | 公式の案内             |
| -------- | ----------------- |
| 対象かどうか   | 対象者には個別にメールで連絡済み  |
| パスワード    | 全会員がリセット済み。再設定が必要 |
| 他社のサービス  | 同じ組み合わせなら他社側も変更   |
| 当せん金・購入  | 不正な受取・購入は確認されていない |
| サーバーへの侵入 | 形跡なし。会員データの流出も未確認 |

再設定は、登録したメールアドレスに届くメールか、公式サイトのトップページから行います。11月13日の正午には、Microsoft社のサービス障害の影響で再設定のメールが届かない場合があると案内されました。メールのリンクに不安があるなら、ブックマークから[公式サイトの「パスワードをお忘れの方」の画面](https://www.takarakuji-official.jp/forget/)を開けば、同じ手続きができます。

## 宝くじ会員が確かめる対象の連絡と再設定メールの見分け方、口座とカードの扱い

### 対象者への個別メールと、対象外の会員にも求められた再設定の手順

不正ログインを受けた4,436名には、個別にメールで連絡したと[11月13日の発表](https://www.takarakuji-preliminary.jp/newsrelease%5F20261113.pdf)に書かれています。自分で対象かどうかを照会するページの案内はありません。

対象でなくても、パスワードの再設定は全員に必要です。[パスワード再設定手順書](https://www.takarakuji-preliminary.jp/password-reset%5Fexplanation%5Fsp.pdf)の流れは、「パスワードをお忘れの方」の画面で登録したメールアドレス等を入れて送信し、届いたメールのURLから新しいパスワードを決める、というものです。再設定してログインしたら、登録内容が正しいかも念のため確かめるよう求められています。

### 件名「パスワード変更手続きのお知らせ」と送信元ドメインで本物を見分ける基準

手順書に載っている正規のメールは、件名が「パスワード変更手続きのお知らせ」で、送信元は宝くじ公式サイトのドメイン takarakuji-official.jp です。本文には受付日時と、手続き用のURL、その有効期限が書かれています。自分で再設定を申し込んでいないのにこの件名のメールが届いたら、リンクは開かないほうが安全です。

見た目だけでは本物と決められません。送信元の表示は偽装できるからです。公式は、不審なメールやサイトでメールアドレスやパスワードを入力しないよう呼びかけています。迷ったときは、メールのリンクを使わず、ブックマークか検索から公式サイトを開いて手続きします。偽のメールと偽サイトが組み合わさる仕組みは[フィッシング詐欺の成立の仕組みと対策](https://www.issoh.co.jp/tech/details/13548/)で解説しました。

### 再設定メールが届かないときの11月13日正午の案内と、コールセンターの受付

11月13日12時、[公式サイトのお知らせ](https://www.takarakuji-official.jp/)に次の案内が載りました。Microsoft社サービスの障害の影響で、一部の会員にパスワード再設定に関するメールが届かない等の事象が出ており、同社のサービス復旧後に手続きしてほしい、という内容です。届かない場合は、迷惑メールのフォルダを見たうえで、時間を置いて申し込み直します。

電話の窓口は宝くじコールセンターで、0570-01-1192（ナビダイヤル）と011-330-0777のいずれもガイダンス【1】です。受付は10時30分から18時30分で、土日祝日と年末年始は休みです。ただし11月14日（土）と15日（日）は10時から17時まで受け付けています。どちらの番号も通話料がかかります。

### 閲覧された可能性のある口座情報とカード下4桁、当せん金の受取の状況

第三者に閲覧された可能性があるのは、氏名、生年月日、性別、住所、電話番号、メールアドレスに加え、次の項目です。

- 当せん金受取口座の金融機関名、口座番号の上4桁、口座名義
- クレジットカード番号の下4桁
- 購入履歴（くじの種類、金額、当落の情報）
- プロフィール画像（登録した人のみ）

口座番号もカード番号も一部の桁だけなので、この情報だけで引き出しや決済はできません。注意したいのは、当落や購入額を知っている前提で「当せん金の受け取り手続き」を装う連絡です。11月13日時点で、不正ログインに伴う購入や、口座の変更による当せん金の受取は確認されていません。

### 同じパスワードを使う他社サービスの変更と、売場でのポイントカード表示

今回のパスワードは、宝くじのサイトから漏れたものではありません。外部で手に入れられた組み合わせが使われたとみられています。宝くじと同じメールアドレスとパスワードを他社のサービスでも使っているなら、そちらのパスワードも変えるよう求めるのが公式の案内です。ネット銀行やECサイトのように、お金や配送先に関わるサービスから先に変えます。

宝くじ売場で公式アプリのポイントカードを使う人は、先にパスワードの変更を済ませておく必要があります。変更が済むと、アプリでポイントカードを表示できるようになります。売場での購入そのものは、サイトとアプリが止まっていた間も通常どおりでした。

## 11月4日の不正ログインから13日の再開まで、3回の公表で明らかになった内容

### 11月6日・11日・13日の公表文で増えた情報と、サイト停止から再開までの日付

公表は3回に分かれ、件数は最後の発表で初めて出ました。

| 日付         | 出来事・公表内容            |
| ---------- | ------------------- |
| 11月4日〜5日   | 不正ログインが発生           |
| 11月5日      | 公式サイトと公式アプリを停止      |
| 11月6日      | パスワードの意図しない変更と停止を告知 |
| 11月11日     | 閲覧された可能性のある項目を公表    |
| 11月13日 8時  | 件数を公表し、全会員リセットのうえ再開 |
| 11月13日 12時 | 再設定メールが届かない事象を案内    |

[11月6日の告知](https://www.takarakuji-preliminary.jp/newsrelease%5F20261106%5Fv1.pdf)は、パスワードが意図せず変更される事象を入口に書かれ、復旧時期は未定でした。[11月11日の更新](https://www.takarakuji-preliminary.jp/newsrelease%5F20261111.pdf)で閲覧された可能性のある項目と「リスト型攻撃」の語が加わり、13日に4,436名と4,133名という数字が出ています。

### 4,436名のうち4,133名で変更、93％という比率が示す攻撃の自動化

ログインされたアカウントのうち、パスワードが変えられたのは4,133名で、割合にすると約93％です。ほぼ全てのアカウントで、ログインの直後に変更まで進んだことになります。1件ずつ人が操作したとは考えにくく、ログインと変更をひと続きで流す仕組みが使われたと読むのが自然です。ただし、攻撃の方法について公式は説明していません。

パスワードを変えられると、本人は自分のアカウントに入れなくなります。気づくのは「ログインできない」ときで、その間、攻撃者だけが中を見られる状態が続きます。リスト型攻撃そのものの検知指標と漏えい照合は[パスワードリスト攻撃の検知の指標と漏えい照合](https://www.issoh.co.jp/tech/details/18730/)で扱いました。本記事はその事例として、変更の段階を掘り下げます。

### 攻撃元や試行回数など、11月13日時点で公表されていない6項目

2026年11月13日に確認した時点で、次の6つは公表されていません。この記事でも推測で補いません。

- 攻撃元と、ログインの試行回数・失敗件数
- 多要素認証を会員に提供していたかどうか
- パスワードの保存方式
- パスワードを変えた後に、攻撃者が何をしたか
- 閲覧の有無を、アカウントごとにどこまで確かめたか
- 個人情報保護委員会への報告の有無

サーバーへの侵入がないと書かれている点は、会員にとって安心材料です。宝くじのサイトのデータベースから一覧が持ち出されたのではなく、正しいパスワードでの「ログイン」が起きたという整理になります。

## リスト型攻撃でログイン直後にパスワードを変えられる会員サイトの構造と検知の実装

### 現在のパスワードの確認が、リスト型攻撃の変更を止められない理由

ここからは、会員サイトを運営する事業者の開発者に向けた内容です。パスワード変更の画面で「現在のパスワード」を求めるのは定石で、[OWASPのAuthentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication%5FCheat%5FSheet.html)も、変更の前に現在の認証情報を求めるよう書いています。

リスト型攻撃では、これが壁になりません。攻撃者はログインに使った正しいパスワードを持っているので、現在のパスワードの欄にもそのまま入れられます。同じ文書が例に挙げるもう1つの手段、すでに登録済みのパスキーのような「攻撃者の手元にない要素」を求めない限り、変更は通ります。止めるには、パスワードとは別の要素を変更の時点で求めるしかありません。

試行の回数で止める方法にも限界があります。[NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html)の3.2.2節は、1つの認証器への連続した失敗を100回以下に制限するよう定めています。リスト型攻撃は1つのアカウントに1回ずつ正解を当てにくるので、失敗の回数で効くのは外れた組み合わせの側だけです。

### ログインから数秒の変更を端末単位で束ねて拾う、Pythonの検知と実行結果

今回のように、ログインの直後にパスワードを変える動きは、ログの2つの行を突き合わせれば拾えます。次のスクリプトは、ログイン成功から10分以内の変更を集め、同じ送信元IPか同じ端末の特徴で3アカウント以上に及んでいれば要対応とする仕組みです。30秒以内の変更も別に出します。

```
# ログイン成功の直後にパスワードが変わったアカウントを拾い、送信元ごとに束ねる（Python 3.9以上・標準ライブラリのみ）
# ログはすべて検証用のダミー。IPは文書用アドレス（RFC 5737）を使っている
from collections import defaultdict
from datetime import datetime, timedelta

WINDOW = timedelta(minutes=10)  # ログインからこの時間内の変更を「直後」とみなす
FAST = timedelta(seconds=30)    # 人の操作では難しい速さ
SPREAD = 3                      # 同じ送信元・端末でこの数以上のアカウントなら攻撃とみなす

LOG = [  # (時刻, 種別, 会員ID, 送信元IP, 端末ID)
    ("2026-11-04 21:00:05", "login_ok", "m001", "203.0.113.10", "fp-77"),
    ("2026-11-04 21:00:09", "pw_change", "m001", "203.0.113.10", "fp-77"),
    ("2026-11-04 21:00:12", "login_ok", "m002", "203.0.113.11", "fp-77"),
    ("2026-11-04 21:00:15", "pw_change", "m002", "203.0.113.11", "fp-77"),
    ("2026-11-04 21:00:20", "login_ok", "m003", "203.0.113.12", "fp-77"),
    ("2026-11-04 21:00:24", "pw_change", "m003", "203.0.113.12", "fp-77"),
    ("2026-11-04 21:00:31", "login_ok", "m004", "203.0.113.10", "fp-77"),  # 変更に失敗した例
    ("2026-11-04 21:05:00", "login_ok", "m100", "198.51.100.5", "fp-01"),  # 本人がゆっくり変更
    ("2026-11-04 21:07:40", "pw_change", "m100", "198.51.100.5", "fp-01"),
]


def detect(log):
    last_login = {}
    by_key = defaultdict(set)
    fast = []
    logins = changes = 0
    for ts, kind, member, ip, dev in sorted(log):
        t = datetime.fromisoformat(ts)
        if kind == "login_ok":
            logins += 1
            last_login[member] = (t, ip, dev)
        elif kind == "pw_change" and member in last_login:
            lt, lip, ldev = last_login[member]
            if t - lt > WINDOW:
                continue
            changes += 1
            by_key[("ip", lip)].add(member)
            by_key[("端末", ldev)].add(member)  # IPを替えても端末の特徴は残りやすい
            if t - lt <= FAST:
                fast.append((member, int((t - lt).total_seconds())))
    return logins, changes, by_key, fast


logins, changes, by_key, fast = detect(LOG)
print(f"ログイン成功 {logins} 件のうち直後のパスワード変更 {changes} 件（{changes / logins:.0%}）")
for (kind, key), members in sorted(by_key.items()):
    if len(members) >= SPREAD:
        print(f"要対応: {kind} {key} が {len(members)} アカウントで直後変更 {sorted(members)}")
print("30秒以内の変更:", ", ".join(f"{m}({s}秒)" for m, s in fast))
```

Python 3.14.10（Windows）で2026年11月13日に実行した結果です。終了コードは0でした。

```
ログイン成功 5 件のうち直後のパスワード変更 4 件（80%）
要対応: 端末 fp-77 が 3 アカウントで直後変更 ['m001', 'm002', 'm003']
30秒以内の変更: m001(4秒), m002(3秒), m003(4秒)
```

攻撃の3アカウントはIPを1件ずつ替えているので、IP単位では1アカウントずつにしか見えず、要対応に上がりません。端末の特徴で束ねると、同じ端末が3〜4秒で次々に変更していたことが分かります。本人の m100 は2分40秒かけて変更しており、30秒以内の一覧にも入りません。実運用では、端末の特徴をログイン画面のスクリプトやTLSの指紋から作り、10分ごとの集計で通知します。[OWASPのCredential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential%5FStuffing%5FPrevention%5FCheat%5FSheet.html)も、多層の防御として、IPアドレスによる対策と並べて端末の指紋（Device Fingerprinting）を挙げています。

## 変更時の追加認証と旧連絡先への通知、全会員リセットで再設定メールが詰まる問題

### 新しい端末からの変更に追加認証を求め、旧連絡先へ通知するPythonと結果

検知は、変更が起きた後に動きます。変更そのものを止めるには、パスワード変更の処理に条件を足す設計が必要です。次のスクリプトは、過去に使ったことのない端末からの変更に追加認証を求め、変更を通したときは他のセッションを失効させて、変更前の連絡先へ通知します。当せん金のような払出先の口座は、変更を受け付けても72時間は反映しません。

```
# パスワードと払出口座の変更を、追加認証・旧連絡先への通知・待機時間で守る（Python 3.9以上・標準ライブラリのみ）
# 会員・端末・通知はすべて検証用のダミー。待機時間などの値は例
from datetime import datetime, timedelta

HOLD = timedelta(hours=72)  # 払出口座の変更を反映するまでの待機時間（例）
KNOWN_DEVICES = {"m100": {"fp-01"}}  # 会員ごとに過去に使った端末
SESSIONS = {"m100": ["s-1", "s-2"]}  # 会員ごとの有効なセッション
outbox = []


def notify(member, text):
    # 登録済みの連絡先へ送る。変更後の連絡先ではなく「変更前」の宛先に送るのが要
    outbox.append(f"{member}: {text}")


def change_password(member, device, step_up_ok, now):
    # リスト型攻撃では攻撃者も現在のパスワードを知っているので、それだけでは止まらない
    if device not in KNOWN_DEVICES.get(member, set()) and not step_up_ok:
        return "拒否: 新しい端末からの変更には追加認証（ワンタイムコードかパスキー）が必要"
    revoked = SESSIONS.pop(member, [])
    SESSIONS[member] = ["s-new"]
    notify(member, f"{now:%m/%d %H:%M} パスワード変更。心当たりがなければ取り消しリンクから戻す")
    return f"変更: 他のセッション {len(revoked)} 本を失効"


def change_payout(member, account_tail, now):
    apply_at = now + HOLD
    notify(member, f"払出口座の変更を受付（下4桁 {account_tail}）。{apply_at:%m/%d %H:%M} まで反映しない")
    return f"保留: {apply_at:%m/%d %H:%M} に反映"


now = datetime(2026, 11, 4, 21, 0)
print("攻撃者（新しい端末・追加認証なし）:", change_password("m100", "fp-77", False, now))
print("本人（いつもの端末）:", change_password("m100", "fp-01", False, now))
print("本人（払出口座の変更）:", change_payout("m100", "4321", now))
print("通知:", *outbox, sep="\n  ")
```

同じ環境で実行した結果です。終了コードは0でした。

```
攻撃者（新しい端末・追加認証なし）: 拒否: 新しい端末からの変更には追加認証（ワンタイムコードかパスキー）が必要
本人（いつもの端末）: 変更: 他のセッション 2 本を失効
本人（払出口座の変更）: 保留: 11/07 21:00 に反映
通知:
  m100: 11/04 21:00 パスワード変更。心当たりがなければ取り消しリンクから戻す
  m100: 払出口座の変更を受付（下4桁 4321）。11/07 21:00 まで反映しない
```

攻撃者は正しいパスワードを持っていても、新しい端末からは追加認証で止まります。本人がいつもの端末で変えた場合は変更が通り、残っていたセッション2本は失効する仕組みです。攻撃者が先に入っていたなら、このとき追い出されます。追加認証の方式の比べ方は[多要素認証（MFA）の3要素と実装方式](https://www.issoh.co.jp/tech/details/13314/)で、パスワードを使わない形へ寄せる手順は[パスキー移行の実装手順](https://www.issoh.co.jp/tech/details/17716/)で整理しました。

通知を変更前の連絡先へ送るのは、攻撃者がメールアドレスも同時に書き換える場合に備えるためです。[OWASPのForgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot%5FPassword%5FCheat%5FSheet.html)は、パスワードを再設定したら本人にメールで知らせること、侵害が疑われる回復の後は既存のセッションと未使用の再設定リンクを無効にすることを求めています。

### 全会員リセットの再設定メールが1つの配送経路に集中したときの詰まりと分散

宝くじ公式サイトは、全会員のパスワードをリセットしたうえで再開しました。本人以外に変えられたパスワードを確実に無効にする手段として筋が通っています。その代わり、全会員の復旧がメール1本の経路に乗ります。再開から4時間後の正午には、Microsoft社のサービス障害の影響で再設定のメールが届かない場合があると案内されました。障害の中身は公表されていません。

開発側が持ち帰る点は2つです。1つは、一斉リセットの前に、会員のメールアドレスのドメイン別の件数と、送信基盤の1時間あたりの上限を突き合わせ、送信を時間で分けること。もう1つは、メール以外の復旧経路を事前に用意しておくことです。SMSのワンタイムコードや、登録済みのパスキーでの本人確認がその例です。メールしか経路が無いと、配送側の障害や受信側の迷惑メール判定がそのまま会員の締め出しになります。

### 当せん金の受取口座のような払出先の変更に、待機時間と通知を置く理由

今回、口座の変更による当せん金の受取は確認されていません。それでも、ログインした攻撃者が最初に狙うのは、お金の出口を自分の口座に向けることです。払出先の変更に72時間などの待機時間を置き、その間に変更前の連絡先へ通知すれば、本人が気づいて止める余地が生まれます。

待機時間は、本人の不便と引き換えです。当せん金のように支払いの時期が分かっていて急ぐ必要が少ない用途では、待機を置く利点が大きくなります。即時の送金を売りにするサービスでは、待機の代わりに変更時の追加認証を必須にする設計です。公開APIの側で認可やトークンの失効をどう組むかは[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)にまとめています。

## 会員1,000人超の漏えい等報告と、会員サイトの運営者が診断を先に入れる条件

### 閲覧のおそれも含む1,000人超の漏えい等報告と、民間の運営者が見る期限

民間の事業者が運営する会員サイトで同じことが起きた場合の扱いを確かめておきます。[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、漏えいが確定していなくても「おそれ」の段階で報告の対象になり、本人の数が1,000人を超える場合や、不正の目的で行われたおそれがある場合が含まれます。不正の目的による場合の確報の期限は、発覚日から60日以内です。

宝くじの発売元は地方公共団体なので、民間の事業者とは適用される規定の枠組みが違います。報告の有無も11月13日の時点で公表されていません。ここでは宝くじの扱いを判断せず、民間の運営者が自社の事案に当てはめる基準として示しました。報告と本人への通知の流れは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で確認できます。

### 払出口座を持つ会員サイトが先に入れる対策と、第三者の診断を頼む境目

結論から書くと、上の2本のうち検知のスクリプトは会員の規模を問わず入れます。ログイン成功とパスワード変更のログが残っていれば数十行で書け、今回のような一斉の変更を当日のうちに拾えるからです。

次のいずれかに当てはまる会員サイトは、変更時の追加認証まで入れたうえで、第三者の診断を先に受けます。当せん金や売上金、ポイントの換金のように会員へお金を払い出す、会員の口座やカードの情報を一部でも画面に表示している、会員が数万人を超えている、のいずれかです。反対に、会員がログインしても閲覧できるのが購入履歴程度で、払い出しも決済情報も持たない小規模なサイトなら、管理者の多要素認証と検知の通知を整えるところまでで十分です。ログインとアカウント変更の守りを第三者の目で確かめたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でご相談いただけます。

## よくある質問

宝くじ公式サイトの不正ログインについて、会員から出やすい質問をまとめました。内容は2026年11月6日、11日、13日の公表文と、13日正午の公式サイトのお知らせに基づきます。

### 宝くじ公式サイトの不正アクセスで、自分が対象かどうかはどう確かめますか？

不正ログインを受けた4,436名には、個別にメールで連絡したとされています。自分で照会するページの案内はありません。対象でなくても、全会員のパスワードがリセットされているので、再設定は全員に必要です。メールが本物か迷う場合や、ログインできない理由が分からない場合は、宝くじコールセンター（0570-01-1192、ガイダンス【1】）に問い合わせます。

### パスワード再設定のメールが届かないときはどうすればよいですか？

11月13日12時の公式のお知らせでは、Microsoft社サービスの障害の影響で、一部の会員に再設定のメールが届かない等の事象が起きているとされ、同社のサービスの復旧後に手続きするよう案内されています。迷惑メールのフォルダも確かめ、時間を置いて公式サイトの「パスワードをお忘れの方」の画面から申し込み直してください。

### 当せん金の受取口座やクレジットカードの情報は悪用されますか？

閲覧された可能性があるのは、口座の金融機関名と口座番号の上4桁、口座名義、カード番号の下4桁です。番号の全桁ではないので、これだけで引き出しや決済はできません。11月13日時点で、不正ログインに伴う購入や口座変更による当せん金の受取は確認されていません。当落や購入額を知っているそぶりで手続きを求める連絡には応じないでください。

### 宝くじのサイトから個人情報が流出したのですか？

公式の説明では、サーバーやデータベースへの侵入の形跡はなく、会員データの流出も確認されていません。外部で手に入れられたメールアドレスとパスワードで、4,436名のアカウントにログインされ、その画面で会員情報が閲覧された可能性がある、という事案です。一覧が丸ごと持ち出された事案とは違いますが、ログインされたアカウントの情報は見られた前提で備えます。

### 宝くじと同じパスワードを他のサービスでも使っています。何をすればよいですか？

他社のサービスのパスワードを、それぞれ別のものに変えてください。公式も、同じメールアドレスとパスワードを他社のサービスで使っている会員に変更を求めています。ネット銀行やECサイトのように、お金や配送先に関わるものから先に変える順序です。多要素認証を設定できるサービスでは、併せて有効にしておくと、同じ手口でのログインを止めやすくなります。

## 関連記事

- [パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装](https://www.issoh.co.jp/tech/details/18730/)：今回の手口の検知と照合
- [カプコンの情報漏洩：CAPCOM ID 1,177万件の範囲と二段階認証・偽メールの見分け方](https://www.issoh.co.jp/tech/details/18825/)：パスワードの変更経路が狙われた事案
- [ファンくる不正アクセス：421万件の対象確認と連携会員の範囲、会員登録APIの認可不備](https://www.issoh.co.jp/tech/details/19576/)：リスト型攻撃とAPIの事案が続いた例
- [ローソンID不正アクセス：215万件の漏えい項目と本物メールの見分け方【10月24日訂正】](https://www.issoh.co.jp/tech/details/18328/)：会員IDの事案と本物メールの見分け方
- [APIレート制限（レートリミット）とは？5方式の比較と429設計・分散実装【2026年版】](https://www.issoh.co.jp/tech/details/16179/)：ログインURLへの試行を減らす設計

---

出典: [宝くじ公式サイト不正アクセス：4,436名の対象確認とパスワード再設定、変更された仕組み](<https://www.issoh.co.jp/tech/details/19727/>)（株式会社一創）