Mass Assignment in Aspnet with Firestore

Mass assignment in an ASP.NET context with Google Cloud Firestore as the backend occurs when an application binds user-supplied JSON or form data directly to a model or document object that is then written to Firestore. Because Firestore documents are schemaless and often represented in .NET as POCOs (Plain Old CLR Objects), developers may map incoming request payloads to these objects using model binders without explicit allow-listing of properties.

This pattern becomes dangerous when the model contains fields that should be immutable or server-controlled, such as identifiers, roles, permissions, tenant IDs, or version numbers. If an attacker can add unexpected properties to the request, they may overwrite sensitive fields in the Firestore document. For example, a user profile update endpoint that accepts a JSON payload and calls SetAsync on a DocumentReference can inadvertently allow elevation of privilege if the payload includes a IsAdmin field that maps to the document.

The risk is compounded by Firestore’s flexible data model: unlike a relational schema with strict column constraints, new fields can be added or existing fields overwritten unless the application enforces property-level validation. When using ASP.NET Core’s default model binding, public settable properties are candidates for population, which may include fields that should be ignored during updates. Without explicit filtering or allow-listing, an attacker can inject or modify fields that affect authorization, ownership, or data integrity in Firestore.

Consider an endpoint designed to update user settings that maps to a UserSettings class. If the class accidentally exposes a writable IsPremium property and the binding does not exclude it, an attacker can include "isPremium": true in the request to gain unintended benefits. Firestore will persist this change because the SDK treats the deserialized object as a plain map when using SetAsync with an object or Document class, making it a direct path to data tampering.

In automated scanning, middleBrick checks for these issues by correlating the unauthenticated attack surface of the API with the OpenAPI specification and runtime behavior. It flags endpoints that accept broad input and interact with Firestore-style backends where mass assignment can lead to privilege escalation or unauthorized data modification, aligning with findings in categories such as BOLA/IDOR and BFLA/Privilege Escalation.

To mitigate mass assignment in ASP.NET when working with Firestore, explicitly control which properties are bound and how data is written. Prefer using a DTO (Data Transfer Object) that includes only the fields intended for client updates, and map to Firestore documents with care.

Example 1 — Using a DTO and explicit mapping to avoid unwanted fields:

// DTO for incoming updates
public class UpdateUserSettingsDto
{
    public string Theme { get; set; }
    public int NotificationLevel { get; set; }
}

// In the controller
[HttpPut("settings")]
public async Task UpdateSettings(UpdateUserSettingsDto dto)
{
    var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    if (userId == null) return Unauthorized();

    var docRef = _firestoreDb.Collection("users").Document(userId);
    var update = new Dictionary<string, object>
    {
        { "theme", dto.Theme },
        { "notificationLevel", dto.NotificationLevel },
        { "updatedAt", Timestamp.GetCurrentTimestamp() }
    };
    await docRef.UpdateAsync(update);
    return Ok();
}

Example 2 — Using model binding with BindNever to protect server-side properties when using a domain model directly:

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

    [BindNever]
    public string InternalRole { get; set; }

    [BindNever]
    public bool IsAdmin { get; set; }
}

[HttpPatch("profile")]
public async Task<IActionResult> PatchProfile([BindProperty(IncludeProperties = "DisplayName,Email")] UserProfile profile)
{
    var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    if (userId == null) return Unauthorized();

    var docRef = _firestoreDb.Collection("users").Document(userId);
    var updates = new Dictionary<string, object>
    {
        { "displayName", profile.DisplayName },
        { "email", profile.Email }
    };
    await docRef.UpdateAsync(updates);
    return Ok();
}

Example 3 — Using Firestore transactions to enforce server-side validation when reading and writing:

var docRef = _firestoreDb.Collection("accounts").Document(accountId);
await _firestoreDb.RunTransactionAsync(async transaction =>
{
    var snapshot = await transaction.GetSnapshotAsync(docRef);
    if (snapshot.Exists)
    {
        // Apply only intended fields, ignore any client-supplied keys
        var updates = new Dictionary<string, object>
        {
            { "balance", ComputeNewBalance(snapshot) },
            { "lastModified", Timestamp.GetCurrentTimestamp() }
        };
        transaction.Update(docRef, updates);
    }
});

In all cases, avoid binding raw request bodies directly to Firestore document objects. Prefer explicit field selection and server-side computation for sensitive values. middleBrick’s scans validate that endpoints handling Firestore interactions do not expose mass assignment risks by checking for proper input validation and property authorization within the 12 parallel security checks.