Lawson ID: 2.15 million accounts leaked through the app's own “show me my data” mechanism.

This was not a stolen database or a ransomware attack. By Lawson's account, the data came out through the part of the app that exists to show each customer their own details. That makes it an API design question for every company with a customer app, and a phishing problem for everyone else: 2.15 million names and email addresses tied to a brand that almost everyone in Japan uses.

At a glance. Original graphic for this article.

What Lawson has disclosed

On 8 October 2026, Lawson published a notice about unauthorized access to two of its services. Lawson notice (Japanese)

Lawson ID is the account service used to sign in to Lawson's app and web services. It was accessed between 12 and 14 September (Saturday to Monday).
Lawson App Reservation lets customers pre-order and pay for seasonal items in the official app. It was accessed on 17 September.
Discovery. Lawson found both during an investigation it carried out on 7 October. It says it has confirmed there was no other unauthorized access and no malware infection.
Cause, as stated. A system connected to the Lawson app was misused. The security mechanism that is meant to show information in the app to the account holder was accessed by a third party, and data leaked through it.
Response. Lawson blocked the suspicious sources, stopped the pre-order feature, posted a notice in the app, reported to the Personal Information Protection Commission and other bodies, and is emailing affected customers individually. Pre-orders are due to restart in mid-October.
Misuse. No fraudulent use or other secondary harm has been confirmed.

Service	People	Data that leaked
Lawson ID	2,155,345	Email address and name; also sex, phone number, address and newsletter preferences where the customer had entered them, for example to apply for a prize
Lawson App Reservation	26	Name, phone number and part of the credit card number

The notice uses the word "leaked" (漏えい), not "may have leaked". Passwords, Ponta or d POINT card numbers and purchase history are not on the list. Lawson does not say they were safe; it lists what it confirmed.

Figure 1. The disclosure timeline. Original graphic for this article.

The same evening, the karaoke operator Daiichikosho said data on about 8.72 million customers may have leaked after malware infected a device used by an employee of one of its contractors. Kyodo via Sanspo (Japanese)

What "a mechanism for showing users their own data" points to

Lawson has not described the flaw. Its wording still narrows the possibilities. The leak came through an app-facing function whose job is to return the signed-in customer's own record. When such a function hands out other people's records, there are three common explanations:

Broken object-level authorization. The server returns whichever customer record the request names, instead of checking that the record belongs to the caller. An attacker changes the ID and loops. This is the first risk in the OWASP API Security Top 10. OWASP API1:2023
Weak session or token handling. The server trusts a token it should not: one that can be forged, guessed, replayed or obtained for any account.
A credential taken from the app. A key or secret built into the app lets anyone who extracts it call a back-end service directly, without being a customer at all. "A system related to the app was misused" fits this reading too.

Whichever it was, two facts make the case useful for every app owner:

Volume did not stand out, or did not raise an alarm. 2,155,345 records in three days is about 30,000 an hour if spread evenly, or eight a second. Lawson's app has passed 40 million downloads, so a profile endpoint may serve that much legitimate traffic. Lawson: app passes 40 million downloads (Japanese) The signal that does stand out is how many different customers one caller reads: a real user reads one.
23 days passed before anyone noticed. Lawson disclosed the day after it found the access, which is fast. By comparison, H.I.S. took 300 days to get from an alert to a public notice. H.I.S.: 300 days from alert to notice The gap at Lawson was in detection, not in disclosure.

The data returned also matters. The function that leaked addresses and phone numbers was one that shows customers their own profile. Screens that show only a name and a membership number do not need the API behind them to return a home address. Returning only the fields a screen displays limits what any flaw can leak. OWASP API3:2023

Why this data matters

Names with email addresses are enough for convincing phishing. "Your Lawson ID was affected: confirm your details here" is a credible message to 2.15 million people this week, and Lawson really is emailing them.
Phone numbers and addresses widen the channels. Where customers entered them, SMS and phone calls become possible, and a home address makes a pretext feel official.
Part of a card number is a script. For the 26 pre-order customers, a caller who can say "your card ending in …" sounds like the card company. Twenty-six is small, but the technique works at any scale.
The brand covers many services. A lure can name the app, point cards, payments or tickets; Lawson already warns customers about fake emails in the name of Lawson Ticket. Lawson FAQ (Japanese)
Work addresses are in the data too. Prize applications and newsletters are often signed up with work email addresses. Some of the genuine notices, and the fakes, will land in corporate mailboxes.

The attacker's playbook: what this case enables

No attacker has been named, and the route has not been disclosed beyond the wording above. This is how a red team would approach a consumer app API, mapped to MITRE ATT&CK.

Step	What it would look like here	ATT&CK
Map the app	Run the app through an intercepting proxy on a test phone; find the call that returns the signed-in member's profile and any keys the app carries	T1595 Active Scanning
Get past the check	Not disclosed. Change the member ID in the request, reuse or forge a token, or call the back end with a key taken from the app	T1190 Exploit Public-Facing Application; T1078 Valid Accounts
Collect	Script the call and store the responses; 2.15 million records over a weekend and a Monday	T1119 Automated Collection
Second target	The same approach against the pre-order service three days later: 26 records with part of a card number	T1190 Exploit Public-Facing Application
Use the data	Email, SMS and phone lures in Lawson's name; "your card ending in …" calls; sale of the list	T1566 Phishing; T1656 Impersonation; T1598 Phishing for Information

Two points shape the defence. For app owners, the flaw class is common and can be tested with two ordinary accounts. For everyone else, the main risk is the lure that arrives next week, not this week's breach.

The defender's playbook

Put this into practice: use the API data exposure playbook for containment, object and field checks, record-level scoping and verified reopening. Lawson's disclosed mechanism does not establish a specific authorization flaw; the guide covers the possible response branches.

1. If you run a customer app: test the calls that return "my" data

Derive the customer from the session, never from the request. Every endpoint that returns personal data should look up the record from the authenticated session or token, and refuse when the owner of the requested record is not the caller.
Test with two accounts. Sign in as customer A and request customer B's profile, orders and addresses by changing IDs. Repeat for every app version still in use, and include the app's API in every penetration test.
Keep secrets out of the app. Anything shipped in the app binary can be extracted. Back-end keys that bypass customer authentication should not exist in the app.
Return only what the screen shows. If a screen needs a name, the API should not return an address and phone number as well.
Limit and log. Rate-limit profile calls per token, account and address. Log the record ID served and the caller, so scoping takes hours. OWASP API4:2023
Check your vendors. Apps are often built and run by agencies. Send them the questions below. The customer account takeover playbook covers the related risk of attackers signing in as customers.

2. Detect scraping in hours, not weeks

Alert on distinct records per caller. A real customer reads one profile. Alert when one address, token or account reads more than a handful in an hour.
Watch for many accounts from one source. If the attacker signs in with many accounts, count distinct accounts per address or device instead.
Watch response size and new clients. Sudden growth in bytes returned by profile calls, unknown app versions or user agents, and traffic from hosting providers are cheap second signals.
Run the hunting queries below on your own API logs. At Lawson's scale, a distinct-records alert would have fired in the first hour, not after 23 days.

3. Prepare staff and customers for Lawson-themed phishing

Give one rule: Lawson's notices come from lawson_id@mailservice.lawson.jp, according to its notice. Even so, do not act on links in messages; open the app or type the address.
Watch inbound mail and DNS for Lawson, Lawson ID and Ponta names from unofficial domains (queries below), and block confirmed lookalike domains.
Brief call centres and HR: staff may receive calls quoting their name, address or part of a card number. Verification goes through numbers on the card or the official site, never through the caller.
The phishing response playbook covers clean-up if someone clicks.

4. Which teams should act

Team	Exposure to review	Next step	Evidence needed
App owners and IT Operations	Customer app APIs that return personal data	Run the two-account test; check for secrets in the app; add rate limits	Test results per endpoint, fixes with dates
SIEM / SOC	API gateway and web logs	Schedule the scraping queries; alert on distinct records per caller	Query schedule, alert routing, thresholds
Email Security	Lawson-, Lawson ID- and Ponta-themed mail	Run the mail query; block confirmed lookalikes with a review date	Message list, recipients, click records
Legal / Privacy	Fields each API returns; reporting readiness	Confirm data minimisation and that logs can scope a leak	Field inventory per endpoint, log retention
Third-party Risk	Agencies that build or run your apps	Send the vendor questions below	Written answers, last test report
HR and call centres	Staff and customers receiving calls or SMS	Brief with the verification rule	Briefing record, report log

Hunting: is the lure arriving, and could your app leak the same way?

No indicators have been published. Lawson has not released attacker addresses, tools or request patterns. The first query looks for Lawson-themed mail from unofficial domains. The others look for the scraping pattern in your own API logs.

All queries are illustrative and were not run against live data. Table and field names were checked against vendor documentation on 8 October 2026 (JST). Expect noise: genuine Lawson notices, news and newsletters will match the mail query; mobile carriers' shared addresses can inflate per-address counts.

1. Inbound mail naming Lawson, Lawson ID or Ponta from other domains. Microsoft Defender XDR advanced hunting; needs 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. Your own API: one caller reading many customer records. Azure Monitor, Azure API Management gateway logs in resource-specific mode. If your profile endpoint takes no ID (for example /me), the DistinctUsers and Requests conditions still apply.

// 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. The same check in Splunk for web or API gateway logs with CIM-style fields (uri_path, status, user, src). Replace the index, sourcetype and profile path.

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

Download the examples: mail KQL · API KQL · API SPL.

Other platforms. Sumo Logic, DNS or proxy logs: company devices reaching domains that resemble Lawson or Ponta. Lines containing the official domains are excluded, which also hides lookalikes such as lawson.jp.example.net, so review those separately.

_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

In CrowdStrike Falcon (LogScale / Next-Gen SIEM), DNS requests from endpoints:

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

No result does not prove nothing happened: mail to personal addresses and SMS are invisible to company tools, and API logs that do not record the object served cannot show scraping. EmailEvents · ApiManagementGatewayLogs

Copy-paste templates

Replace everything in [square brackets]. Have Legal or Privacy review anything that leaves the company.

Questions for the team or vendor that runs your customer app

Subject: [Company] – customer app API checks following the Lawson ID incident

Dear [contact],
Following Lawson's 8 October 2026 notice that customer data leaked through the mechanism its app uses to show customers their own information, please answer the following in writing by [date].
1. Which API endpoints return customer personal data (profile, address, phone, orders, payment details), and what fields does each return?
2. For each, how does the server decide which customer's record to return: from the authenticated session or token, or from an ID in the request?
3. Has each been tested by signing in as one customer and requesting another customer's data? When, by whom, and with what result?
4. Does the app contain any API key, client secret or credential that can call back-end services without a customer signing in?
5. What rate limits apply per token, per account and per IP address to profile and order endpoints?
6. Do logs record, for each request, the caller and the customer record returned? How long are they kept?
7. Is there an alert when one caller reads many different customers' records? What threshold, and who receives it out of hours?
8. Which older app versions still call these endpoints, and do they use the same checks?
9. When was the last penetration test that included the app's API, and are all high-risk findings fixed?
10. Within how many hours would you notify us of suspected unauthorized access, and through which verified channel?
Kind regards,
[Name, title, department]

Note to employees

Subject: Lawson ID data leak – watch for fake messages

Lawson announced on 8 October 2026 that names and email addresses, and in some cases phone numbers and addresses, of 2,155,345 Lawson ID accounts leaked after unauthorized access in September.
- Lawson says it is emailing affected customers from lawson_id@mailservice.lawson.jp. Even so, do not click links in messages about this; open the Lawson app or website yourself.
- Expect fake emails, SMS and calls about Lawson, Lawson ID, Ponta, prizes or refunds. Lawson will not ask you for your password by email or phone.
- If a message reaches your work mailbox, report it with [report button or address]. Do not forward it to colleagues.
- If you entered a work email address in Lawson ID, you may receive the genuine notice at work. It is still safe to check it in the app rather than through the link.
Questions: [security contact].

Five-line briefing for management

1. What happened: Lawson ID was accessed on 12–14 Sep 2026 through the mechanism its app uses to show customers their own data; 2,155,345 accounts' names and emails (plus phone and address where entered) leaked; 26 app pre-orders exposed part of a card number. Found 7 Oct, disclosed 8 Oct.
2. Why it matters to us: [our app / our vendor's app] has the same kind of "my data" API. The flaw class is common and testable with two accounts.
3. Our exposure: [number] endpoints return personal data; two-account test [done / scheduled for date]; distinct-records alert [in place / not in place]; app secrets review [done / planned].
4. Actions under way: vendor questions sent [date]; scraping queries scheduled; staff warning on Lawson-themed phishing issued [date].
5. Decisions needed: [e.g. require two-account testing before each app release; add rate limits and distinct-records alerting; remove back-end keys from the app]. Next update: [time].

What remains unknown

How the attacker got past the mechanism: an authorization flaw, a token problem or a credential taken from the app. Lawson has not said.
What prompted the 7 October investigation, three weeks after the access.
How many of the 2,155,345 records include phone numbers or addresses. The notice lists those fields only "where entered".
Whether passwords, point-card numbers, payment data or purchase history were reachable through the same mechanism. They are not listed as leaked.
Whether one source or many made the requests, and whether the attacker used real customer accounts.
Whether the data has been offered for sale.

Sources and updates

8 October 2026: first published. Lawson's notice and news coverage were checked on the evening of 8 October (JST). We will update this analysis if Lawson discloses the cause or more detail on the data.

16 October 2026: added a link to the reusable API data exposure response guide; the incident's factual findings and uncertainties are unchanged.

30-second briefing