Prototype Pollution in Aspnet with Firestore

Prototype pollution in ASP.NET applications using Google Cloud Firestore typically occurs when user-controlled input is merged into server-side objects that are later used to build Firestore document writes or queries. Because JavaScript-style object manipulation is not native to .NET, pollution often arises through JSON deserialization or dynamic dictionaries (e.g., System.Text.Json or Newtonsoft.Json) that map incoming JSON into Dictionary<string, object> or ExpandoObject. If these dictionaries are recursively merged or used to construct Firestore DocumentReference.SetAsync() payloads without strict validation, attacker-controlled properties like __proto__, constructor.prototype, or nested keys can introduce fields that affect object behavior elsewhere in the server process or downstream client deserialization.

In the context of Firestore, prototype pollution does not directly modify Firestore documents stored on Google’s servers—document schemas are enforced at write time. However, pollution can corrupt in-memory representations before data is sent to Firestore, leading to malformed writes, unintended field injection (e.g., injecting metadata fields that bypass application-level authorization checks), or query logic manipulation. For example, if an endpoint builds a document dictionary from polluted input and calls SetAsync(), an injected __type or __v field might change how the document is interpreted by other services or deserialized clients, potentially bypassing property-level authorization checks modeled after OWASP API Security Top 10:2023 Broken Object Level Authorization (BOLA).

Because Firestore operations often rely on structured dictionaries for batch writes or dynamic field updates, an ASP.NET endpoint that merges request data into these dictionaries without deep copying or schema validation can propagate polluted properties into document payloads. This can also affect runtime behavior when the polluted object is used to construct Firestore queries (e.g., injecting a $where-like pseudo-field that changes filtering logic in application code). MiddleBrick scans detect such patterns by correlating OpenAPI/Swagger definitions (including $ref resolution across spec versions) with runtime inputs that map to Firestore-related operations, highlighting insecure deserialization and missing property authorization as high-severity findings aligned with compliance frameworks such as OWASP API Top 10 and SOC2.

LLM/AI Security checks are particularly relevant here because attackers may attempt prompt injection or jailbreak techniques to coerce API endpoints into generating or manipulating Firestore-related payloads that include malicious object properties. middleBrick’s active prompt injection testing (system prompt extraction, instruction override, DAN jailbreak, data exfiltration, and cost exploitation probes) and output scanning for PII or executable code help identify risks where AI-assisted code generation or API interaction might inadvertently propagate polluted structures to Firestore operations. These checks complement the 12 parallel security assessments—Authentication, BOLA/IDOR, BFLA/Privilege Escalation, Property Authorization, Input Validation, Rate Limiting, Data Exposure, Encryption, SSRF, Inventory Management, Unsafe Consumption, and LLM/AI Security—ensuring that prototype pollution paths are surfaced before deployment.

To mitigate prototype pollution in ASP.NET when working with Firestore, enforce strict input validation and avoid recursive merging of untrusted data into dictionaries used for Firestore writes. Prefer strongly typed models with System.Text.Json deserialization configured to disallow polymorphic deserialization and ignore extra properties. When dynamic updates are necessary, deep-copy and validate the dictionary before passing it to Firestore operations.

Example: Safe Firestore document write with validated input

using Google.Cloud.Firestore;
using System.Text.Json;

public class FirestoreService
{
    private readonly FirestoreDb _db;

    public FirestoreService()
    {
        _db = FirestoreDb.Create("my-project");
    }

    public async Task SetDocumentSafeAsync(string collection, string documentId, JsonElement userInput)
    {
        // Validate and project only allowed fields
        var allowedFields = new HashSet<string> { "name", "email", "settings" };
        var documentData = new Dictionary<string, object>();

        foreach (var property in userInput.EnumerateObject())
        {
            if (!allowedFields.Contains(property.Name)) continue;
            // Map JSON primitives safely; avoid recursive merging
            if (property.Value.ValueKind == JsonValueKind.String)
            {
                documentData[property.Name] = property.Value.GetString();
            }
            else if (property.Value.ValueKind == JsonValueKind.Number)
            {
                documentData[property.Name] = property.Value.GetInt64();
            }
            // Add more controlled mappings as needed
        }

        DocumentReference docRef = _db.Collection(collection).Document(documentId);
        await docRef.SetAsync(documentData);
    }
}

Example: Using a DTO to avoid dynamic dictionary pollution

using Google.Cloud.Firestore;
using System.Text.Json;

public class UserProfile
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Settings { get; set; }
}

public async Task SetDocumentWithDto(string collection, string documentId, string json)
{
    var options = new JsonSerializerOptions
    {
        PropertyNameCaseInsensitive = true,
    };
    // Disallow extra properties and polymorphic deserialization by default
    var profile = JsonSerializer.Deserialize<UserProfile>(json, options);
    if (profile == null) throw new ArgumentException("Invalid data");

    var data = new Dictionary<string, object>
    {
        { "name", profile.Name },
        { "email", profile.Email },
        { "settings", profile.Settings }
    };

    await _db.Collection(collection).Document(documentId).SetAsync(data);
}

For dynamic updates, always deep-copy the dictionary and sanitize keys before merging. Avoid using ExpandoObject or JavaScriptSerializer-style patterns that may inadvertently allow prototype chain manipulation. Apply the principle of property-level authorization by validating each field against the user’s permissions before including it in a Firestore write, ensuring that injected fields cannot bypass BOLA checks. The Pro plan’s continuous monitoring can help detect anomalous write patterns that may indicate attempted pollution, while the GitHub Action can enforce a minimum security score before allowing deployments that include Firestore interactions.

When leveraging the MCP Server to scan APIs directly from your AI coding assistant, ensure that generated Firestore code follows these strict validation patterns. middleBrick’s dashboard can track security scores over time and the CLI can integrate into scripts to fail builds if risk scores drop due to insecure deserialization or missing property authorization, aligning with compliance mappings for OWASP API Top 10, PCI-DSS, and SOC2.