Broken Object Property Level Authorization (Mass Assignment)

Description

This vulnerability occurs when an API fails to properly validate authorization at the object property level, allowing users to access or modify object properties beyond their intended permissions. Commonly exploited through mass assignment attacks, attackers can manipulate API requests to read sensitive fields in responses or write to protected properties during create/update operations. This affects REST APIs, GraphQL endpoints, and other API architectures that expose object properties without granular authorization controls.

Remediation

Implement the following security controls to prevent unauthorized property-level access:

1. Enforce Property-Level Authorization:
Implement explicit authorization checks for each property before allowing read or write operations. Verify that the authenticated user has permission to access or modify specific properties based on their role and context.

// Example: Property-level authorization in Node.js
function updateUser(userId, updateData, currentUser) {
  const allowedFields = ['name', 'email', 'phone'];
  const adminOnlyFields = ['role', 'isActive', 'credits'];
  
  // Filter properties based on user role
  const updates = {};
  for (const [key, value] of Object.entries(updateData)) {
    if (allowedFields.includes(key)) {
      updates[key] = value;
    } else if (adminOnlyFields.includes(key) && currentUser.role === 'admin') {
      updates[key] = value;
    }
    // Silently ignore unauthorized properties
  }
  
  return User.update(userId, updates);
}

2. Use Data Transfer Objects (DTOs) with Whitelisting:
Define explicit DTOs or schemas that specify exactly which properties can be read or written for each API endpoint and user role. Avoid using automatic object serialization that exposes all model properties.

// Example: DTO-based approach in Python
from pydantic import BaseModel

class UserUpdateDTO(BaseModel):
    name: str | None = None
    email: str | None = None
    phone: str | None = None
    # Explicitly exclude sensitive fields like 'role', 'password_hash'

class AdminUserUpdateDTO(UserUpdateDTO):
    role: str | None = None
    is_active: bool | None = None
    # Admin-specific fields

@app.put("/users/{user_id}")
def update_user(user_id: int, data: UserUpdateDTO, current_user: User):
    # Only whitelisted fields from DTO can be updated
    return user_service.update(user_id, data.dict(exclude_unset=True))

3. Implement Separate Response Schemas:
Create role-specific response schemas that return only the properties appropriate for each user's authorization level. Never return the entire database model in API responses.

// Example: Role-based response filtering in Java
public class UserResponse {
    public static UserResponse fromUser(User user, Role currentUserRole) {
        UserResponse response = new UserResponse();
        response.setId(user.getId());
        response.setName(user.getName());
        response.setEmail(user.getEmail());
        
        // Only include sensitive fields for admins
        if (currentUserRole == Role.ADMIN) {
            response.setRole(user.getRole());
            response.setCreatedAt(user.getCreatedAt());
            response.setLastLogin(user.getLastLogin());
        }
        return response;
    }
}

4. Validate Input Against Schemas:
Use schema validation libraries to enforce strict input validation, rejecting requests that contain unexpected or unauthorized properties rather than silently ignoring them.

5. Apply the Principle of Least Privilege:
By default, make all properties inaccessible and explicitly grant access only to properties required for specific operations and user roles. Document which properties are accessible to which roles.

6. Conduct Regular Security Testing:
Perform API security testing specifically targeting property-level authorization, including testing with different user roles, attempting to read hidden properties, and trying mass assignment attacks with unexpected fields. Review API responses to ensure sensitive properties are not inadvertently exposed.

References