Insecure Direct Object References (IDOR)

Technical Description

Insecure Direct Object References (IDOR) occur when an application exposes internal object identifiers (database primary keys, filenames, UUIDs, or other references) in API endpoints, URLs, or request parameters and fails to verify that the authenticated user is authorized to access the referenced object. The vulnerability is fundamentally an access control failure: the application authenticates who the user is but does not authorize whether they should access the specific resource.

Consider an API endpoint for retrieving user profiles:

GET /api/users/1042/profile
Authorization: Bearer <valid_token_for_user_1042>

If changing the ID to 1043 returns another user’s profile without any authorization check, the application is vulnerable to IDOR. This pattern appears across numerous resource types:

• Horizontal IDOR: Accessing resources belonging to other users at the same privilege level (e.g., viewing another customer’s order at /api/orders/5678).
• Vertical IDOR: Accessing resources belonging to users at a higher privilege level (e.g., accessing admin configurations through predictable identifiers).
• Object Manipulation IDOR: Not just reading but modifying or deleting resources belonging to other users (e.g., PUT /api/users/1043/email to change another user’s email address).

IDOR is deceptively simple but pervasive because modern applications expose hundreds or thousands of API endpoints, each with multiple object references, and authorization checks must be implemented consistently at every single one. A single missing check creates a vulnerability.

Sequential integer IDs make exploitation trivial, but UUIDs do not prevent IDOR. If UUIDs leak through other features (search results, shared links, error messages, or other API responses), they become just as exploitable.

Real-World Impact

IDOR vulnerabilities have caused massive data exposures:

• First American Financial (2019): An IDOR vulnerability exposed approximately 885 million sensitive financial records, including bank account numbers, Social Security numbers, and mortgage documents. Simply decrementing the document ID in the URL granted access to any document in the system.
• Parler (2021): IDOR in the social media platform’s API allowed researchers to sequentially download every public and private post, including deleted content, GPS-tagged media, and identity verification documents.
• T-Mobile (2017): An IDOR in T-Mobile’s API exposed customer account details including phone numbers, email addresses, and account PINs.

Bug bounty programs consistently report that IDOR is among the most frequently submitted vulnerability types. It is commonly found in e-commerce order lookups, healthcare patient portals, financial dashboards, and multi-tenant SaaS platforms.

Detection Methodology

IDOR detection requires systematic authorization testing:

1. Multi-Account Testing: Create at least two accounts at each privilege level. For every API endpoint that accepts an object identifier, authenticate as User A and attempt to access User B’s resources.
2. Parameter Enumeration: Identify every object reference in URLs, query parameters, POST bodies, and headers. Test each one by substituting IDs from another account.
3. Sequential ID Probing: For endpoints using integer IDs, test adjacent values. For UUIDs, collect identifiers from various API responses and cross-reference them between accounts.
4. HTTP Method Variation: If GET /api/resource/123 is properly protected, test PUT, PATCH, DELETE, and POST methods on the same endpoint. Authorization checks are frequently missing on write operations.
5. Indirect References: Test for IDOR through indirect vectors: file download endpoints, export functions, email notification triggers, and webhook configurations that reference other users’ data.

How Revaizor Discovers This

Revaizor’s AI agents systematically test for IDOR with a methodology that mirrors expert manual testing:

• Multi-Session Architecture: Revaizor provisions multiple authenticated sessions across different user roles and privilege levels. It then cross-tests every discovered API endpoint, attempting to access resources from one session using identifiers obtained from another.
• Automatic Object Reference Tracking: As Revaizor’s agents interact with the application, they catalog every object identifier encountered in responses, building a mapping of resource types to their identifiers. This catalog feeds targeted cross-account access attempts.
• Write Operation Testing: Revaizor does not stop at read access. It tests whether unauthorized users can modify, delete, or create resources through IDOR, identifying object manipulation vulnerabilities that have the highest business impact.
• Business Logic Context: Revaizor understands application workflows and tests IDOR in multi-step processes, such as changing the order ID during checkout, swapping document IDs during a signing workflow, or modifying recipient IDs in payment flows.

Remediation

The fundamental fix for IDOR is server-side authorization enforcement on every resource access:

# Vulnerable - no authorization check
@app.route('/api/orders/<order_id>')
@login_required
def get_order(order_id):
    order = Order.query.get(order_id)
    return jsonify(order.to_dict())

# Secure - scoped to authenticated user
@app.route('/api/orders/<order_id>')
@login_required
def get_order(order_id):
    order = Order.query.filter_by(
        id=order_id,
        user_id=current_user.id  # Authorization enforcement
    ).first_or_404()
    return jsonify(order.to_dict())

Comprehensive IDOR prevention includes:

• Indirect Object References: Map internal IDs to per-session opaque tokens. The server maps the token back to the real ID after verifying authorization. This eliminates ID enumeration.
• Centralized Authorization Layer: Implement access control checks in middleware or a dedicated authorization service rather than relying on individual endpoint implementations. Frameworks like OPA (Open Policy Agent) or CASL can enforce consistent policies.
• Automated Authorization Testing: Integrate IDOR testing into your CI/CD pipeline. For every API endpoint, automatically verify that cross-account access is denied.
• Rate Limiting and Monitoring: Even with proper authorization, monitor for enumeration patterns (sequential ID access attempts) as an early warning of IDOR exploitation attempts.
• Avoid Exposing Internal IDs: Where possible, use UUIDs instead of sequential integers to make enumeration harder, but never rely on ID obscurity as the sole control.