# Idor Blast Radius

When you find an Insecure Direct Object Reference (a URL/body/header parameter that...

- Repository: https://github.com/vigolium/vigolium (1141 stars)
- Category: Writing
- License: MIT
- Last updated: 2026-10-25
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add vigolium/vigolium --skill idor-blast-radius -g -a claude-code -y`
Codex: `npx skills add vigolium/vigolium --skill idor-blast-radius -g -a codex -y`
Cursor: `npx skills add vigolium/vigolium --skill idor-blast-radius -g -a cursor -y`
Gemini CLI: `npx skills add vigolium/vigolium --skill idor-blast-radius -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

The rest: https://github.com/vigolium/vigolium/blob/HEAD/internal/resources/olium/skills/idor-blast-radius/SKILL.md