ローソンID：アプリの「本人の情報を表示する」仕組みから215万件が漏えい。

データベースが盗まれたのでも、ランサムウェアでもありません。ローソンの説明では、利用者に本人の情報を見せるためのアプリの仕組みから情報が出ていきました。顧客向けアプリを持つすべての企業にとってはAPI設計の問題であり、それ以外の企業にとってはフィッシングの問題です。国内のほとんどの人が使うブランドに結びついた215万件の氏名とメールアドレスだからです。

概要カード：「ローソンID 215万5,345件。アプリの『本人の情報を表示する』仕組みから漏えい。」の見出し。9月12〜14日と17日に不正アクセス、10月7日に判明、10月8日に公表。最後の不正アクセスから判明まで23日。漏えいした情報は、ローソンIDがメールアドレスと氏名、入力があれば性別、電話番号、住所、メルマガ取得情報。アプリ予約26件が氏名、電話番号、クレジットカード番号の一部。パスワード、ポイントカード番号、購買履歴は記載なし。

概要：この記事のために作成した図です。

ローソンが公表した内容

2026年10月8日、ローソンは2つのサービスへの不正アクセスについてお知らせを公表しました。ローソンのお知らせ

ローソンID は、ローソンのアプリやWEBサービスを利用するためのアカウントサービスです。9月12日（土）〜14日（月）に不正アクセスを受けました。
ローソンアプリ予約 は、季節の催事商品を公式アプリから事前に予約・決済できるサービスです。9月17日（木）に不正アクセスを受けました。
判明。 いずれも10月7日（水）に実施した調査の中で判明しました。これ以外の不正アクセスやマルウェア感染はないことを確認済みとしています。
原因の説明。 ローソンアプリに関連するシステムが不正に利用されたもので、本来アプリ上で利用者本人に情報を表示するためのセキュリティ機構が第三者による不正アクセスを受け、情報が漏えいしたとしています。
対応。 不審なアクセス元のブロック、アプリ予約機能の停止、アプリ上でのお知らせ、個人情報保護委員会など関係機関への報告を行い、対象のお客様には個別にメールで案内しています。アプリ予約は10月中旬に再開する予定です。
悪用。 現時点で、本件に起因する不正利用や二次被害は確認されていません。

サービス	件数	漏えいした情報
ローソンID	215万5,345件	メールアドレス、氏名。プレゼントの応募などで入力されている場合は、性別、電話番号、住所、メルマガ取得情報
ローソンアプリ予約	26件	氏名、電話番号、クレジットカード番号の一部

お知らせは「漏えいの可能性」ではなく「漏えいしたことを確認」と書いています。パスワード、Pontaカードやdポイントカードの番号、購買履歴は一覧にありません。安全だったと書かれているわけではなく、確認された情報が列挙されています。

2026年9月上旬から10月下旬までのタイムライン。ローソンIDは9月12〜14日に不正アクセスを受け、215万5,345件が漏えい。アプリ予約は9月17日に不正アクセスを受け、カード番号の一部を含む26件。10月7日の調査で判明し、ローソンIDへの最後の不正アクセスから23日後。10月8日にお知らせ、アプリ、メールで公表。アプリ予約は10月中旬に再開予定。3日間に均等にならすと、1時間あたり約3万件、1秒あたり約8件。

図1：公表の時系列。この記事のために作成した図です。

同じ日の夜、カラオケ店を運営する第一興商も、業務委託先の従業員の端末がマルウェアに感染し、顧客約872万件の情報が漏えいした恐れがあると発表しました。共同通信（サンスポ）

「本人に情報を表示するための仕組み」が示すもの

ローソンは欠陥の中身を説明していません。それでも、その言い回しから可能性は絞り込めます。漏えいは、ログインした利用者本人のデータを返すためのアプリ向けの機能を通じて起きました。こうした機能が他人のデータを返してしまう原因として、よくあるものは3つです。

オブジェクト単位の認可の不備。 サーバーが、リクエストが指定した顧客のデータを、それが呼び出した本人のものかを確かめずに返してしまうものです。攻撃者はIDを変えながら繰り返すだけです。OWASP API Security Top 10の1番目のリスクです。OWASP API1:2023（英語）
セッションやトークンの扱いの弱さ。 偽造、推測、再利用ができるトークンや、任意のアカウントのものを取得できるトークンを、サーバーが信用してしまうものです。
アプリから取り出された認証情報。 アプリに組み込まれた鍵や秘密情報を取り出せば、顧客としてログインしなくてもバックエンドを直接呼び出せてしまうものです。「アプリに関連するシステムが不正に利用された」という説明は、この読み方にも当てはまります。

どれだったとしても、アプリを運営するすべての企業にとって参考になる事実が2つあります。

量は目立たなかったか、警報につながらなかった。 3日間で215万5,345件は、均等にならすと1時間あたり約3万件、1秒あたり約8件です。ローソンアプリは4000万ダウンロードを超えており、プロフィールを返すAPIは正規の利用だけでもそのくらいの量をさばいている可能性があります。ローソンアプリ4000万ダウンロード突破際立つのは1つの呼び出し元が何人分の顧客データを読んだかです。本物の利用者が読むのは1人分です。
気づくまでに23日かかった。 ローソンは判明の翌日に公表しており、これは速い対応です。比べると、エイチ・アイ・エスはアラートから公表まで300日かかりました。エイチ・アイ・エス：検知から公表まで300日ローソンで遅れたのは公表ではなく、検知です。

返していたデータも問題です。住所や電話番号が漏えいしたのは、利用者に本人のプロフィールを見せるための機能でした。氏名と会員番号しか表示しない画面のために、裏側のAPIが自宅住所まで返す必要はありません。画面に表示する項目だけを返していれば、欠陥があっても漏れる範囲は限られます。OWASP API3:2023（英語）

このデータが重い理由

氏名とメールアドレスがあれば、説得力のあるフィッシングができる。 「ローソンIDが影響を受けました。こちらから情報をご確認ください」は、今週、215万人に届いても不自然ではない文面です。実際にローソン自身が対象者にメールを送っています。
電話番号と住所で手口が広がる。 入力されていた人については、SMSや電話も使えるようになり、自宅の住所は口実をもっともらしく見せます。
カード番号の一部は台本になる。 アプリ予約の26人に「下4桁が……のカードについて」と電話すれば、カード会社のように聞こえます。26件は少数ですが、手口は規模を問いません。
ブランドは多くのサービスにまたがる。 アプリ、ポイントカード、決済、チケットのどれを名乗っても誘い文句になります。ローソンは、ローソンチケットを騙った不審なメールへの注意をすでに呼びかけています。ローソンFAQ
業務用のアドレスも含まれる。 プレゼント応募やメルマガの登録に会社のメールアドレスを使う人は少なくありません。本物の案内も偽物も、一部は会社のメールボックスに届きます。

攻撃者の視点：この事案で何ができるか

攻撃者は特定されておらず、経路も上記の説明以上は公表されていません。以下は、消費者向けアプリのAPIに対してレッドチームが取る手順で、MITRE ATT&CKに対応づけています。

段階	この事案で考えられること	ATT&CK
アプリを調べる	検証用のスマートフォンで通信を中継・記録し、ログインした会員のプロフィールを返す呼び出しや、アプリが持つ鍵を探す	T1595 Active Scanning
チェックを突破する	公表なし。リクエストの会員IDを書き換える、トークンを再利用・偽造する、アプリから取り出した鍵でバックエンドを呼ぶ	T1190 Exploit Public-Facing Application; T1078 Valid Accounts
集める	呼び出しをスクリプト化して応答を保存する。週末と月曜日で215万件	T1119 Automated Collection
次の標的	3日後に同じ手口をアプリ予約に向ける。カード番号の一部を含む26件	T1190 Exploit Public-Facing Application
データを使う	ローソンを名乗るメール、SMS、電話。「下4桁が……」の電話。名簿の販売	T1566 Phishing; T1656 Impersonation; T1598 Phishing for Information

防御の考え方を決める点が2つあります。アプリを運営する側にとって、この種の欠陥はよくあるもので、普通のアカウントが2つあれば試せます。それ以外の企業にとって主なリスクは、今週の漏えいそのものではなく、来週届く誘い文句です。

防御側の視点

実務に使うには： APIデータ漏えいプレイブックで、封じ込め、対象と項目の認可、レコード単位の範囲、再開の検証を確認できます。ローソンの説明だけでは特定の認可欠陥は確定せず、手順は複数の可能性を扱います。

1. 顧客向けアプリを運営しているなら：「本人の情報」を返す呼び出しを試す

顧客はリクエストではなくセッションから決める。 個人情報を返すすべてのエンドポイントで、認証済みのセッションやトークンから対象の顧客を決め、求められたデータの持ち主が呼び出した本人でなければ拒否します。
2つのアカウントで試す。 顧客Aとしてログインし、IDを書き換えて顧客Bのプロフィール、注文、住所を求めます。利用中のすべてのアプリのバージョンで繰り返し、すべてのペネトレーションテストにアプリのAPIを含めます。
アプリに秘密情報を入れない。 アプリに同梱したものは取り出せます。顧客の認証を経ずにバックエンドを呼べる鍵をアプリに入れてはいけません。
画面に表示する項目だけを返す。 画面に必要なのが氏名だけなら、APIが住所や電話番号まで返すべきではありません。
制限し、記録する。 プロフィールの呼び出しにトークン、アカウント、IPアドレスごとの回数制限をかけます。返した顧客データのIDと呼び出し元を記録すれば、範囲の特定は数時間で済みます。OWASP API4:2023（英語）
委託先を確認する。 アプリの開発や運用は外部の会社が担うことが多くあります。下の質問を送ってください。攻撃者が顧客としてログインする関連のリスクは、顧客アカウント乗っ取りのプレイブックで扱っています。

2. スクレイピングを数週間ではなく数時間で見つける

呼び出し元ごとの顧客数で警報を出す。 本物の顧客が読むプロフィールは1人分です。1つのアドレス、トークン、アカウントが1時間に数人分を超えて読んだら警報を出します。
1つの送信元からの多数のアカウントを見る。 攻撃者が多数のアカウントでログインしている場合は、アドレスや端末ごとのアカウント数を数えます。
応答サイズと新しいクライアントを見る。 プロフィールの呼び出しが返すバイト数の急増、見慣れないアプリのバージョンやユーザーエージェント、ホスティング事業者からの通信は、手軽な補助の兆候です。
下のハンティングクエリを自社のAPIログで実行する。 ローソンほどの規模でも、顧客数による警報なら23日後ではなく最初の1時間で鳴ったはずです。

3. ローソンを装うフィッシングに従業員と顧客を備えさせる

ルールを1つ伝える。 お知らせによると、ローソンの案内はlawson_id@mailservice.lawson.jpから届きます。それでも、メッセージのリンクから操作せず、アプリを開くかアドレスを自分で入力します。
受信メールとDNSを見る。 ローソン、ローソンID、Pontaの名前を使った非公式ドメインからのメールを探し（下のクエリ）、確認できたなりすましドメインはブロックします。
コールセンターと人事に伝える。 氏名や住所、カード番号の一部を口にする電話がかかってくる可能性があります。確認はカードや公式サイトに載っている番号を通して行い、かけてきた相手の番号は使いません。
誰かがクリックしてしまった場合の対応は、フィッシング対応のプレイブックにまとめています。

4. 対応すべきチーム

チーム	確認する範囲	次の一手	必要な証跡
アプリ担当・IT運用	個人情報を返す顧客向けアプリのAPI	2アカウントのテスト、アプリ内の秘密情報の確認、回数制限の追加	エンドポイントごとのテスト結果と修正日
SIEM / SOC	APIゲートウェイとWebのログ	スクレイピングのクエリを定期実行し、呼び出し元ごとの顧客数で警報を出す	実行スケジュール、通知先、しきい値
メールセキュリティ	ローソン、ローソンID、Pontaを名乗るメール	メールのクエリを実行し、確認できたなりすましを期限付きでブロック	メール一覧、受信者、クリックの記録
法務 / プライバシー	各APIが返す項目と、報告の準備	データ最小化と、ログで漏えい範囲を特定できるかを確認	エンドポイントごとの項目一覧、ログの保存期間
委託先管理	アプリを開発・運用する委託先	下の質問を送る	書面の回答、最新のテスト報告書
人事・コールセンター	電話やSMSを受ける従業員と顧客	確認のルールを周知する	周知の記録、報告の記録

ハンティング：誘い文句は届いているか、自社のアプリは同じように漏れないか

侵害の痕跡（IOC）は公表されていません。 ローソンは、攻撃者のアドレス、ツール、リクエストの特徴を公表していません。1つ目のクエリは非公式ドメインからのローソンを名乗るメールを探し、残りは自社のAPIログでスクレイピングのパターンを探します。

いずれも例示であり、実データでは実行していません。 テーブル名とフィールド名は、2026年10月8日（日本時間）に各社のドキュメントで確認しました。ノイズに注意してください。本物のローソンの案内、ニュース、メルマガはメールのクエリに一致し、携帯キャリアの共有アドレスはアドレスごとの件数を押し上げます。

1. ローソン、ローソンID、Pontaを名乗る他ドメインからの受信メール。 Microsoft Defender XDRの高度なハンティング。Defender for Office 365が必要です。

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Inbound mail since 8 Oct 2026 that names Lawson, Lawson ID or Ponta but was not sent from Lawson's domains.
// Lawson says its own notices to affected customers come from lawson_id@mailservice.lawson.jp.
let Since = datetime(2026-10-08T00:00:00Z);
let LurePattern = @"(?i)lawson|ローソン|ponta|ポンタ";
let OfficialDomains = @"(?i)(^|\.)(lawson\.co\.jp|lawson\.jp|REPLACE_WITH_OTHER_VERIFIED_DOMAIN)$";
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where Subject matches regex LurePattern or SenderDisplayName matches regex LurePattern
| where not(SenderFromDomain matches regex OfficialDomains)
| join kind=leftouter (
    EmailUrlInfo
    | where Timestamp > Since
    | project NetworkMessageId, UrlDomain
    ) on NetworkMessageId
| summarize Recipients = dcount(RecipientEmailAddress), UrlDomains = make_set(UrlDomain, 10),
    FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| order by FirstSeen asc
| take 500

2. 自社のAPI：1つの呼び出し元が多数の顧客データを読む。 Azure Monitor、Azure API Managementのゲートウェイログ（リソース固有モード）。プロフィールのエンドポイントがIDを取らない場合（例：/me）でも、DistinctUsersとRequestsの条件は使えます。

// Illustrative; not run against live data. Azure Monitor Log Analytics, Azure API Management (resource-specific logs).
// For your own app: callers that read many different customer records through an endpoint meant to return the caller's own data.
// A normal user reads one record, their own. A scraper reads thousands. Set the operation or path of your profile endpoint.
let Since = ago(30d);
let ProfileOperation = @"(?i)REPLACE_WITH_PROFILE_OPERATION_OR_PATH";
ApiManagementGatewayLogs
| where TimeGenerated > Since
| where ResponseCode == 200
| where OperationId matches regex ProfileOperation or Url matches regex ProfileOperation
| extend ObjectId = extract(@"/(\d{4,}|[0-9a-fA-F-]{32,36})(?:[/?]|$)", 1, Url)
| summarize Requests = count(), DistinctObjects = dcount(ObjectId), DistinctUsers = dcount(UserId),
    ResponseMB = round(sum(ResponseSize) / 1048576.0, 1), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by CallerIpAddress, bin(TimeGenerated, 1h)
| where DistinctObjects > 50 or DistinctUsers > 20 or Requests > 1000
| order by Requests desc
| take 500

3. 同じ確認をSplunkで。 CIM形式のフィールド（uri_path、status、user、src）を持つWebやAPIゲートウェイのログが前提です。インデックス、ソースタイプ、プロフィールのパスを置き換えてください。

index="REPLACE_WITH_API_LOG_INDEX" sourcetype="REPLACE_WITH_API_SOURCETYPE" status=200 earliest=-30d
| rex field=uri_path "^/REPLACE_WITH_PROFILE_PATH/(?<object_id>[^/?]+)"
| where isnotnull(object_id)
| eval client=coalesce(user, src)
| bin _time span=1h
| stats dc(object_id) AS distinct_objects count AS requests dc(http_user_agent) AS user_agents BY _time client
| where distinct_objects > 50
| sort 0 - distinct_objects

ダウンロード：メールのKQL · APIのKQL · APIのSPL

その他のプラットフォーム。 Sumo Logicで、DNSやプロキシのログから、ローソンやPontaに似たドメインへの社内端末からのアクセスを探します。公式ドメインを含む行は除外しているため、lawson.jp.example.netのようななりすましも隠れます。別途確認してください。

_sourceCategory="REPLACE_WITH_DNS_OR_PROXY_SOURCE_CATEGORY" (*lawson* OR *ponta*) NOT "lawson.co.jp" NOT "lawson.jp" NOT "ponta.jp"
| count by _sourceCategory, _sourceHost
| sort by _count

CrowdStrike Falcon（LogScale / Next-Gen SIEM）で、端末からのDNS要求を見ます。

#event_simpleName=DnsRequest
| DomainName=/lawson|ponta/i
| DomainName!=/(^|\.)(lawson\.co\.jp|lawson\.jp|ponta\.jp)$/i
| groupBy([DomainName, aid], function=count())

結果がなくても、何も起きていない証明にはなりません。個人アドレスへのメールやSMSは会社のツールからは見えず、返した顧客データを記録していないAPIログではスクレイピングを確認できません。EmailEvents（英語） · ApiManagementGatewayLogs（英語）

コピーして使えるテンプレート

［］内をすべて置き換えてください。社外に出すものは、法務またはプライバシー担当の確認を受けてください。

顧客向けアプリを運営するチーム・委託先への質問

件名：［会社名］―ローソンIDの事案を受けた顧客向けアプリのAPIの確認

［ご担当者様］
ローソンが2026年10月8日に、アプリで利用者本人に情報を表示するための仕組みから顧客データが漏えいしたと公表したことを受け、以下について［期日］までに書面でご回答ください。
1. 顧客の個人情報（プロフィール、住所、電話番号、注文、決済情報）を返すAPIのエンドポイントはどれで、それぞれどの項目を返しますか。
2. それぞれ、どの顧客のデータを返すかをサーバーはどう決めていますか。認証済みのセッションやトークンからですか、リクエストのIDからですか。
3. ある顧客としてログインし、別の顧客のデータを求めるテストを、それぞれ実施しましたか。いつ、誰が、どんな結果でしたか。
4. アプリの中に、顧客がログインしなくてもバックエンドを呼べるAPIキー、クライアントシークレット、認証情報はありますか。
5. プロフィールや注文のエンドポイントに、トークン、アカウント、IPアドレスごとにどんな回数制限をかけていますか。
6. ログには、リクエストごとに呼び出し元と返した顧客データが記録されますか。保存期間はどれだけですか。
7. 1つの呼び出し元が多数の顧客のデータを読んだときの警報はありますか。しきい値はいくつで、業務時間外は誰が受けますか。
8. これらのエンドポイントを呼ぶ古いアプリのバージョンはどれが残っていて、同じチェックを使っていますか。
9. アプリのAPIを含むペネトレーションテストを最後に実施したのはいつで、高リスクの指摘はすべて修正済みですか。
10. 不正アクセスの疑いがある場合、何時間以内に、どの確認済みの経路で当社に連絡しますか。
よろしくお願いいたします。
［氏名、役職、部署］

従業員への案内

件名：ローソンIDの情報漏えい―偽の連絡にご注意ください

ローソンは2026年10月8日、9月の不正アクセスにより、ローソンID 215万5,345件の氏名とメールアドレス、一部では電話番号や住所が漏えいしたと公表しました。
・ローソンは対象のお客様に lawson_id@mailservice.lawson.jp からメールを送っているとしています。それでも、この件に関するメッセージのリンクはクリックせず、ローソンのアプリやサイトを自分で開いてください。
・ローソン、ローソンID、Ponta、プレゼント、返金などを名乗る偽のメール、SMS、電話が予想されます。ローソンがメールや電話でパスワードを尋ねることはありません。
・会社のメールボックスに届いた場合は、［報告ボタンまたは報告先］で報告してください。同僚に転送しないでください。
・ローソンIDに会社のメールアドレスを登録している場合、本物の案内が会社に届くことがあります。その場合も、リンクではなくアプリで確認してください。
問い合わせ先：［セキュリティ担当］

経営層向け5行報告

1. 何が起きたか：2026年9月12〜14日、ローソンIDがアプリで本人の情報を表示するための仕組みを通じて不正アクセスを受け、215万5,345件の氏名とメールアドレス（入力があれば電話番号、住所）が漏えい。アプリ予約26件ではカード番号の一部が漏えい。10月7日に判明、8日に公表。
2. 当社にとっての意味：［当社／委託先］のアプリにも同じ種類の「本人の情報」を返すAPIがある。この種の欠陥はよくあり、2つのアカウントで試せる。
3. 当社の状況：個人情報を返すエンドポイント［数］、2アカウントのテスト［実施済み／日付に予定］、顧客数による警報［あり／なし］、アプリ内の秘密情報の確認［実施済み／予定］。
4. 実施中の対応：委託先への質問送付［日付］、スクレイピングのクエリの定期実行、ローソンを装うフィッシングへの注意喚起［日付］。
5. 判断が必要な事項：［例：アプリのリリース前に2アカウントのテストを必須にする、回数制限と顧客数による警報の導入、アプリからのバックエンドの鍵の削除］。次回報告：［時刻］。

まだ分かっていないこと

攻撃者がどうやって仕組みを突破したか。 認可の不備か、トークンの問題か、アプリから取り出された認証情報か。ローソンは明らかにしていません。
10月7日の調査のきっかけ。 不正アクセスから3週間後でした。
215万5,345件のうち、電話番号や住所を含む件数。 お知らせはこれらを「入力されている場合」としています。
パスワード、ポイントカード番号、決済情報、購買履歴に同じ仕組みで届いたか。 漏えいした情報としては挙げられていません。
リクエストが1つの送信元からか多数からか、 攻撃者が実在の顧客アカウントを使ったか。
データが売りに出されているか。

出典と更新履歴

2026年10月8日： 初版を公開しました。ローソンのお知らせと報道は、10月8日夜（日本時間）に確認しました。ローソンが原因やデータの詳細を公表した場合は、この分析を更新します。

2026年10月16日： 再利用可能なAPIデータ漏えい対応手順へのリンクを追加しました。事件の事実認定と不明点は変更していません。

30秒でわかる要点