Mass Assignment in Aspnet with Bearer Tokens

Mass assignment in ASP.NET occurs when an action method accepts a complex object from model binding and directly persists it without explicitly specifying which properties should be bound. When this pattern is combined with Bearer token authentication, the risk surface changes in two important ways. First, Bearer tokens are typically transmitted in the Authorization header and are often stored in browser local storage or insecure mobile containers, making them more likely to be leaked or extracted by malicious actors or insecure third‑party code. Second, many ASP.NET APIs accept JSON payloads and use [FromBody] or implicit model binding, which maps incoming keys to public settable properties automatically.

Consider an endpoint that updates a user profile and relies on a Bearer token for identity but binds the entire request body to a domain object:

// Example vulnerable action in an ASP.NET Core controller
[Authorize(AuthenticationSchemes = "Bearer")]
[HttpPut("/api/profile")]
public IActionResult UpdateProfile(UserProfileInput model)
{
    // Dangerous: binds all incoming properties including IsAdmin
    _profileService.Update(model);
    return Ok();
}

public class UserProfileInput
{
    public string DisplayName { get; set; }
    public string Email { get; set; }
    public bool IsAdmin { get; set; }
    public string Role { get; set; }
}

An attacker who steals or guesses a valid Bearer token can send a crafted PATCH/PUT request that includes extra properties such as IsAdmin or Role. Because the model binder populates all public settable properties, the server may unintentionally elevate privileges or change authorization-relevant fields. This becomes a BOLA/IDOR-like issue when the token identifies a user but the bound model allows that user to modify attributes they should not control. In addition, if the API also exposes sensitive data fields in responses (Data Exposure), a stolen token paired with overly permissive binding can lead to both unauthorized modification and unintended data disclosure.

The interaction with OpenAPI/Swagger exacerbates the issue when specs define request bodies that include sensitive properties without explicit bind exclusions. If the spec references definitions that contain IsAdmin, Role, or internal identifiers, and runtime behavior mirrors the spec, an attacker can infer which fields are mutable. Because middleBrick scans OpenAPI 2.0/3.0/3.1 specs and cross-references them with runtime behavior, it can highlight mismatches where model definitions permit more input than intended.

Mass assignment in this context is not just about binding quantity; it is about the trust boundary created by Bearer tokens. Tokens often carry scopes or claims that indicate permissions, but if the server relies solely on token presence rather than validating which properties a given subject may change, the authorization boundary is effectively bypassed. This aligns with BOLA/IDOR patterns where object-level authorization is missing, and with BFLA/Privilege Escalation when assignment enables privilege elevation.

Remediation centers on explicit whitelisting of bindable properties and enforcing per-user authorization on object ownership. Prefer [Bind] or explicit models for input, and validate that the resource being modified belongs to the identity represented by the Bearer token.

1. Use explicit models and Bind

Define an input model that includes only the properties that are safe to bind, and apply [Bind] to exclude sensitive fields:

[Authorize(AuthenticationSchemes = "Bearer")]
[HttpPut("/api/profile")]
public IActionResult UpdateProfile([Bind(Include = "DisplayName,Email")] UserProfileInput model)
{
    var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    _profileService.UpdateProfile(userId, model.DisplayName, model.Email);
    return NoContent();
}

public class UserProfileInput
{
    public string DisplayName { get; set; }
    public string Email { get; set; }
}

By excluding IsAdmin, Role, and other sensitive properties from the bind list, the server ignores any attacker-supplied values for those keys even if they are present in the JSON payload.

2. Apply per-object ownership checks

After binding only safe properties, verify that the resource belongs to the authenticated subject. This prevents IDOR despite the presence of a valid Bearer token:

[Authorize(AuthenticationSchemes = "Bearer")]
[HttpPut("/api/users/{id}")]
public async Task<IActionResult> UpdateUser(Guid id, [FromBody] UserUpdateInput input)
{
    var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    if (userId == null || !Guid.TryParse(userId, out var uid) || id != uid)
    {
        return Forbid();
    }
    // Proceed with update using input (which should also be bound explicitly)
    await _userService.UpdateAsync(id, input.Email, input.DisplayName);
    return NoContent();
}

public class UserUpdateInput
{
    public string Email { get; set; }
    public string DisplayName { get; set; }
}

This ensures that even with a valid Bearer token, a user cannot modify another user’s resource. Combine this with explicit binding to mitigate both mass assignment and BOLA/IDOR risks.

3. Use [ApiController] and automatic 400 responses

ASP.NET Core’s [ApiController] attribute enables automatic model state validation, which returns a 400 response when binding encounters issues. While this does not prevent over-posting by itself, it encourages explicit contract definitions and makes misconfigurations more visible during development:

[ApiController]
[Route("api/[controller]")]
[Authorize(AuthenticationSchemes = "Bearer")]
public class ProfileController : ControllerBase
{
    [HttpPut]
    public IActionResult Update([FromBody] ProfileUpdateRequest request)
    {
        // request includes only explicitly defined properties
        // server-side mapping to domain ensures no unwanted setters
        return Ok();
    }
}

public class ProfileUpdateRequest
{
    public string DisplayName { get; set; }
    public string Bio { get; set; }
}

For production, always pair this with explicit mapping to domain models and ownership checks. middleBrick can validate that your API spec and runtime behavior do not inadvertently allow broader binding than intended.