Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ShulkwiSEC/bb-huge --skill idor-broken-object-authorizationgit clone --depth 1 https://github.com/ShulkwiSEC/bb-hugeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shulkwisec/bb-huge/idor-broken-object-authorization)<a href="https://agentmods.dev/skills/shulkwisec/bb-huge/idor-broken-object-authorization"><img src="https://agentmods.dev/badge/skills/shulkwisec/bb-huge/idor-broken-object-authorization.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.02817 |
| Opus 5 | $0.00018 | $0.01409 |
| Sonnet 5 | $0.00007 | $0.00563 |
| Haiku 4.5 | $0.00004 | $0.00282 |
Grade A, and why
idor-broken-object-authorization scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to idor-broken-object-authorization — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 337 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 337 lines · 37 tokens per session scan A 8e9370bf70d0
idor-broken-object-authorization is a skill published in the GitHub repository ShulkwiSEC/bb-huge (22 stars, last pushed 1mo ago), licensed MIT. It adds 37 tokens to every session and 2,817 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to idor-broken-object-authorization, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
bugcrowd-reporting
Bugcrowd-specific reporting tactics complementing report-writing: VRT category search-and-fallback strategy when no exact match exists, manual severity override when VRT defaults underrate impact, severity-request paragraph as first body section, OOS-clause rebuttal templates (rate limiting on auth-flow endpoints…
skill-context-detection
Auto-detect work context (Dev vs Knowledge) — use to tailor workflows based on current task type.
skill-copilot-provider
GitHub Copilot CLI as optional zero-cost provider via copilot -p programmatic mode.
supabase
Supabase / PostgREST Row-Level-Security playbook — pull the anon (or leaked servicerole) key out of the frontend JS, map tables from the auto-generated OpenAPI spec, test anonymous RLS READ disclosures (PII/secret leaks), and anonymous RLS WRITE abuse (insert/update/delete — e.g. forging…
skill-security-framing
URL validation and content sanitization for untrusted sources — use when handling external input safely.
race
Race condition / TOCTOU playbook — limit overrun (one-time codes used twice, gift cards spent twice), single-packet attack (last-byte sync) to force parallel processing, and state-confusion races (file upload + read, order before payment). Use when timing-sensitive logic could be abused — one-time codes, coupons/gift…