Idor Enumeration Attack

Idor Enumeration is a systematic attack technique where an attacker discovers and maps the internal identifier structure of a system. Rather than exploiting a single vulnerability, the attacker gathers intelligence about how identifiers are generated, formatted, and sequenced to expand their access beyond the initially compromised resource.

The attack typically begins when an attacker obtains a valid identifier through various means: exploiting another vulnerability, observing network traffic, analyzing API responses, or simply guessing common patterns. Once they have one valid identifier, they analyze its structure to understand the underlying pattern.

Attackers look for several key characteristics in identifiers:

• Sequential patterns: Auto-incrementing integers (1, 2, 3, 4...)
• Time-based patterns: Timestamps, dates, or sequential generation
• Format patterns: UUID versions, prefix/suffix conventions, character sets
• Business logic patterns: User IDs, order numbers, invoice numbers

Common identifier formats include:

Sequential:          1001, 1002, 1003, 1004
UUID v4:           550e8400-e29b-41d4-a716-446655440000
Time-based UUID:    2a3b4c5d-6e7f-8a9b-0c1d-2e3f4a5b6c7d
Business pattern:   ORD-2024-0001, INV-2024-0001
Hashed IDs:         a3f9e2c1b4d8e7f6a5b4c3d2e1f0a9b8

Once the pattern is understood, attackers systematically enumerate through the identifier space. This might involve incrementing numbers, generating valid UUIDs, or manipulating format components. The goal is to discover additional valid identifiers that grant access to other users' resources.

Real-world examples demonstrate the severity of this technique. In 2022, a major e-commerce platform suffered a breach where attackers enumerated order IDs in the format ORD-YYYY-NNNN, discovering thousands of valid orders across multiple customers. Another case involved a healthcare portal where patient IDs followed a predictable pattern based on registration dates, allowing attackers to access complete medical records.

APIs are particularly vulnerable to Idor Enumeration because they expose identifier-based endpoints directly to clients. Unlike traditional web applications with complex navigation, APIs often use straightforward RESTful patterns that make enumeration straightforward.

Consider a typical API endpoint pattern:

GET /api/users/{userId}/profile
GET /api/orders/{orderId}/details
GET /api/documents/{documentId}/content
GET /api/invoices/{invoiceId}/pdf

When these endpoints lack proper authorization checks, an attacker who discovers one valid identifier can systematically enumerate through the space. The API's predictable structure and lack of human interface make automated enumeration highly effective.

Attackers employ several techniques specifically for API enumeration:

• Sequential number testing: Incrementing numeric IDs (1001, 1002, 1003...)
• UUID generation: Creating valid UUIDs to test for existence
• Format manipulation: Changing date components, prefixes, or suffixes
• Batch enumeration: Using tools to test thousands of identifiers rapidly

Common API enumeration patterns include:

GET /api/users/1001/profile    
GET /api/users/1002/profile    
GET /api/users/1003/profile    
...

GET /api/orders/ORD-2024-0001/details
GET /api/orders/ORD-2024-0002/details
GET /api/orders/ORD-2024-0003/details
...

GET /api/documents/doc_001234
GET /api/documents/doc_001235
GET /api/documents/doc_001236
...

The attack becomes particularly dangerous when combined with other API vulnerabilities. For example, an attacker might first exploit an authentication bypass to get one valid user ID, then enumerate through all user IDs to build a complete database of user information. Or they might discover a valid order ID through a separate vulnerability, then enumerate through related order IDs to access competitors' order information.

API-specific enumeration also includes testing for different response behaviors. Some systems return different HTTP status codes for valid vs invalid identifiers (200 OK vs 404 Not Found), while others return different error messages. These subtle differences help attackers map the identifier space more efficiently.

Detecting Idor Enumeration requires monitoring for unusual access patterns and implementing proper authorization controls. Security teams should watch for:

• Rapid sequential access: Multiple requests with incrementing identifiers in short timeframes
• Unusual identifier patterns: Requests with identifiers that don't match the user's known resources
• Cross-user access attempts: Requests for resources that belong to other users
• Invalid identifier patterns: Systematic testing of malformed or out-of-range identifiers

Prevention requires a defense-in-depth approach. The most critical control is proper authorization checking on every API endpoint that accesses user-specific resources. Each request must verify that the authenticated user has permission to access the specific resource being requested.

Implementation patterns for authorization include:

// Insecure: Only checks if user is authenticated
async function getUserProfile(req, res) {
  const userId = req.params.userId;
  const profile = await db.getUserProfile(userId);
  res.json(profile);
}

// Secure: Verifies resource ownership
async function getUserProfile(req, res) {
  const requestedUserId = req.params.userId;
  const authenticatedUserId = req.user.id;
  
  if (requestedUserId !== authenticatedUserId) {
    return res.status(403).json({ error: 'Access denied' });
  }
  
  const profile = await db.getUserProfile(requestedUserId);
  res.json(profile);
}

Additional preventive measures include:

• Rate limiting: Throttle requests per user/IP to slow down enumeration attempts
• Consistent error responses: Return uniform responses for both valid and invalid identifiers to prevent information leakage
• Access logging: Log all resource access attempts with user context for audit trails
• Input validation: Validate identifier formats and ranges before processing
• Resource ownership verification: Always check that the requested resource belongs to the authenticated user

Security testing tools can help identify Idor vulnerabilities. middleBrick scans APIs for authorization weaknesses including Idor vulnerabilities. The scanner tests endpoints with various identifier patterns and verifies proper authorization controls are in place. Unlike traditional penetration testing that might take weeks, middleBrick provides results in 5–15 seconds with a security risk score and specific findings about authorization gaps.

Continuous monitoring is essential since new Idor vulnerabilities can be introduced with code changes. Integrating security scanning into CI/CD pipelines ensures that authorization checks aren't accidentally removed or bypassed during development. The middleBrick GitHub Action can automatically scan staging APIs before deployment, failing builds if critical authorization issues are detected.