Data Exfil Deep

Find the pagination count field (needed for mass exposure proof): total, count, meta.total, x-total-count header, recordCount

Step 1: Classify Exposure Type (1 min)

Which pattern are you seeing?

• Response has extra fields the UI does not show? Go to Step 3 (Excessive Data).
• Changing an ID returns another user's data? Go to Step 2 (IDOR).
• Single request returns data for many users? Go to Step 4 (Mass Exposure).
• Endpoint accessible without auth? Test with no token first, then escalate.

Data Sensitivity Tiers (determines severity ceiling)

Always push to find the highest-tier data accessible. Same vuln at T1 vs T4 is a completely different finding.

Step 2: IDOR Testing Procedure

1. Two accounts required. Account A and Account B in separate sessions.
2. Collect all IDs from Account A's traffic - user IDs, resource IDs, order IDs, document IDs. Check URL, body, headers, cookies.
3. Replay each request as Account B using Account A's IDs.
   • Got Account A's data? IDOR confirmed. Note the data tier (T1-T4).
   • Same data regardless of ID? Server ignores ID param. Not IDOR.
   • 403/401? Proper access control. Move on.
4. Try with NO auth token - sometimes the check is missing entirely.
5. Found IDOR? Immediately test what fields are in the response. Push for T1 data. Then go to Step 4 for mass exposure proof.

Step 3: Excessive Data Exposure

1. Intercept your own profile API call. Compare raw JSON response to what the UI shows.
2. Look for hidden fields: ssn, dob, password_hash, internal_id, admin_notes, credit_card_last4, phone, ip_address, location, apiKey, role
3. Found extra fields? Classify by data tier.
   • T1/T2 data in response? HIGH/CRITICAL finding even on your own profile - the API overshares.
   • T3/T4 only? Lower severity - still report if combined with IDOR.
4. Test on other users' objects (if IDs available) - same excessive fields on other users' data = IDOR + excessive data exposure chain.
5. Check search results - each result object often contains the same hidden fields as the detail endpoint.

Step 4: Mass Exposure Proof

1. Test pagination limits: Add ?limit=10000 to any paginated endpoint. Does it return all records?
2. Test export endpoints: /api/export/users, /api/reports/download, /api/download
3. Test empty search: GET /api/search?q= - returns all results?
4. Test autocomplete: GET /api/users/suggest?q=a - enumerates user base?

Safe PoC (do NOT dump the database): Request page 1 and page 2. Note the total count in the response. Report: "Endpoint returns total: 847,293 - this represents the total accessible user records."

Found mass exposure? This is the severity amplifier. Single-user IDOR = Medium. All-user IDOR = Critical.

Step 5: Escalate Severity

Severity formula:

Base: IDOR or excessive exposure = Medium
+ T1 data (SSN, card, medical) = Critical
+ No auth required = +1 severity
+ Mass exposure (all users) = +1 severity
+ Enables account takeover = Critical regardless

Chaining decision tree:

• Found OAuth bypass? Show what account data is now exposed.
• Found IDOR with T4 data? Test ALL fields - push for T1.
• Found LLM injection? Enumerate what PII the model can access.
• Any access control bypass? This skill is always step 2.

Step 6: Report Structure

Evidence required:

1. Request/response - your own account's data (baseline)
2. Request/response - Account B's data accessed from Account A's session
3. Highlighted diff showing sensitive fields
4. If mass exposure: total count from paginated response
5. Real-world impact statement

Frame it as: "IDOR in /api/user/{id} allows any authenticated user to access full profiles including ssn, dob, home_address for all 2.3M users. No rate limiting. Enables identity theft at scale."

NOT: "The endpoint returns data for other users."

Quick Triage (if starting fresh - 10 min)

1. Intercept your profile API call. Hidden fields in response? Step 3.
2. Change your user ID to 1, 2, 3. Other users' data? Step 2.
3. Add ?limit=1000 to paginated endpoints. All records? Step 4.
4. Check /api/admin/, /api/internal/, /api/v1/users. No auth needed? Finding.
5. Try /api/export, /api/download. Bulk data? Step 4.

Nothing after all five? Move on.

Rate Limit Bypass

If enumeration is blocked:

• Batch requests (rate limit is per-request, not per-object)
• Rotate test accounts (separate rate limit buckets)
• WebSocket/subscription endpoints (often no rate limiting)
• Mobile API endpoints (often less protected)
• Jitter: 2-5 second delays

When to Stop

• UUIDs confirmed random + no leakage vector? Try GraphQL field mining.
• All fields properly authed? Test subscriptions, batch requests.
• All pagination limits enforced? Test export/download endpoints.
• Everything clean after 2+ hours? Document defenses, move on. Return in 30 days.

High-Priority IDOR Locations (test these first)

1. Export/download - GET /export/invoice/12345.pdf
2. Password reset / email change - user_id in POST body
3. Payment/billing - /api/billing/invoices/ID
4. File/attachment - /api/attachments/ID/download
5. Admin API paths - /api/admin/users/ID
6. Newly shipped features - first-sprint code lacks access control review
7. GraphQL mutations - delete/update on other users' objects
8. Legacy API - /api/v1/users/ID unprotected while v2 is guarded
9. Messages/notifications - /api/messages/thread/ID/read
10. Early IDs (1-10) - often admin accounts

Framework-Specific IDOR Shortcuts

Cryptographic IDOR - IDs that look random but are not:

• UUID v1 = contains timestamp, enumerable
• ULIDs = millisecond timestamp, brute-forceable in narrow window
• Hashids with default salt = decode with hashids library
• base64(user_id + padding) = decode directly

Automation

python3 references/idor_enum.py \
  --url "https://api.target.com/documents/{id}" \
  --auth "Bearer YOUR_TOKEN" \
  --start 1 --end 5000 --your-id 4521 --delay 0.5 --out results.json

Reference Files

• references/idor-patterns.md — IDOR techniques, array wrapping, bypass patterns, horizontal-to-vertical chain
• references/api-exposure.md — GraphQL introspection, REST hidden fields, SSPP, access control bypass
• references/mass-exposure.md — Safe mass enumeration, scale calculation, severity escalation, report framing
• references/advanced-patterns.md — WebSocket IDOR, CSWSH, race condition IDOR, GraphQL advanced, mobile APIs
• references/framework-idor.md — Framework-specific IDOR (Rails, Django, Spring, Express, FastAPI), cryptographic IDOR, gRPC patterns, idor_enum.py script