Key takeaways

  • Japan's 2026 breach wave has hit app and membership systems again and again: Burger King Japan (11.18 million records), SourceNext (22.5 million), Yakiniku King (10.79 million), Lawson ID, 2rinkan, Mr Max, Seicomart and Aena among them.
  • Japan's responders now describe how this works: attackers take apart public apps to find and abuse the servers behind them.
  • The most reliable defense this year was not a security product. It was data that was not there: records deleted on schedule at infoQ, emails auto-deleted after 14 days at FutureShop, ID images that expired after a year at Snapmart.
  • The worst exposures came from data kept for years: Times Car's license images of former members and people who never finished signing up, and Yamato's purchase records back to 2018.
  • Internet-facing applications are being attacked far more than before, so anything a company publishes itself needs more security attention than it used to, and the data it collects and keeps should be the minimum needed for its purpose. Decisions to build those apps are usually made without the security team. In our view, three questions belong at the start of every app project in Japan: what data does it really need, how long will it be kept and who deletes it, and can the company defend the API behind it. If the last answer is no, using a third-party service instead, not shipping the app, or pausing it as the Japanese Red Cross did, are legitimate security decisions.

The pattern: apps and member systems#

Look at the large consumer breaches Japan has seen since late September, and a theme stands out. Many of them did not start with a corporate network. They started with an app, or the membership system behind one.

Organization What was hit Records
SourceNext (software) A member information API 22.5 million
Burger King Japan (restaurants) The system managing app members 11.18 million
Yakiniku King (restaurants) App member data, 99.8% of users 10.79 million
2rinkan (motorcycle supplies) The app's API 3.18 million
Lawson (convenience stores) Lawson ID, through a function meant to show app users their own data 2.16 million
Mr Max (discount stores) Software behind its app and online store 1.74 million
Aena (cosmetics) Member pages in its shopping app 817,000 people
Seicomart (convenience stores) The app's server 575,000

Most of these companies have not said exactly how the attackers got in. But Japan's responders have described the method. NICT named the A2B attack: download a company's public app, take it apart, find the APIs it calls and how, and attack those APIs directly. JPCERT/CC then found attackers' servers full of Android app files and reverse engineering tools.

An app is, among other things, a published map of its own backend. Every company that releases one gives attackers that map.

The data that was not there#

Against this kind of attack, many defenses failed. One that held, wherever it existed, was simple: the data was gone before the attackers arrived.

  • infoQ (GMO Research & AI): of the records the attackers took, 9,068 belonged to members who had left more than two months earlier. Their personal data had already been deleted under the company's privacy policy, so those records held none.
  • FutureShop: the mail servers for two of its email services were on IDCF Cloud. The data used to send emails was deleted automatically 14 days after sending, which capped what could have been exposed.
  • Snapmart: creators' identity document images were viewable without authentication for seven years because of a storage setting mistake. But each image was deleted automatically about a year after submission, so no image was exposed for longer than that.

None of these companies avoided an incident. But in each case, a deletion rule set long before decided how much was at stake.

The data that was kept#

The opposite cases are the most damaging of the year.

  • Times Car kept images of members' identity documents, such as driver's licenses, for as long as they were members and for seven years after they left. It also held data on people who never finished signing up. Images for about 1.6 million accounts were taken. A license image cannot be changed like a password.
  • Yamato Transport's pay-later service gave up about 5.26 million records going back to October 2018, including what customers bought.
  • skyticket stopped storing card data in 2018 and deleted what it held, but payment logs containing card numbers stayed on its server. Attackers took them this October: card numbers of up to 6,140 people, encrypted, with the key taken too. Many of those cards will have expired, which limits direct misuse, but the data should not have been there at all.
  • Burger King Japan held full names with readings, phone numbers and birth dates for 11 million app members. Ordering a burger needs very little of that.

On October 16, Times Car changed its rules: identity document images will now be deleted as soon as a member's registration has been checked, and every image it holds will be deleted by the end of October. The images, it turns out, were not needed to run the service. Japan's privacy law already asks businesses to make efforts to delete personal data without delay once it is no longer needed (Article 22). The Financial Services Agency has gone further for identity checks, telling banks to stop accepting uploaded ID photos ahead of the April 2027 deadline.

Our analysis#

The starting point: internet-facing applications are under attack#

Everything below rests on one change. Applications that companies publish on the internet, their websites, apps and the APIs behind them, are being attacked far more than before. Macnica, whose analysis JPCERT/CC cites, counted 119 breaches of Japanese web systems in 2026 up to October 6, 81 of them since July. JPCERT/CC and NICT describe attackers working through targets systematically, and JPCERT/CC says they are using AI tools to do it.

In our view, that means any company that publishes its own application now has to give it more security attention than it would have needed even a year ago: design, testing, monitoring and a plan for what to switch off. Companies that cannot do that should ask whether they need to run the application themselves at all.

And whatever they decide, one principle does not change: the personal data a company collects and keeps should be the minimum needed for its purpose. Every field beyond that is risk with no return.

Japan has too many apps#

In our view, Japan has an unusually large number of store-by-store membership and points apps. A restaurant chain, a convenience store, a discount store and a car-supplies retailer each runs its own, each with its own member database and its own API on the internet. For the customer, that means the same name, phone number and birth date copied into dozens of systems. For attackers, it means dozens of targets, many built and run by companies whose main business is not software.

Every one of those APIs now has to withstand attackers who analyze apps systematically and, according to JPCERT/CC, use AI tools to do it. Not every company that wants an app can defend one at that level.

Not shipping is a security decision#

The usual advice after a breach is to add controls: rate limits, monitoring, server-side authorization. All of that is right, and our coverage of NICT's and JPCERT/CC's findings lists it. But there is an earlier decision that security teams rarely get to make: whether the app, the feature or the data field should exist at all.

In our experience, decisions to launch an app in Japanese companies are made almost entirely without the security team. Business, marketing or sales decide that customers should have an app, a vendor builds it, and security is asked, if at all, to test it shortly before release. By then, what data it collects, how long it keeps it and which APIs it exposes have all been settled. The questions that matter most were never put to the people best placed to answer them.

On October 16, the Japanese Red Cross Society made that decision in reverse. After NICT's warning, it took its blood donor app offline as a precaution to recheck its safety, while keeping a browser version running. No attack had been found. In our view, it is the clearest example this year of treating "do not run it" as a legitimate security control, rather than a failure.

Why "enough security" stops short#

In our view, there is an uncomfortable reason why these breaches keep happening. For most companies, a data breach is not a business-threatening event in the way ransomware is. Ransomware stops shipping, sales and production; a data breach usually does not. The costs are real but bounded: an investigation, notices, a call center, perhaps a voucher. Japan's privacy law has no general administrative fines today, and the 2026 amendment adds them only for narrow cases, from around 2028, while plans for consumer-group lawsuits were dropped. The harm, phishing, fraud and identity misuse, falls mostly on customers, not on the company.

So security budgets for customer data tend to stop at "enough", and in practice there is a limit to how far companies will strengthen them. That is exactly why minimization matters. Deleting data that is no longer needed, and not collecting it in the first place, costs far less than defending it, and it caps the harm however well or badly the defenses hold.

Three questions before the next app#

We would put three questions in front of anyone planning an app or a membership system in Japan, and we would want the security team in the room when they are answered:

  1. What data does it really need? The minimum for the purpose, and nothing more. Not what marketing might use one day. A birthday coupon does not need a full date of birth, and ordering food does not need a name reading.
  2. How long is it kept, and what deletes it? A retention period that depends on someone remembering to run a script is not a retention period. infoQ, FutureShop and Snapmart show what automatic deletion is worth.
  3. Can we defend the API behind it? Assume the app will be decompiled. If the company cannot test, monitor and fix its API at the pace attackers now work, the safest version of the app is the one that is not published.

If the answer to the third question is no, there is a middle path between building an app and doing nothing: using a third party's service to reach the same goal. A shared points program, a messaging platform's official account, or an established ordering, booking or payment platform can deliver coupons, orders or reservations without the company running its own member database and API. The data still exists, but it sits with a provider whose business is running that system and who can, in principle, defend it at a scale a restaurant chain cannot.

Using a third party moves the job of defending against attacks from the internet to the vendor. It does not remove the risk; it turns it into supply chain risk, which grows with every provider a company depends on. This year shows what that looks like. ShopServe exposed data from 7,858 shops at once, and Arcadia's disaster alert service took hundreds of municipalities with it. A shared platform concentrates risk as well as expertise, and when it is breached, its customers learn about it from the vendor, often late. Legally, the responsibility does not move either: under Japan's privacy law, a company that entrusts personal data to a contractor must supervise how that contractor protects it (Article 25). The choice is worth making deliberately: what the provider holds, how it is protected, how quickly it will tell you about an incident, and what happens to your customers if it is breached. For many companies, that is still a better position than running an app they cannot defend.

What "don't keep" does not mean#

Some records must be kept. Tax law requires transaction records to be retained, and some businesses have legal identity verification and record-keeping duties. Times Car itself cited a seven-year tax duty for former members' basic details. But a duty to keep a record of a transaction is not a reason to keep an image of an identity document, or to keep it in a system reachable from the internet. Separating what the law requires from what is merely convenient, and storing the former out of reach, is most of the work.

Whose job is it?#

On October 6, Digital Minister Toshiharu Furukawa, responding to the run of breaches, asked the public to take three steps, starting with not reusing passwords, and to keep in mind that "you protect your own information". The remark was widely read as shifting responsibility from companies and government onto individuals, and drew a backlash.

In our view, both halves are true, but the order matters. Almost every breach this year came from weaknesses on the company's side, which no customer could have prevented or even seen. That is where responsibility starts. But individuals do have one lever that matters: a reused password turns one company's breach into break-ins at many others, which is why SourceNext warned that stolen email and password combinations may be tried elsewhere. Asking people to stop reusing passwords is reasonable. Asking them to protect their own information, while companies keep collecting and holding more of it than they need, puts the burden in the wrong place first.

What this means for readers#

  • If you are in a security team, ask to be involved when the business decides to build an app or collect new data, not only when it is ready for testing.
  • If you own a consumer app or member system, list every personal data field it stores and the reason for each. Remove fields nobody can justify.
  • Set automatic deletion for data that has a natural end: identity document images after verification, sending logs after delivery, accounts after cancellation.
  • Check where else the data is written: logs, backups, exports and test copies often keep personal data, and even card numbers or passwords, long after the main database has stopped holding them. skyticket's card numbers survived for eight years in payment logs.
  • Separate legally required records from operational systems, and keep them where an app or API cannot reach them.
  • Decompile your own app, as attackers will, and fix what you find on the server side.
  • Before building your own app, ask whether a third-party service can do the job, and treat the provider as a supply chain risk: check how it protects the data it would hold for you and how it will notify you of an incident.
  • Treat pausing or retiring an app as an option in your incident and risk planning, as the Red Cross did, not only as a last resort.
  • As an individual, think twice before registering your details, and especially an ID image, with a store's app. Fewer copies of your data mean fewer breaches that include you.

Japanese terms at a glance#

Japanese Reading Meaning
本人確認書類 honnin kakunin shorui Identity document
保有期間 hoyū kikan Retention period
自動削除 jidō sakujo Automatic deletion
遅滞なく消去するよう努めなければならない chitai naku shōkyo suru yō tsutomenakereba naranai Must endeavor to delete without delay (APPI Art. 22)
会員アプリ kaiin apuri Membership app
データ最小化 dēta saishōka Data minimization