Idor Broken Object Authorization
Run structured IDOR, BOLA, and BFLA tests when APIs or apps expose object IDs, tenants, or weak object-level authorization.
Overview
IDOR / Broken Object Level Authorization is an agent skill most often used in Ship (also Validate scope, Build backend) that guides systematic IDOR, BOLA, and BFLA testing when object identifiers and weak authorization a
Install
npx skills add https://github.com/yaklang/hack-skills --skill idor-broken-object-authorizationWhat is this skill?
- Distinguishes IDOR, BOLA (OWASP API A1), and BFLA with impact framing for triage
- Maps object identifiers across URL path, query, body, JSON fields, and headers—not only path params
- Documents A–B testing methodology, non-obvious IDOR surfaces, and chaining IDOR to higher impact
- Covers what bounty hunters repeatedly miss beyond swapping numeric IDs in URLs
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You expose user, order, or tenant IDs across paths, bodies, and headers but only spot-check one endpoint, so other users’ data stays reachable in production.
Who is it for?
Solo builders shipping REST or GraphQL APIs, multi-tenant apps, or bounty hunters who need a structured IDOR surface map beyond URL parameter swaps.
Skip if: Teams that only need dependency CVE scanning or static analysis with no hands-on authorized API testing in a staging environment.
When should I use this skill?
Requests expose object identifiers, tenant boundaries, writable fields, or missing object-level authorization checks.
What do I get? / Deliverables
You get a repeatable playbook to hunt object-level authorization gaps everywhere IDs flow, classify BOLA vs BFLA, and escalate findings with clearer impact notes for fixes or bounty reports.
- IDOR/BOLA test notes per endpoint and ID location
- BFLA versus BOLA classification for findings
- Chaining ideas for higher-impact exploits where applicable
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Authorization flaws are caught before or right after release; the canonical shelf is Ship → Security where solo builders harden APIs and chase bounty findings. Playbook targets penetration-style object-level auth checks, not generic unit tests—fits the security subphase of shipping safely.
Where it fits
Scope a clickable prototype API to list every endpoint that returns another user’s records before full build.
Audit new CRUD handlers while IDs still live in request bodies and nested JSON, not only route params.
Run A–B authorization tests on staging immediately before release or bounty submission.
Re-test after a tenant-boundary change when support reports possible cross-account data leaks.
How it compares
Use as a procedural testing playbook for object-level auth, not as a generic OWASP checklist PDF or an automated DAST substitute.
Common Questions / FAQ
Who is idor-broken-object-authorization for?
Indie developers, agent-assisted pentesters, and bug bounty hunters who own API authorization before launch or during active programs.
When should I use idor-broken-object-authorization?
During Ship security reviews on production-like APIs, while scoping Validate prototypes that already use real IDs, and during Build when wiring backend integrations that pass object references in bodies and headers—not only path segments.
Is idor-broken-object-authorization safe to install?
It is documentation for authorized security testing; review the Security Audits panel on this Prism page before installing and only run techniques against systems you own or have explicit permission to test.
SKILL.md
READMESKILL.md - Idor Broken Object Authorization
# SKILL: IDOR / Broken Object Level Authorization — Expert Attack Playbook > **AI LOAD INSTRUCTION**: IDOR is the #1 bug bounty finding. This skill covers non-obvious IDOR surfaces, all attack vectors (not just URL params), A-B testing methodology, BOLA vs BFLA distinction, chaining IDOR to higher impact, and what testers repeatedly miss. --- ## 1. IDOR vs BOLA vs BFLA | Term | Meaning | Impact | |---|---|---| | IDOR | Insecure Direct Object Reference | Read/modify other users' data | | BOLA | Broken Object Level Authorization (OWASP API Top 10 A1) | Same as IDOR, API terminology | | BFLA | Broken Function Level Authorization | Low-priv user accesses HIGH-PRIV functions (e.g., admin endpoints) | **Key distinction**: - BOLA = accessing **object** you shouldn't own (data belonging to other users) - BFLA = accessing **function** you shouldn't be authorized for (admin CRUD operations, bulk actions, user management) --- ## 2. WHERE TO FIND OBJECT IDs (ALL LOCATIONS) Don't stop at URL path parameters — IDs appear in: ``` URL path: GET /api/v1/users/1234/profile URL query: GET /orders?order_id=982 Request body: {"userId": 1234, "action": "view"} JSON fields: {"resource": {"id": 5678, "type": "invoice"}} Headers: X-User-ID: 1234 X-Account-ID: 9999 Cookies: user_id=1234; account=org_5678 GraphQL args: query { user(id: "1234") { ... } } Form fields: <input name="documentId" value="5678"> WebSocket msgs: {"event":"subscribe","channel_id":9999} ``` --- ## 3. A-B TESTING METHODOLOGY The most systematic IDOR test approach: ``` Step 1: Create two test accounts: UserA and UserB Step 2: Perform all actions as UserA, capture all requests (profile edit, order view, password change, file access, etc.) Step 3: Note every object ID created or accessed by UserA Step 4: Authenticate as UserB Step 5: Replay UserA's requests using UserB's session token Step 6: If UserB can read/modify UserA's data → BOLA confirmed Victim matters: for real bugs, target existing users, not test accounts. Report evidence: show UserA owns the resource, UserB accessed it. ``` --- ## 4. ID TYPE ITS IMPLICATIONS | ID Pattern | Example | Notes | |---|---|---| | Sequential int | `id=1001` → `id=1002` | Easy prediction, high hit rate | | UUID v4 | `550e8400-...` | Need to find UUID from other endpoints | | UUID v1 | Clock-based UUID | Time-predictable! Extract timestamp/MAC | | GUIDs from own data | See in responses | Collect all UUIDs from your own account data first | | Hashed IDs | `md5(user_id)` | Try hashing sequential ints | | Encoded IDs | base64(`{"id":1001}`) | Decode → modify → re-encode | | Compound IDs | `/api/users/1/orders/5` | Both IDs may be independently verifiable | --- ## 5. HORIZONTAL vs VERTICAL PRIVILEGE ESCALATION **Horizontal**: UserA accesses UserB's data (same privilege level) ``` GET /api/account/1234/statement ← you are user 5678 ``` **Vertical**: Low-priv user accesses admin-only functions ``` POST /api/admin/users/delete ← normal user calling admin endpoint GET /api/admin/all-users PUT /api/users/1234/role {"role":"admin"} ``` **Combined**: Low-priv IDOR that grants privilege escalation ``` GET /api/v1/users/1/details → read admin user's auth token ``` --- ## 6. HTTP METHOD ESCALATION When `GET /resource/1234` is properly restricted, test ALL other verbs: ```http GET /api/v1/users/UserA_ID ← might be blocked POST /api/v1/users/UserA_ID ← different code path, might not check authz PUT /api/v1/users/UserA_ID ← update another user's data DELETE /api/v1/users/UserA_ID ← delete another user's account PATCH /api/v1/users/UserA_ID ← partial update (often missed in authz checks) ``` *