IDOR → Blast-Radius Sizing

You have an IDOR candidate: an endpoint where flipping an object reference returns or mutates an object you don't own. Your job is to find the ID space, prove the access is unauthorized, size the impact (how many objects, what data class, read vs write, same-tenant vs cross-tenant), and persist a finding that reflects real severity, not theoretical.

When this skill applies

• A path/query/body param looks like /users/{id}, /orders/{id}, /files/{uuid}, /exports/{slug}, and changing the ref changes the response in a way the auth context shouldn't allow.
• The reference is indirect: an account id in a JWT claim, a X-Account-Id header, a tenant id in a cookie, a hidden form field. These are IDOR too.
• Two different sessions return the same object for the same ID, the server doesn't filter by current_user / current_tenant.
• CWE-639 / CWE-284 / "BOLA" / "Broken Object Level Authorization" / "mass assignment of owner field" in an audit finding.

Don't run this on endpoints that are intentionally cross-user public (/users/{id}/avatar is sometimes public; check before claiming).

Workflow

1. Establish two identities and a baseline

You need a second reference point to prove "this is someone else's object", not just "this object exists". In order of preference:

1. A second authenticated session (query_records / prior auth), best.
2. An object id you legitimately own + a neighboring id you don't.
3. Unauthenticated replay of an authenticated endpoint (if it returns data without a session, that's a stronger, separate finding, note it).

replay_request your own id + your own session → record the canonical "authorized" response (status, length, a unique field like your email).

2. Discover the ID space (don't assume it's enumerable)

Collect every id you've seen for this handler from query_records, then classify and find a source of valid ids before probing: