testing-api-for-broken-object-level-authorization

Tests REST and GraphQL APIs for Broken Object Level Authorization (BOLA/IDOR, OWASP API1:2023) by intercepting API calls, identifying object ID parameters (numeric IDs, UUIDs, slugs), and systematically substituting IDs belonging to other users to check whether the server enforces per-object authori

By mukul975 · 459 installs

npx skills add mukul975/anthropic-cybersecurity-skills --skill testing-api-for-broken-object-level-authorization

Source repository · Upstream listing

Testing API for Broken Object Level Authorization When to Use Assessing REST or GraphQL APIs that use object identifiers in URL paths, query parameters, or request bodies Performing OWASP API Security Top 10 assessments where API1:2023 (BOLA) must be tested Testing multi tenant SaaS applications where users from different tenants should not access each other's data Validating that API endpoints enforce per object authorization checks beyond just authentication Evaluating APIs after new endpoints are added to ensure authorization middleware is applied consistently 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. Prerequisites Written authorization specifying the target API endpoints and scope of testing At least two test accounts with different privilege levels and distinct data sets Burp Suite Professional or OWASP ZAP configured as an intercepting proxy Authentication tokens (JWT, session cookies, API keys) for each test account API documentation (OpenAPI/Swagger spec) or access to enumerate endpoints Python 3.10+ with requests library for scripted testing Autorize Burp extension installed for automated BOLA detection Workflow Step 1: API Endpoint Discovery and Object ID Mapping Enumerate all API endpoints and identify parameters that reference objects: From OpenAPI/Swagger Specification: From Burp Suite Traffic: 1. Browse the application as User A, exercising all features that involve data creation and retrieval 2. In Burp, go to Target Site Map and filter for API paths (e.g., /api/v1/ , /graphql ) 3. Look for patterns: /api/v1/users/{id} , /api/v1/orders/{order id} , /api/v1/documents/{doc uuid} 4. Note the object ID format: sequential integers (predictable), UUIDs (less predictable), or encoded values Classify Object ID Types: ID Type Example Predictability BOLA Risk Sequential Integer /orders/1042 High increment/decrement Critical UUID v4 /orders/550e8400 e29b 41d4 a716 446655440000 Low random Medium (if leaked) Encoded/Hashed /orders/base64encodedvalue Medium decode and predict High Composite /users/42/orders/1042 High multiple IDs to swap Critical Slug /profiles/john doe Medium guess usernames High Step 2: Baseline Request Capture with Authenticated User Capture legitimate requests for User A and User B: Step 3: BOLA Testing Horizontal Privilege Escalation Attempt to access User B's objects using User A's authentication: Step 4: Advanced BOLA Techniques Test for less obvious BOLA patterns: Step 5: Automated BOLA Detection with Autorize (Burp Suite) Configure Autorize for automated detection: 1. Install Autorize from the BApp Store in Burp Suite Professional 2. In the Autorize tab, paste User B's authentication cookie or header 3. Configure the interception filters: Include: . \/api\/. (only API paths) Exclude: . \.(js css png jpg)$ (skip static assets) 4. Set the enforcement detector: Add conditions where response length or status code differs between User A and User B Mark as "enforced" if User A gets 403/401 for User B's resources Mark as "bypassed" if User A gets 200 with User B's data 5. Browse the application as User A; Autorize automatically replays each request with User B's token 6. Review the Autorize results table: Green = Authorization enforced (secure) Red = Authorization bypassed (BOLA vulnerability) Orange = Needs manual review (ambiguous response) Step 6: GraphQL BOLA Testing Key Concepts Term Definition 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 IDOR Insecure Direct Object Reference a closely related term where the application uses user controllable input to directly access objects without authorization checks Horizontal Privilege Escalation Accessing resources belonging to another user at the same privilege level by manipulating object identifiers Vertical Privilege Escalation Accessing resources or functions restricted to a higher privilege level (e.g., regular user accessing admin endpoints) Object ID Enumeration Predicting valid object identifiers by analyzing their format (sequential integers, UUID patterns, encoded values) Autorize A Burp Suite extension that automates authorization testing by replaying requests with different user tokens Tools & Systems Burp Suite Professional : Intercepting proxy for capturing and manipulating API requests with Autorize extension for automated BOLA testing OWASP ZAP : Open source alternative with Access Control Testing add on for authorization boundary testing Autorize : Burp extension that automatically detects authorization enforcement by replaying requests with different user contexts Postman : API testing platform for crafting and replaying requests with different authentication tokens across collections ffuf : Web fuzzer that can enumerate object IDs at scale: ffuf u https://api.example.com/orders/FUZZ w ids.txt H "Authorization: Bearer token" Common Scenarios Scenario: E Commerce API BOLA Assessment 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). Approach : 1. Map all endpoints from the Swagger spec at /api/docs : identify 47 endpoints, 23 of which take object IDs 2. Capture User A's requests for their own resources: profile, orders, addresses, payment methods, wishlist 3. Replace User A's object IDs with User B's IDs systematically across all 23 endpoints 4. Find that GET /api/v1/orders/{id} returns any order regardless of ownership (BOLA on read) 5. Find that PATCH /api/v1/addresses/{id} allows modifying any user's address (BOLA on write) 6. Find that GET /api/v1/users/{id}/payment methods leaks payment card last four digits for any user 7. Test batch endpoint POST /api/v1/orders/export accepts array of order IDs and exports all without ownership check 8. Verify that DELETE /api/v1/orders/{id} correctly returns 403 for non owned orders (authorization enforced) Pitfalls : Only testing GET requests and missing BOLA in PUT/PATCH/DELETE methods that allow data modification or destruction Assuming UUIDs prevent BOLA UUIDs are less predictable but can be leaked in API responses, logs, or URL parameters Not testing nested resource paths where authorization may be checked on the parent but not the child resource Missing BOLA in bulk/batch endpoints that accept arrays of object IDs Not considering that different API versions (v1 vs v2) may have different authorization implementations Output Format