---
title: "タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか"
url: "https://www.issoh.co.jp/tech/details/15978/"
published: 2026-07-31
updated: 2026-10-02
categories: ["脆弱性・インシデント"]
publisher: "株式会社一創"
---

# タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか

タカラトミーは2026年7月28日、スマートフォンアプリ「デュエル・マスターズ サポートアプリ」のユーザー認証機能に脆弱性があり、特定の条件下で第三者が他の利用者の登録情報を閲覧できる状態だったと[公表](https://dm.takaratomy.co.jp/img/notice20260728.pdf)しました。対象は最大約15万5000人。公表文が原因として挙げたのは「開発段階においてユーザー認証機能の設計・実装に脆弱性があったこと」の一文だけで、どの層の欠陥だったのかは2026年10月2日時点でも明らかにされていません。開発や情報システムの現場が知りたいのは、この一行が実装のどこの抜けを指しうるのかという点です。

本記事では、公表された事実を整理したうえで、公表文から考えられる2つの型（トークン検証などの認証そのものの欠陥と、APIのオブジェクトレベル認可の抜け＝IDOR／BOLA）がどう再現されるのか、どの層で確認を置けば防げるのか、認可の抜けを回帰テストと脆弱性診断でどう捕まえるのかを実装の解像度で扱い、個人情報保護法の報告義務までを判断材料としてまとめます。

## まとめ：デュエマアプリ情報漏えい事案の要点と実装で取るべき手

- **事案**：2026年7月28日公表。デュエル・マスターズ サポートアプリのユーザー認証機能に設計・実装の不備があり、特定条件下で第三者が他人の登録情報を閲覧できる状態だった。
- **規模**：対象は2025年8月1日のサービス開始から改修完了の2026年7月13日までに登録した最大約15万5000人。氏名・住所・電話番号など9項目が対象。
- **技術的な本質（推定）**：同社は脆弱性の型を公表していません。「ユーザー認証機能」の不備で他人の登録情報が見える状態は、認可（その人がそのデータを見てよいか）の確認漏れ＝IDOR／BOLAか、トークン検証の欠落などの認証欠陥のどちらかで起きるのが典型です。本記事はこの2つを公表文からの推定として扱います。
- **防ぎ方の核心**：所有者チェックをデータ取得と同じ層へ寄せ、識別子の推測困難化だけで済ませない。`findById`ではなく`findByIdAndOwner`を既定にする設計に倒します。
- **検知の仕掛け**：利用者Aのトークンで利用者Bの資源を呼び出す回帰テストをCIに常設する。これが無いと、今回のように11か月以上気づけません。
- **法対応**：1000人を超える漏えいのおそれは個人情報保護委員会への報告対象。速報は発覚日から3〜5日以内、確報は30日以内（不正の目的で行われたおそれがある場合は60日以内・2026年10月2日時点）。
- **判断**：認可設計は外部委託しても構いませんが、「誰がどのデータを見てよいか」という業務ルールの定義だけは自社で握る。ここを丸投げした案件は、今回と同じ穴を作ります。

## タカラトミーが公表したデュエマアプリ情報漏えい事案の事実関係を整理する

まず一次情報で確認できる範囲を押さえます。出典はタカラトミーが2026年7月28日に公開した[「デュエル・マスターズ サポートアプリ」におけるお客様情報の漏洩可能性に関するお詫びとお知らせ（PDF）](https://dm.takaratomy.co.jp/img/notice20260728.pdf)です。推測を混ぜず、公表されている事実と、そこから技術的に読み取れる範囲を分けて扱います。2026年10月2日時点で、同社のリリース一覧と同アプリのお知らせに続報は掲載されていません。

### 公表内容から確認できる対象期間・対象人数・漏えいの可能性がある情報項目

公表内容を整理すると次のとおりです。数値はいずれも2026年7月28日の発表（第一報・2026年10月2日時点で最新）に基づきます。

| 項目    | 内容                       |
| ----- | ------------------------ |
| 公表日   | 2026年7月28日               |
| 対象アプリ | デュエル・マスターズ サポートアプリ       |
| 原因    | 開発時の利用者認証設計・実装の脆弱性（型非公表） |
| 状態    | 特定条件下で第三者が閲覧可能           |
| 対象期間  | 2025年8月1日〜2026年7月13日     |
| 対象人数  | 最大約15万5000人              |
| 対象項目  | 氏名・住所・電話番号など9項目          |
| 改修完了  | 2026年7月13日               |
| 被害の確認 | 公表時点で閲覧・不正利用は未確認         |

漏えいの可能性がある情報項目は、氏名、住所、電話番号、性別、生年月日、メールアドレス、アプリ内のサービスID、ハンドルネーム、Xのユーザー IDの9項目です。公表された9項目にパスワードやクレジットカード情報は含まれておらず、同社も利用者へ「パスワード変更等の特別なご対応」を求めていません。

「最大約15万5000人」は脆弱性が存在した期間の登録者数を上限として示した数字であり、実際に閲覧された件数ではありません。ただし氏名と住所と生年月日とXのユーザー IDが同一人物の情報として束ねられる形は、なりすましやSNS経由の接触に使われやすい組み合わせです。

### 約11か月間検知できなかったという空白が運用体制について示すもの

技術者の目線で最も重いのは、サービス開始日から改修完了まで11か月以上にわたって脆弱な状態が続いた点です。これは実装のバグそのものよりも、リリース後にその状態を誰も検知できなかったという体制側の課題を示しています。加えて、改修完了の7月13日から公表の7月28日まで15日が空いており、同社は公表文で影響範囲の調査と改修状況の確認のため「ご報告がこの時期となりました」と詫びています。改修と公表の間の空白も、利用者が警戒を始められない期間です。

認可の抜けは正常系のテストでは見つかりません。自分のアカウントで自分のデータを取得する試験は通りますし、画面に他人のデータへの導線が無いため手動の受け入れ試験でも踏みません。露出するのはAPIを直接叩いて識別子を差し替えたときだけで、必要なのは試験の量ではなく「他人になりすまして叩く」という質の違いです。

同時期の事案と比べると、型の違いが見えてきます。生命保険協会の契約照会システムの事案は、2026年9月14日の[調査結果](https://www.seiho.or.jp/info/news/shared/mt-item/20260914.pdf)で、ログインしていないゲストユーザーに他の利用者の個人情報を参照できる権限が誤って付与されていた設定不備と確定しました。未認証のまま見えた型です。本件は「ユーザー認証機能」の不備とだけ公表されており、ログイン済み利用者同士の認可漏れなのか、認証そのものの欠陥なのかは分かっていません。認証と認可のどこが抜けると何が見えるのかは、[生命保険協会の契約照会システム情報漏えい｜ゲストユーザー権限の設定不備を技術解説](https://www.issoh.co.jp/tech/details/15878/)と併せて読むと輪郭がはっきりします。同じ「情報漏えい」でも、サーバーを掌握されてデータを持ち出された型では、認証・認可の不備とは異なる打ち手が必要です。その対比は[ショップサーブの情報漏えい最大885万件｜サーバー侵害とデータ外部送信の技術解説](https://www.issoh.co.jp/tech/details/16098/)で扱っています。データベース層へ到達され保存データを削除された型については、[PeakManagerの個人情報漏えい｜DB侵害・外部転送とデータ削除の技術解説](https://www.issoh.co.jp/tech/details/16101/)で整理しました。

## ユーザー認証機能の不備とは何を指すのか認証と認可を切り分けて読む

公表文で使われた「ユーザー認証機能の不備」という表現は、技術的には二つの異なる欠陥を含みうる言い方です。切り分けないまま対策を考えると、見当違いの改修に工数を払うことになります。

### 認証は本人確認で認可は権限確認という役割の違いを実装で押さえる

認証（Authentication）は「あなたは確かにこのアカウントの持ち主か」を確かめる処理です。IDとパスワードや生体などで本人性を検証し、以降のリクエストで使うトークンを発行します。

一方の認可（Authorization）は「そのアカウントは、いま要求されたこのデータや操作に手を出してよいか」を確かめる処理になります。トークンが有効であることと、そのトークンの持ち主が特定のレコードを読んでよいことは、まったく別の判定です。この境界の考え方はOAuth 2.0の仕様理解と直結するため、フローごとの役割分担は[OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説](https://www.issoh.co.jp/tech/details/8369/)で確認しておくと設計判断が速くなります。

今回のような「第三者が他人の登録情報を閲覧できる状態」は、典型的には2つの型で起きます。1つは、認証は機能していてトークンも発行されているのに、発行済みトークンの持ち主と要求されたレコードの持ち主が一致するかの突き合わせが抜けている型（認可の不備）。もう1つは、トークンの署名や有効期限を検証していない、あるいはクライアントが送ってきた利用者IDをそのまま信じるといった、本人確認そのものの欠陥です。[OWASP API Security Top 10のAPI2:2023 Broken Authentication](https://api-security.owasp.org/editions/2023/en/0xa2-broken-authentication/)は、後者の例として「トークンの真正性を検証しない」「署名なしや弱い署名のJWTを受け入れる」「JWTの有効期限を検証しない」を挙げています。タカラトミーの公表文は「ユーザー認証機能」と書いているだけで、どちらの型だったかは公表されていません。以下の章は前者を中心に扱いますが、後者の点検も同じ重さで行ってください。

### トークンは正しいのに他人のデータが返る状態が起きる実装上の理由

実装がこの形に落ちる理由は、サーバー側の処理が「ログイン済みか」で門番を終えてしまうからです。ミドルウェアでトークンを検証し、通過したリクエストはすべて正当なものとして扱う。あとは受け取った識別子でデータベースを引くだけ、という素直な作りが穴になります。

認証ミドルウェアは横断的に効くので実装の見落としが起きにくい一方、認可はエンドポイントごとの業務ルールなので、書き忘れても他の機能は壊れません。テストも通り、レビューでも「認証は入っているから大丈夫」と流れやすい。この非対称性が、認可の抜けを長期間放置させる構造的な理由です。

認証欠陥の型で多いのは、サーバーが利用者の特定をクライアントの申告に頼る作りです。次の例は、Node.jsのサーバー側で利用者IDをどこから取るかの違いを示します（`verifyAccessToken`は、利用しているフレームワークや認証基盤の検証関数に読み替えてください）。

```
// NG: リクエスト本文の userId をそのまま信じている（値を改変すれば他人になれる）
const user = await repo.findById(req.body.userId);

// OK: 署名・有効期限・発行者を検証したトークンからだけ利用者IDを取り出す
const claims = await verifyAccessToken(req.headers.authorization);
if (!claims) return res.status(401).end();
const user = await repo.findById(claims.sub);
```

モバイルアプリでは、ログイン画面を通った後の通信で端末が自分の利用者IDを送る設計がよく見られます。その値を検証済みトークンの中身と突き合わせない限り、ログインの仕組みが正しくても本人確認は成立していません。

## IDORとBOLAの違いとモバイルアプリAPIで露出する典型パターン

この欠陥には名前が付いています。名前を知っておくと、診断報告書や社内の議論で認識がぶれません。

### 連番のIDをそのまま外部へ公開する設計が招く一括取得と再現のリスク

IDOR（Insecure Direct Object Reference・安全でない直接オブジェクト参照）は、リクエストに含まれる識別子を差し替えるだけで他人の資源へ到達できてしまう状態を指す古くからの呼び名です。[OWASP API Security Top 10](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/)（2026年10月2日時点でも2023年版が最新）では、APIの文脈に絞ってBOLA（Broken Object Level Authorization・オブジェクトレベル認可の不備）としてAPI1に置かれています。呼び名は違いますが、指している欠陥は同じものと考えて差し支えありません。

| 呼称          | 抜けている確認    | 典型的な露出        |
| ----------- | ---------- | ------------- |
| BOLA（API1）  | レコードの所有者一致 | 他人の会員情報の取得    |
| BOPLA（API3） | 項目単位の可視範囲  | 権限外の属性が応答に混入  |
| BFLA（API5）  | 操作の実行権限    | 一般利用者が管理操作を実行 |

連番の識別子を採用していると被害の広がり方が変わります。1件の成功が判明した時点で、値を増減させるだけで全件を順に取得できる形になるためです。レート制限が無ければ、15万件規模の走査を止める仕組みも存在しません。

### モバイルアプリはクライアント側の制御では守り切れないという前提

モバイルアプリ特有の事情として、クライアント側の制御は防御として数えられません。バイナリは利用者の手元にあり、通信内容の観察も改変も可能だからです。端末側で「自分のIDしか送らない」ように書いてあることは、サーバーにとって何の保証にもなりません。

この前提が共有されていないチームでは、「アプリからは他人のIDを送れない仕様だから安全」という説明が設計レビューを通過します。サーバー側は、あらゆる識別子が任意に差し替えられて届く前提で書く。これが出発点です。

## サーバー側でオブジェクトレベル認可を実装する三つの設計方針と限界

では、どう書けば防げるのか。実務で採れる方針は大きく三つあり、それぞれ守備範囲と限界が異なります。

### 所有者チェックをデータ取得と同じ層へ寄せて実装漏れを防ぐ設計方針

最も効果が高いのは、所有者の一致確認をデータ取得の呼び出しそのものに含める方針です。取得してから確認するのではなく、取得の条件に所有者を混ぜてしまいます。

```
// NG: 認証済みかどうかだけを見て取得している
const order = await repo.findById(req.params.orderId);
return res.json(order);

// OK: 所有者の一致を取得条件に含める
const order = await repo.findByIdAndOwner(
  req.params.orderId, req.auth.userId
);
if (!order) return res.status(404).end();
return res.json(order);
```

この形にすると、書き忘れが「他人のデータが見える」ではなく「自分のデータも取れない」という壊れ方に変わります。壊れ方が正常系のテストで露見する側に倒れるため、検知されないまま本番へ出る確率が大きく下がるわけです。加えて、存在しない場合と権限が無い場合を同じ応答に揃えておくと、識別子の存在有無を外部から推し量られる余地も減らせます。

ロールが絡む業務システムでは、役割ごとの許可を宣言的に定義しておく方針も併用できます。ロール設計の考え方と導入判断は[RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/6488/)にまとめています。ただしロールだけでは「同じ一般利用者どうしのデータを分ける」判定は表現できないため、今回の型の防御にはレコード単位の所有者確認が別途必要です。

アプリケーション層の書き忘れを構造的に潰したい場合は、データベース側で行単位の可視範囲を強制する手も選択肢です。実装の入口と設定方法は[Row Level Security（RLS）とは？行単位アクセス制御の仕組みとDB別の設定方法を解説](https://www.issoh.co.jp/tech/details/5442/)が参考になります。アプリ側の実装者が何人替わっても境界が動かない点が強みで、逆に接続ユーザーの設計を誤ると効かないという弱点も抱えます。

### 識別子を推測できない値にする対策だけでは認可の代替にならない理由

連番をUUIDやランダム文字列へ置き換える対策は、たしかに一括走査の難度を上げます。しかしこれは認可ではなく、当てにくくしただけの措置です。

識別子は応答本文、URL、ログ、共有リンク、外部連携など多くの経路で外へ出ます。退職した元従業員や権限を落とした後の元管理者など、いったん値を知った相手には推測困難性が効きません。推測しにくい識別子は一括取得を遅くする補助として数え、所有者チェックの代わりに置かないでください。

## 認可テストを自動化して回帰させる仕組みと脆弱性診断での検出可能性

実装方針が決まっても、それが将来にわたって守られる保証は別に用意する必要があります。今回の事案が11か月続いた事実は、実装より検知の話だからです。予約系Webシステムで不正プログラムの設置と外部送信を検知する設計は[イエローハットの個人情報流出 最大180万件](https://www.issoh.co.jp/tech/details/17203/)で扱っています。

### 利用者Aのトークンで利用者Bの資源を呼び出す回帰テストの実装型

常設したいテストの型は単純です。テスト用に利用者Aと利用者Bを作り、Bの資源の識別子を取得したうえで、Aのトークンでその識別子を呼びます。期待値は404または403で、200が返ればテスト失敗という判定にします。

エンドポイントを追加するたびに手で書く運用は抜けるため、OpenAPIの定義からパスパラメータを持つ操作を抽出し、総当たりで回す形に自動生成しておくと堅くなります。

参照系だけでなく、更新系と削除系も同じ観点で試験してください。読めないが書けてしまうという組み合わせは実際に起こります。加えて、一覧取得の応答に他人のレコードが混ざっていないかという件数ベースの検証も入れておくと、絞り込み条件の書き忘れを拾えます。

### 脆弱性診断で認可の不備を検出するために発注側が渡すべき事前情報

外部の診断で認可不備を捕まえるには、渡す情報の設計が結果を左右します。認可の判定は業務ルールに依存するため、診断側が仕様を知らなければ「他人のデータが返っている」と判断できません。

最低限、権限の異なる複数のテストアカウント、各アカウントが保有するデータの識別子、エンドポイントの一覧と役割、権限モデルの説明を渡します。アカウントを1つしか渡さない発注は、認可の観点がほぼ検査されないまま報告書が出てくる典型です。診断の種類と費用感、外注時の見極め方は[脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)で整理しています。

攻撃者の視点で目的達成までの経路を試すやり方を組み合わせると、単体では軽微に見える欠陥の連鎖も見えてきます。手法の違いと実施の流れは[ペネトレーションテストとは？手法・種類・実施の流れをわかりやすく解説](https://www.issoh.co.jp/column/details/1410/)が参考になります。自社での常設が難しい場合は、リリース前の関門として外部の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)を挟み、認可観点を明示的に依頼する形が現実的です。

## 個人情報保護法の漏えい報告義務と未成年中心サービスの通知設計を考える

実装の話と並行して、事故が起きた際の法的な動き方も設計に含めておく必要があります。判断に迷う時間そのものが被害を広げるためです。

### 1000人超の漏えいのおそれで生じる速報と確報という実務の流れ

個人情報保護法では、個人データの漏えい等が発生し個人の権利利益を害するおそれがあるとき、個人情報保護委員会への報告と本人への通知が義務づけられています。[委員会の漏えい等報告ページ](https://www.ppc.go.jp/personalinfo/legal/leakAction/)によれば、報告対象となる事態は、要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正の目的による行為の場合、そして1000人を超える場合の4類型です。本件は最大約15万5000人で4つ目に該当しうる規模ですが、タカラトミーが委員会へ報告したかどうかと、その日付は公表文に記載がなく確認できません。

報告は二段階で行います。速報は発覚日から3〜5日以内、確報は発覚日から30日以内（不正の目的で行われたおそれがある場合は60日以内）というのが2026年10月2日時点の同ページの記載です。実際に漏えいしたことが確認できていなくても「漏えいのおそれ」がある段階で対象になる点が実務上の要注意箇所で、被害の有無を調べ切ってから動くと期限を外します。

本人通知は「事態の状況に応じて速やかに」とされ、日数の固定はありません。通知が困難な場合は、代替措置として公表などの方法も認められています。法の全体像は[個人情報保護法とは？その定義と基本的な概念を解説](https://www.issoh.co.jp/column/details/5869/)を、直近の改正で企業対応がどう変わるかは[個人情報保護法改正とは？2026年成立の令和8年改正で企業対応はこう変わる](https://www.issoh.co.jp/column/details/13787/)を確認してください。件数の推移から見た全体傾向は[個人情報漏えい件数の推移をグラフで解説｜最新データと過去最多（約1.9万件）](https://www.issoh.co.jp/column/details/2406/)にまとめています。

### 未成年が中心の利用者へ本人通知を届けるための設計上の工夫と限界

カードゲームのサポートアプリのように未成年が利用者の多くを占めるサービスでは、通知の設計が一段難しくなります。登録メールアドレスが保護者のものである場合と本人のものである場合が混在し、住所への郵送も世帯単位でしか届きません。

設計で仕込めることは、登録時にメールアドレスの帰属（本人か保護者か）を持つこと、アプリ内の告知面を通知チャネルとして常時使える状態にしておくことの二つです。緊急時に新規で作ろうとすると、審査と実装で数日を失います。

限界も明示しておきます。アプリを削除済みの利用者、メールアドレスを変更した利用者には、どの手段でも届きません。だからこそ、通知で回収する前提を置かず、そもそも脆弱な状態を長期間放置しない検知側へ投資するほうが費用対効果は高くなります。

## 発注側と開発側が今回の事案から引き出すべき採用条件と見送り場面

ここからは、当社が受託開発とセキュリティ診断の現場で判断している基準を、条件付きで言い切ります。一般論ではなく、採用する場面と見送る場面を分けて示します。

### 認可設計を外部に委ねてよい場面と自社で握るべき場面を分ける条件

認可の「実装」は外部に委ねて構いません。所有者チェックをどの層に置くか、フレームワークのどの機構を使うか、RLSを併用するかといった技術選択は、経験のある開発会社のほうが速く堅く決められます。

一方で、認可の「定義」は自社で握ってください。誰がどのデータを見てよいか、代理と閲覧と編集をどう分けるか、退会や権限変更の後に過去データへの到達をどう扱うか。これらは業務そのものであり、外部が推測で埋めた瞬間に穴が生まれます。判断基準としては、権限マトリクス（役割×資源×操作）を自社の担当者が説明できる状態になっているかを見てください。説明できないなら、それは委託先ではなく発注側の宿題が残っています。

逆に見送るべき場面もはっきりしています。仕様書に権限の記述が一切なく、かつ短納期でリリース日だけが決まっている案件で、認可要件の整理工数を削って着手する進め方は採るべきではありません。今回の事案が示すとおり、この欠陥は本番で11か月動いても症状が出ないため、削った工数の請求書は数年後に事故として届きます。

### 今回と同型の事故を避けるためにリリース判定前へ挟むべき三つの関門

実務で機能している関門は三つです。第一に、権限マトリクスのレビュー。資源と操作の組み合わせに対して、想定する役割ごとの可否が空欄なく埋まっているかを確認します。空欄は仕様の未決定であり、実装者の裁量で埋められた箇所が事故の起点になります。

第二に、他人トークンによる横断テストの合格。前述の回帰テストをリリース判定の必須項目に置き、緑になっていることを条件にします。件数が少ないうちに仕組み化するほど安く済みます。

第三に、外部診断における認可観点の明示的な依頼。複数権限のアカウントを渡したうえで、オブジェクトレベル認可の検査を依頼範囲へ書き込んでください。ここまで揃えて初めて、今回の型の事故を「起きない」ではなく「起きても11か月続かない」状態にできます。完全な予防ではなく検知までの時間短縮を目標に置くほうが、実務は回ります。

## よくある質問

### デュエマアプリの利用者は今すぐ何をすべきですか？

タカラトミーはパスワードの変更を求めておらず、パスワード自体は対象項目に含まれていません。ただし氏名・住所・生年月日・メールアドレス・XのユーザーIDが束ねられた形が想定されるため、同社を装うメールやSMS、SNSのダイレクトメッセージには警戒してください。

### 最大約15万5000人という数字は実際に漏れた件数ですか？

いいえ。脆弱性が存在した期間に登録していた利用者数の上限として示された数字であり、実際に閲覧された件数ではありません。公表時点で第三者による閲覧や不正利用は確認されていないとされています。ただしアクセスログの保持期間や粒度によっては、閲覧の有無を事後に確定できない場合もあり、未確認と無被害は同義ではない点に注意が必要です。

### IDORとBOLAは違うものとして区別すべきですか？

実務上は同じ欠陥を指す呼び名として扱って問題ありません。IDORはWebアプリ全般で古くから使われてきた用語、BOLAはOWASP API Security Top 10がAPIの文脈で整理した用語という違いです。なお本件がIDOR／BOLAだったかどうかは、タカラトミーが脆弱性の型を公表していないため確認できません。診断報告書や社内チケットでは、どちらの呼称を使うかをチームで統一しておくと、対応漏れの追跡が楽になります。

### WAFやレート制限を入れれば認可の不備は防げますか？

防げません。WAFは既知の攻撃パターンに合致する通信を弾く仕組みで、正規の形式で自分のトークンを付けたリクエストは通常の通信として通過します。レート制限も一括取得の速度を落とすだけで、1件の不正な取得は止まりません。これらは被害の拡大を抑える層として価値がありますが、サーバー側の所有者チェックを置き換える手段にはなりません。

### 既存サービスで認可の抜けを点検する実務手順を教えてください。

まず識別子を引数に取るエンドポイントを一覧化し、それぞれに所有者確認のコードがあるかを機械的に確認します。次に権限の異なる2つのテストアカウントを用意し、片方のトークンでもう片方の資源を呼ぶ試験を参照・更新・削除の順で実施してください。ここで200が返る箇所が見つかった場合は、影響範囲とログの保持状況を先に確定させてから改修に入ります。報告義務の判断に必要な材料が消えるためです。

## 関連記事

- [生命保険協会の契約照会システム情報漏えい｜ゲストユーザー権限の設定不備を技術解説](https://www.issoh.co.jp/tech/details/15878/)
- [OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説](https://www.issoh.co.jp/tech/details/8369/)
- [RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/6488/)
- [Row Level Security（RLS）とは？行単位アクセス制御の仕組みとDB別の設定方法を解説](https://www.issoh.co.jp/tech/details/5442/)
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)
- [ペネトレーションテストとは？手法・種類・実施の流れをわかりやすく解説](https://www.issoh.co.jp/column/details/1410/)
- [個人情報保護法改正とは？2026年成立の令和8年改正で企業対応はこう変わる](https://www.issoh.co.jp/column/details/13787/)
- [個人情報漏えい件数の推移をグラフで解説｜最新データと過去最多（約1.9万件）](https://www.issoh.co.jp/column/details/2406/)

---

出典: [タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか](<https://www.issoh.co.jp/tech/details/15978/>)（株式会社一創）