Type Confusion in APIs

Type confusion is a class of vulnerability that occurs when an application incorrectly interprets data as a different type than intended. In strongly typed languages like TypeScript, Java, or C#, type systems exist to prevent this kind of error. However, in dynamically typed languages like JavaScript or Python, or when type checking is bypassed, type confusion can lead to serious security issues.

The vulnerability manifests when an API accepts input that should be one type but is interpreted as another. For example, an API endpoint might expect a string for a user ID but receives an array, or expects a number but gets an object. This mismatch can cause the application to behave in unexpected ways, potentially exposing sensitive data or allowing unauthorized operations.

Type confusion often occurs at API boundaries where input validation is lax or when polymorphic behavior is exploited. Attackers can craft payloads that exploit these type mismatches to bypass security controls, access unauthorized data, or trigger application errors that reveal information.

Type confusion in APIs can lead to several dangerous attack scenarios. One common pattern is when an API expects a numeric ID but receives an object with properties. For instance, if an endpoint expects a user ID but receives { "id": 123, "isAdmin": true }, the application might interpret this as valid and grant elevated privileges.

Another scenario involves array/object confusion. An API might expect a single value but receives an array, causing the application to process all elements unexpectedly. This can lead to batch operations being performed without proper authorization checks, or database queries returning more data than intended.

Type confusion can also bypass input validation. If an API validates that a field is a string but receives an object with a toString() method, the application might convert it and accept malicious input. Similarly, numeric comparisons can be bypassed if strings containing numbers are accepted where only integers should be valid.

In JSON APIs, type confusion often occurs when the client sends different data structures than the server expects. The server's deserialization logic might not properly validate the incoming structure, leading to unexpected behavior when the application processes the malformed data.

Detecting type confusion requires both static analysis and dynamic testing. Static analysis tools can examine code to identify places where type checking is insufficient or where polymorphic behavior might lead to type mismatches. Look for functions that accept generic types without proper validation, or where type assertions are used without verification.

Dynamic testing involves sending intentionally malformed payloads to API endpoints. Test with various type combinations: send objects where arrays are expected, arrays where objects are expected, strings where numbers are expected, and vice versa. Monitor how the application responds and whether it processes the data in unexpected ways.

middleBrick scans for type confusion vulnerabilities by testing API endpoints with malformed payloads that target common type confusion patterns. The scanner sends inputs with incorrect types to see if the API processes them without proper validation. For example, it might send an object where a string is expected, or an array where a single value is expected, then analyzes the response for signs of improper handling.

The scanner also examines OpenAPI specifications to identify endpoints where type definitions exist but might not be properly enforced at runtime. It cross-references the spec with actual behavior to find discrepancies between documented types and how the API actually processes input.

Key indicators of type confusion vulnerabilities include: application crashes or errors when receiving unexpected types, successful processing of malformed input, unexpected data being returned, or authorization bypasses when type mismatches occur.

Preventing type confusion requires rigorous input validation and type checking at API boundaries. Always validate the type and structure of incoming data before processing. For JSON APIs, use schema validation to ensure the input matches the expected structure exactly. Libraries like JSON Schema, Joi, or Zod can enforce strict type constraints.

// Vulnerable code - no type validation
app.post('/users', (req, res) => {
  const userId = req.body.userId;
  // Process without checking if userId is actually a string/number
});

// Secure code - strict type validation
app.post('/users', (req, res) => {
  const { userId } = req.body;
  if (typeof userId !== 'string' && typeof userId !== 'number') {
    return res.status(400).json({ error: 'Invalid userId type' });
  }
  // Continue processing
});

Implement strict deserialization practices. When parsing JSON or other structured data, ensure the parser enforces the expected structure and types. Avoid using generic deserialization methods that can accept any structure. Use type-safe data transfer objects (DTOs) that explicitly define the expected types and structure.

For languages that support it, use static typing throughout your codebase. TypeScript, for example, can catch many type confusion issues at compile time. Even in dynamically typed languages, consider using runtime type checking libraries to enforce type constraints.

Implement defense in depth by validating types at multiple layers. Validate at the API boundary, again in business logic, and when interacting with databases or external systems. This layered approach ensures that even if one validation layer fails, others will catch type mismatches.

Consider using the principle of least privilege for data processing. Only allow the specific types and structures that your application actually needs, and reject anything that doesn't match exactly. Be particularly cautious with polymorphic code that can handle multiple types, as this often introduces type confusion vulnerabilities.

Type confusion vulnerabilities have been implicated in several high-profile security incidents. While specific CVEs for pure type confusion in web APIs are less common than in lower-level languages, the pattern appears frequently in application logic vulnerabilities.

One notable example involved a cryptocurrency exchange where type confusion in their trading API allowed attackers to bypass balance checks. The API expected a numeric amount but received an object, and the application's comparison logic failed to properly validate the type, allowing trades to be executed without sufficient funds.

In another incident, a social media platform's API suffered from type confusion that allowed users to access others' private messages. The API expected a user ID string but received an array of IDs, and the backend query logic processed all IDs without proper authorization checks, returning data for multiple users in a single request.

Type confusion is particularly dangerous in financial and healthcare APIs where data integrity is critical. A type confusion vulnerability in a medical records API could cause patient data to be associated with the wrong record, leading to privacy violations and potential medical errors.

The OWASP API Security Top 10 includes related concepts under "Broken Object Level Authorization" (API1) and "Broken Function Level Authorization" (API2), where type confusion often plays a role in bypassing authorization checks. These vulnerabilities can have severe consequences including data breaches, unauthorized transactions, and compliance violations under regulations like GDPR, HIPAA, and PCI-DSS.