Test for Insecure Direct Object References

IDOR Vulnerability Testing is a skill for assessing Insecure Direct Object Reference weaknesses in web applications. It covers database records and static files whose identifiers appear in user-controlled requests. The assessment follows application object references, compares access across test-user contexts, documents access-control failures, and develops remediation recommendations.

The workflow distinguishes references in URL paths, query parameters, request bodies, file names, and GUID or UUID values. It considers profile, order, invoice, document, message, and address endpoints, together with file downloads. Detection topics include parameter and request-body manipulation, HTTP method differences, and enumeration. Burp Suite supports both manual request inspection and automated payload workflows, including cases where the same identifier occurs in multiple request positions.

Response analysis separates a potentially successful request from confirmed ownership failure. A successful response requires verification that the data belongs to the other test account. Forbidden responses indicate access control, missing resources differ from unauthenticated requests, and server errors may indicate validation issues. Impact analysis distinguishes horizontal user-to-user access from vertical user-to-admin access.

Remediation focuses on server-side ownership checks, authenticated-user filtering, and indirect references. Client-provided resource identifiers do not replace authorization. Filter an address query by the authenticated user:

# Instead of: /api/address/123
# Use: /api/address/current-user/billing

def get_address(request):
    # Always filter by authenticated user
    address = Address.objects.filter(user=request.user).first()
    return address

Use it for authorized assessments, defensive validation, and controlled educational environments where an application exposes user-specific resources. Written permission from the system owner is mandatory. Real user data must not be accessed, modified, or exfiltrated, and findings must follow proper disclosure channels.

Before any target-probing, exploitation, data extraction, state-changing, persistence, or credential-access command, the workflow requires an exact target, confirmed written authorization and scope, proposed commands, and an explanation of their effects. Execution waits for explicit confirmation in the current conversation. Without confirmation, activity remains read-only and defensive, preferably in a sandbox, disposable VM, or controlled lab.

At least two valid test accounts are needed for cross-user verification. Session-bound tokens, hard-to-enumerate identifiers, rate limits, and chained vulnerabilities can limit assessment. Blind, asynchronous time-based, and WebSocket IDOR may be harder to confirm through direct responses.

Inputs include the target application URL, approved scope, multiple test accounts, an intercepting proxy, and knowledge of application flow and object-reference formats. Outputs include a vulnerability report, proof-of-concept evidence across user contexts, affected endpoints and parameters, severity classification, and specific fixes. All activities and findings are documented.

Verification can use uniquely identifiable data in the second test account, ownership markers, creation dates, and metadata. Response-length and timing differences are secondary indicators rather than a replacement for ownership evidence. Troubleshooting covers consistently forbidden requests, UUID references, session-bound resources, rate-limited enumeration, and unclear impact. The assessment examples span profile access, address updates, receipts, repeated identifier positions, and role boundaries.

Burp Suite or another intercepting proxy is used for request capture and manipulation. Django-style remediation uses ownership validation, user-filtered queries, and protected receipt downloads to address application-side access-control failures.