When you find an Insecure Direct Object Reference (a URL/body/header parameter that lets you read or write another user's or another tenant's object), discover the ID space, prove the access is unauthorized, quantify the blast radius (how many records reachable, what data class, read vs write, same-tenant vs cross-tenant), and persist a finding sized by real impact rather than by the existence of the flaw. Use when an ID parameter (numeric, UUID, hash, slug, or an indirect ref in a header/cookie) changes the response across IDs, when CWE-639/CWE-284/BOLA was flagged, or when an audit finding hints at object-level access control gaps.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
When you find an Insecure Direct Object Reference (a URL/body/header parameter that lets you read or write another user's or another tenant's object), discover the ID space, prove the access is unauthorized, quantify the blast radius (how many records reachable, what data class, read vs write, same-tenant vs cross-tenant), and persist a finding sized by real impact rather than by the existence of the flaw. Use when an ID parameter (numeric, UUID, hash, slug, or an indirect ref in a header/cookie) changes the response across IDs, when CWE-639/CWE-284/BOLA was flagged, or when an audit finding hints at object-level access control gaps.
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}, ,
, — and changing the ref changes the
response in a way the auth context shouldn't allow.
/orders/{id}
/files/{uuid}
/exports/{slug}
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:
A second authenticated session (query_records / prior auth) — best.
An object id you legitimately own + a neighboring id you don't.
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:
Sequential numeric (1, 2, 3, 5, 6…): full enumeration trivial.
Sequential with gaps (1004, 1009, 1011…): probe a range; gaps are
deletes, not auth.
Timestamped / snowflake (1700000000123…, Twitter-style ids): the
high bits are a clock — neighbors are ids created near yours in time.
UUID v1 (xxxxxxxx-xxxx-1xxx-…): time + MAC encoded — not random.
Ids minted close in time share a prefix; partially predictable.
UUID v4 (…-4xxx-[89ab]xxx-…): not enumerable from outside — you
need a leak. Hunt list endpoints, comment threads, Referer/Location
headers, search results, error messages, sitemaps, JS bundles.
Hashids / short hash (a3f9, 7c2k, gY3p): often a reversible
encoding of a sequential int (hashids, sqids, base62). Decode a few of
your own ids; if they map to small consecutive integers, it's
sequential in disguise — enumerable.
Slug (order-john-2024-001): semi-predictable; try permutations of
the variable parts you can infer.
remember the format + the id source as idor-id-space. If the space is
UUIDv4 and you found no leak, say so in the finding — "enumerable only with
a valid id source" caps the realistic blast radius.
3. Confirm the access is unauthorized
replay_request a neighboring / other-owner id with your session:
Different object's data (different email, owner, content) → IDOR confirmed.
403 / 404 / {error:"not found"} body → the auth check works. Read the
body, not just the status; some apps 200 with an error envelope.
Same object regardless of id → not an object ref; move on.
Re-confirm once (a second neighboring id) so a single coincidental match
doesn't drive a finding.
4. Size — sample, don't crawl
Probe 20–50 ids maximum chosen to cover the space, never the whole range:
~10 near yours (your_id ± 5), ~10 near the low end, ~10 near an
estimated high end.
For hashids, decode→increment→re-encode to generate neighbors.
Count, per status, how many returned another principal's data. Project the
total ("28/30 sampled ids resolved; ids run 1–~50000 → ~all 50k users
reachable") and state the projection in the finding, not 50000 requests.
remember the count as idor-reachable.
5. Determine data class
For 1–3 leaked records, note what's exposed and categorize:
Credentials (password hash, API key, session/refresh token) — critical.
Try PUT / POST / PATCH / DELETE with the other-owner id and the body
the legitimate owner would send. Do not destructively modify or actually
elevate. A 200/204 (or a reflected-back changed field) proves the write
path — note it, then stop. Probe owner/role fields specifically
({"role":"admin"}, {"owner_id":<you>}) for mass-assignment-style
privilege takeover; confirm via a read-back, do not leave the change in place.
Read-IDOR is high; write-IDOR is critical.
7. Check the tenant boundary
If the app is multi-tenant, repeat step 3 with an id from a different
tenant/org, not just a different user in your tenant. Cross-tenant read or
write is the worst flavor — it breaks the product's core isolation promise.
Flag it explicitly: same-tenant vs cross-tenant changes both severity and
the disclosure urgency.
8. Persist the finding
report_finding once per IDOR pattern (not per id probed):
severity: (data class) × (read|write) × (same|cross-tenant) — use the
tables above; cross-tenant write of credentials/financial is "contact the
customer ASAP" critical.
title: endpoint + ref type + blast + tenancy, e.g. "IDOR on GET /api/orders/{id} reads all ~12k orders cross-tenant; sequential numeric id".
cwe_id: CWE-639.
description: 3–4 sentences — endpoint, ref type + id source, ids probed,
count reached, data class, read/write, same vs cross-tenant.
Include 1 masked sample row from another principal (***@***).
If the audit harness already filed a theoretical finding for the same
endpoint, update_finding with status: triaged and the new evidence
instead of double-reporting.
Pitfalls
Don't paste 50 real emails/records into the finding. One masked sample +
the count + projection is what matters.
A 200 with empty body, or a 200 {error:"not found"}, is not a leak —
read the body before claiming.
"I got data" + "I'm an admin in this app" = not IDOR; you're allowed to
see it. Confirm your session is a regular, low-privilege role.
UUIDv4 with no id source is not "all users reachable" — cap the claim.
Hashids/short slugs that look opaque are frequently sequential ints in
disguise; decode before declaring the space non-enumerable.
A neighbor id returning data could be your own second object. Verify the
owner field differs from your principal.
Output expectations
One finding per IDOR pattern (not per id probed).
A remember note with the canonical proof request, id source, and
projection.
