OWASP A01 : Contrôle d'Accès Défaillant et Exploitation IDOR

Dans le Top 10 de l'OWASP, Broken Access Control frequently takes the number one spot (A01). This category encompasses a wide range of vulnerabilities where an application fails to properly enforce restrictions on what authenticated users are allowed to do. Among these, Insecure Direct Object Reference (IDOR) is arguably the most prevalent and damaging subclass.

This comprehensive guide, brought to you by Cayvora Security's penetration testing team, dissects how Broken Access Control manifests, how IDOR vulnerabilities are exploited in the wild, and exact methodologies for developers to prevent them in 2025.

Understanding Broken Access Control

Access control (or authorization) is the process of granting or denying specific requests from a user, program, or process. When access control is "broken," it means a user can act outside of their intended permissions. This typically results in unauthorized information disclosure, modification or destruction of data, or performing a business function outside the user's limits.

Access control vulnerabilities usually fall into three categories:

1. Vertical Privilege Escalation: An ordinary user accessing administrative functions. (e.g., changing /user/profile to /admin/profile in the URL).
2. Horizontal Privilege Escalation: A user accessing the resources of another user with the same privilege level. This is the domain of IDOR.
3. Context-Dependent Privilege Escalation: A user performing an action out of sequence, such as skipping a payment step in an e-commerce checkout flow.

What is IDOR?

Insecure Direct Object Reference (IDOR) occurs when an application provides direct access to objects based on user-supplied input. If a developer assumes that the user will only request documents they are authorized to see, they might use the raw database ID in the URL.

Real Exploitation Example: The Financial Dashboard

Imagine a banking application where users view their monthly statements. The URL for retrieving a PDF statement looks like this:

https://bank.example.com/api/v1/statements/download?statement_id=84920

When User A logs in, the application generates a link with their specific statement_id.

L'Exploit:

An attacker (User B) logs into the application and observes their own statement URL, which ends in statement_id=84925. Recognizing the sequential nature of the IDs, the attacker simply intercepts the request using a tool like Burp Suite or modifies the URL directly in the browser:

https://bank.example.com/api/v1/statements/download?statement_id=84920

Because the backend code fetches the record corresponding to 84920 without verifying if the currently authenticated session belongs to the owner of that statement, the attacker successfully downloads the financial statement of User A.

Code Level Vulnerability

// VULNERABLE CODE (Spring Boot API Example)
@GetMapping("/statements/download")
public ResponseEntity<Resource> getStatement(@RequestParam Long statement_id) {
    // Fetches the statement simply based on the ID provided in the request
    Statement stmt = statementRepository.findById(statement_id);

    if (stmt == null) {
        return ResponseEntity.notFound().build();
    }

    // Returns the file unconditionally!
    return serveFile(stmt.getFilePath());
}

IDOR in API Endpoints and Hidden Fields

IDOR vulnerabilities are not limited to GET parameters in URLs. They frequently occur in POST bodies, REST API paths, and hidden form fields.

For example, a password reset request might send:

POST /api/user/update HTTP/1.1
Content-Type: application/json
Authorization: Bearer <Victim_Token>

{
  "user_id": 105,
  "email": "[email protected]"
}

If the backend trusts the user_id provided in the JSON payload instead of deriving it from the Bearer token, the attacker can change anyone's email address by simply iterating the user_id.

Prevention and Remediation Strategies

Preventing IDOR and Broken Access Control requires a defense-in-depth approach. You cannot rely on obfuscation or simply hiding links in the UI.

1. Implement Strict Access Control Checks

The fundamental fix for IDOR is to enforce an access control check at every single endpoint that interacts with an object.

Secure Code Example:

// SECURE CODE
@GetMapping("/statements/download")
public ResponseEntity<Resource> getStatement(@RequestParam Long statement_id, Principal principal) {

    Statement stmt = statementRepository.findById(statement_id);
    User currentUser = userRepository.findByUsername(principal.getName());

    // Critical Authorization Check
    if (stmt == null || !stmt.getOwnerId().equals(currentUser.getId())) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }

    return serveFile(stmt.getFilePath());
}

In this secure version, the server explicitly verifies that the ownerId of the requested statement matches the ID of the currently authenticated currentUser.

2. Use Indirect Object References

Instead of using the database's sequential primary key (e.g., 105, 84920), use a random, unguessable identifier like a UUID-v4 (Universally Unique Identifier).

https://bank.example.com/api/v1/statements/download?id=f47ac10b-58cc-4372-a567-0e02b2c3d479

While UUIDs do not replace access control checks (an attacker could still access the file if they somehow obtained the UUID), they massively reduce the attack surface by making it impossible to enumerate and guess valid IDs. This mitigates mass-scraping attacks.

3. Derive Identity from the Session

Never trust the client to tell the server who they are. If a user is performing an action on their own profile, do not include user_id in the request parameters or payload. Derive the user_id exclusively from the secure session token (e.g., a validated JWT or session cookie).

4. Implement Role-Based Access Control (RBAC)

For vertical privilege escalation, ensure that administrative endpoints check the user's role before proceeding. In modern frameworks, this is often handled using annotations.

The Role of Automated Testing

Automated testing tools struggle to find IDOR vulnerabilities because they cannot easily distinguish between a user accessing their own data versus someone else's data. This is why manual penetration testing by experienced security engineers is crucial.

During a penetration test, the Cayvora Security team utilizes advanced techniques like Autorize (a Burp Suite extension) to systematically test every endpoint using multiple privilege contexts simultaneously, ensuring no access control flaws slip into production.

Conclusion

Broken Access Control poses a severe threat because it bypasses all other technical security controls to strike directly at the application's core logic and data confidentiality. By mandating access control checks at the data-access layer and moving away from direct, enumerable object references, organizations can effectively neutralize IDOR attacks.