access control
20 articles with this tag
Toypo App Unauthorized Access (697,209 Users Affected, per Toypo): Phone Numbers, Names and Addresses Leaked, and What Store App Users Should Do
Toypo Inc. confirmed unauthorized access by a third party to its customer-management app, the Toypo app, on October 4, 2026, and said in a notice dated October 14 that 697,209 users are covered and that their information may have leaked. A second Toypo notice page, which has no date and no number of people, says the information leaked. Since October 13 the company has been contacting those covered one by one, including by in-app push notification. According to the company, part of its system had an access-control flaw that let an authenticated user obtain other users' information they were not entitled to see, and its logs show a third party used it to obtain user information. The flaw has been fixed. The information that may have leaked is the phone number and user ID or similar identifiers and, where registered, name, name in kana, email address, date of birth, gender and address. Passwords and other login credentials, credit card numbers and other payment data, points, store-visit history and purchase or usage history are not included, it says, and users do not need to change passwords or take other action in the app. No specific secondary harm has been confirmed. It has reported to the Personal Information Protection Commission. A third-party security assessment is being arranged. In notices by stores that use the app, JR Kyushu Food Service says about 26,900 of about 61,500 registered members are covered, and Mannoya says 12 of 212 members of its Kineya Mannoya official app. Toypo's contact is 0120-546-030 (weekdays 9:00 to 18:00 Japan time; the call center takes calls until 18:00 on October 30, then the in-app contact). This site's conclusion: a message that gets your phone number and name right is not necessarily genuine. Do not use its links or numbers; check through the in-app contact or the contact listed in the notice.
Unauthorized Access to Commune (166,505 Member Records, Counted per Community): Member Data from Corporate Communities Leaked — What Members and Operators Should Do
On October 9, 2026, Commune Inc. announced that its community services for businesses, Commune and Commune for Work, were accessed without authorization by an outside third party, and that member data in some communities leaked. The leaks occurred from about 18:00 on October 5 to about 21:00 on October 6, and from 13:17 to 14:36 on October 7 (Japan time). Its first notice gave about 307,000 members (an estimate of unique people) as the maximum possibly affected. In a follow-up on October 21, after a detailed investigation, it confirmed that 166,505 members were affected (the total of member IDs counted per community, so people in several communities are counted once for each; this includes communities run by the company and test/demo communities, and excludes accounts created by the attacker), and that 125,601 of them had data including email addresses leaked. For the others, the leaked data includes display names, profiles and private group memberships. For 144 members, passwords were changed to temporary ones without their action. No leak of the passwords themselves or of direct messages was confirmed, and the company does not hold payment data. It attributes the incident to invitation links for private communities obtained illegitimately and to impersonation of administrators. Client companies that run communities on the service have also published notices; JMAM said the names, addresses, ages and phone numbers in member profiles on its Toki Labo community also leaked. To prevent misuse of the leaked email addresses, Commune Inc. stopped all communities for emergency maintenance from 00:50 on October 10 and took measures such as making two-factor authentication mandatory for administrator accounts. On October 16 it announced that communities would reopen in stages, starting with clients that ask, in the web browser version only and with some features restricted (the app, new registration with an email address and “forgot password” resets remain unavailable). It says no new unauthorized access or leak was found during the maintenance or testing. The October 21 follow-up also says the company filed a preliminary report with the Ministry of Internal Affairs and Communications (Kanto Bureau of Telecommunications) on October 9, has begun consulting the police, found no programs, accounts or settings left behind by the attacker after analysing all logs, and is preparing a forensic investigation by a third-party organisation. This site's take: check the notice of the company that runs your community to see whether you are affected, and do not open links in emails that claim to come from the community.
Japan's October 2026 warnings on unauthorized access (National Cybersecurity Office, IPA, JPCERT/CC): what to check this week, and what to do if you find something
In September and October 2026, organizations in Japan disclosed one data breach from unauthorized access after another. On 9 October the Cabinet Secretariat's National Cybersecurity Office and IPA issued warnings, following JPCERT/CC's alert of 8 October. IPA says the attacks have not been tied to a single product's vulnerability and appear to start from compromised internet-facing apps and services or accounts. This week: (1) list your internet-facing apps and review their logs for the last month, then three months; (2) check cloud, VPN and other external services for failed sign-ins, unfamiliar source addresses and accounts you don't recognise; (3) re-inventory the personal data you hold and minimise it. If anything looks wrong, declare an incident, preserve logs, bring in specialists and report to the Personal Information Protection Commission. This site's view: discovering that you only keep one month of logs is itself a finding to act on.
Unauthorized Access to Lawson ID (2,155,345 Records): Email Addresses and Names Leaked — What Members and App Reservation Users Should Do
On October 8, 2026, Lawson, Inc. announced that unauthorized third-party access to its account service Lawson ID, and to Lawson App Reservation (a service for reserving and paying for seasonal event products in the app), had leaked personal data. An investigation on October 7 found that Lawson ID was accessed without authorization from September 12 to 14 and App Reservation on September 17. The company confirmed leaks of 2,155,345 Lawson ID records (email address and name, plus gender, phone number, address and newsletter preference where these had been entered, for example when applying for a giveaway with Lawson ID) and 26 App Reservation records (name, phone number and part of the credit card number). The company says a system related to the Lawson app was misused, and that a security mechanism meant to show information to the user themselves in the app was accessed without authorization by a third party. Passwords are not among the listed items. As of October 8 no misuse or secondary harm had been confirmed, and on October 13 it added lawson_id@id.lawson.jp as a sender address for the individual notification emails. This site's take: Lawson ID holders should not open links in emails or texts claiming to be Lawson or offering points or coupons, and should check through the official app they open themselves.
NewsPicks Data Breach (Card Holder Names and Last Digits, up to 362,000 Records): What Leaked Through an Internal Admin Tool and What Users Should Do
On October 8, 2026, Uzabase, Inc. announced that an admin tool used in the operation of its news service NewsPicks had been accessed without authorization by a third party, and that some users' personal data may have leaked. Its second notice on October 9 said the intrusion exploited a vulnerability in that admin tool, and gave maximum estimated counts per item: part of the card data used for web payments (card holder name and the last 3 or 4 digits of the card number, etc.) 362,000; email addresses 323,000; job-level category 273,000; affiliation 65,000; names 59,000; and others. The company says full card numbers and security codes were never stored on its systems and did not leak, and that no password leak has been confirmed. No secondary damage has been confirmed. This site's take: a message that quotes your card's last digits or your employer is not proof that it is genuine. Do not open links, check through the official app or a site you open yourself, and keep an eye on your card statements.
skyticket (Adventure Inc.) Data Breach (About 14.64 Million Records): Passwords, Refund Bank Details and Some Users' Card Data Exposed — What Users Should Do Today
On October 9, 2026, Adventure Inc. announced three separate incidents of unauthorized access, each by a different route, affecting its travel comparison and booking site skyticket. In the first, an administrative function was misused and used as a starting point to reach other servers and data stored in the cloud; about 14.64 million records leaked, including names (also as written in passports), dates of birth, email addresses, phone numbers, addresses and the remitter name used for bank transfers, and about 4.13 million of them included hashed member passwords. In the second, a vulnerability in a business management system was exploited, and 17,780 records (including duplicates, with more still being counted) containing refund bank account details leaked or may have leaked. In the third, a bus booking completion page could be displayed without logging in, and about 12,000 bookings were or may have been viewed. The company first said card numbers were not among the leaked data, but corrected this in a second notice on October 16: the card number, cardholder name and expiry date (for some, the number only; no security codes) of up to 6,140 people who registered or used a credit card to pay the "skyticket Premium" membership fee between February 2017 and June 2018 leaked in the first incident, along with member IDs, names and passwords for a welfare benefits service offered as a Premium perk. Passport images were not exposed, and as of the October 9 notice the only confirmed secondary harm was one unauthorized login to a member account (the second notice does not say whether the leaked card data has been misused). This site's take: members should change their password from the official site or app today, change it anywhere it was reused, check card statements from October onward if they registered or used a card for the Premium fee in that period, ignore messages about refunds, compensation or booking changes, and never give anyone a bank PIN or one-time code.
Japan e-Tax Gift Tax Data Exposure (2026): Who Is Affected
On October 2, 2026, Japan's National Tax Agency (NTA) announced that gift tax returns and related documents of 79 people could be viewed by other users in MyPage on e-Tax, the national online tax filing and payment system. According to reports, this lasted from 8:30 on September 24 to midnight, and from 4:00 to 15:58 on September 25. Nineteen users may actually have viewed someone else's return, and personal information of 203 people in total — filers plus the donors and tax accountants named in the returns — may have been seen. The cause was a defect introduced by a September 24 update that expanded MyPage's gift tax information feature; it has been fixed. NTA regional bureau and tax office staff contacted affected people individually, and the 19 viewers were asked to keep the information confidential and delete it. No sign of saving or secondary harm has been found. The NTA says this is unrelated to problems with its new core system (KSK2). This site's take: affected people are being contacted by the tax office. For any call or text that uses this incident as a reason, follow the NTA's advice: hang up and call back on a tax office number you look up yourself. Developers should test, on every change, that requesting user B's data while logged in as user A is refused.
Companies House WebFiling Flaw (2026): Exposed Data and Checks
On March 13, 2026, UK Companies House became aware of an issue that meant a logged-in registered user of its WebFiling service could potentially view and change another company's details after a specific set of actions. It closed WebFiling at 1:30pm that day and reopened it at 9am on March 16. According to Companies House, the cause was a defect introduced during a major system update on October 11, 2025, and it was not a cyber-attack. Data that may have been visible includes the day of the date of birth and residential addresses of directors and people with significant control (PSCs), and company registered email addresses; unauthorised filings such as new accounts or changes of director were also technically possible. Passwords, identity verification data and existing filed documents were not affected. An April 8 update said a very small number of instances of unauthorised access or attempted changes had been identified. This was an authorization failure, not an intrusion. The login check worked; the check on whether this user may handle this company did not. Directors should review their filing history and turn on Follow alerts; developers should test, on every release, that requesting someone else's data is refused.
Cloud storage public exposure: when data can leak even with Block Public Access enabled
Bucket leaks come from configuration, not attack. The line that matters in the docs: block public access settings do not alter existing policies or ACLs — the public settings remain underneath the block, and removing the block restores public access. So the goal is not "blocking is enabled" but "nothing is public even with blocking off". Apply it at the account level, because a bucket policy can grant someone the ability to turn a bucket-level block off. And "public" is defined more broadly than people assume.
File upload vulnerabilities — preventing web shells and RCE by design
The problem with an upload vulnerability isn't 'receiving a file' — it's where you put it and whether it can execute. Unauthenticated endpoint + no type validation + stored under the web root + scripts run there = web shell → RCE. Defend in layers: (1) auth/permission + CSRF on the endpoint, (2) server-side allow-list + content inspection, (3) store outside the web root (or disable execution), (4) randomize names, never trust user paths. Don't rely on one control; have something that can stop the attack at every step.
What is the OWASP Top 10: the standard list of the 10 biggest web-app risks
The OWASP Top 10 is a list the non-profit OWASP publishes every few years of the 'most critical web-app risks.' It's a common language for developers and operators. The current 2025 edition (announced November 2025) is still led by Broken Access Control; Security Misconfiguration rose to second, and two new categories were added: Software Supply Chain Failures and Mishandling of Exceptional Conditions. SSRF was merged into Broken Access Control. These are risk CATEGORIES, not individual exploits, so use them as a lens to audit your own app.
What is PCI DSS: the security standard for handling credit-card data
PCI DSS (Payment Card Industry Data Security Standard) is the international standard for businesses that store, process, or transmit card data. Set by the card brands, it requires network protection, encryption of stored data, least-privilege access control, monitoring/logging, and vulnerability management. In practice the safest move is to not hold card numbers yourself — hand processing to a compliant payment provider (tokenization) and shrink your scope.
ASP.NET Core security — a production hardening reference
ASP.NET Core is a mature, stable framework, but incidents come from settings. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — don't expose detailed errors / the Developer Exception Page in production, externalize secrets (User Secrets/env/Key Vault), NuGet dependency CVEs, authorization ([Authorize], fallback default-deny, resource-based/owner), over-posting (DTOs/[Bind]), unsafe deserialization (avoid BinaryFormatter), HTTPS/headers/antiforgery, SSRF, and (3) a self-verification checklist. Defensive only — no attack steps.
Django security — a production hardening reference
Django ships many safe defaults (ORM, CSRF, auto-escaping, auth), but incidents come from settings. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — DEBUG=False + ALLOWED_HOSTS, externalizing SECRET_KEY, pip dependency CVEs, production security settings (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), authorization (owner scope), injection and output (raw/extra, mark_safe), CSRF/sessions/admin, SSRF/uploads, and (3) a self-verification checklist. Defensive only — no attack steps.
Express (Node.js) security — a production hardening reference
Express is minimalist — it guards almost nothing by default, so you add the defenses. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — security headers (helmet) + disabling x-powered-by, npm dependency CVEs, input validation and injection (SQL/NoSQL operator), authentication and owner-scoped authorization, rate limiting and size caps, sessions/cookies/CSRF, SSRF, production error handling (no stack exposure), NODE_ENV, and (3) a self-verification checklist. Defensive only — no attack steps.
Laravel security — a production hardening reference
Laravel's defaults are strong; production incidents come from config and operations. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) a table of dangerous defaults, (3) per-area guidance — secrets/APP_KEY, production config (APP_DEBUG/caching), authorization (Policy/Gate, Mass Assignment), injection/output (Eloquent binding, Blade), sessions/CSRF/cookies, uploads, HTTPS/headers/rate limiting, Composer dependency CVEs, and (4) a self-verification checklist. Defensive only — no attack steps.
Next.js security — a production hardening reference
Next.js's defaults are fairly safe, but incidents happen at the server/client boundary. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — the boundary and env vars (NEXT_PUBLIC_), dependency CVEs (including core RCE), Server Actions / Route Handlers authorization + input validation, SSRF on server-side fetches, security headers/CSP, auth/session/cookies, rate limiting, and (3) a self-verification checklist. Defensive only — no attack steps.
Ruby on Rails security — a production hardening reference
Rails ships conventions and safe defaults (CSRF protection, Strong Parameters, an ORM), but production incidents come from operations. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — secrets and credentials (master key/secret_key_base), production config (force_ssl, no exception exposure), gem CVEs, Strong Parameters/Mass Assignment, authorization (Pundit, owner scope), injection and dangerous methods (where interpolation/send/constantize), sessions/cookies/CSRF, SSRF/uploads, and (3) a self-verification checklist. Defensive only — no attack steps.
Authentication vs authorization: a login alone doesn't protect other users' data
Authentication = verifying who someone is; authorization = deciding what they may do. They're different, and adding a login is not authorization. Without owner (user_id) scoping on data, 'logged in = sees all data' — the top-ranked OWASP Broken Access Control. Add a scaffold with registration left open and a stranger can sign up and get in. Defenses: scope every query to the owner, close unneeded registration, defense-in-depth, audit/access logs before an incident, detect new sign-ups.
What is IDOR: a flaw that exposes other people's data when an ID is changed
IDOR lets a user change ?id=124 to 125 and read someone else's invoice or personal data — broken access control. The main defense: server-side, check on every access whether the logged-in user is allowed this object. Hard-to-guess IDs are not a fix.