Insecure Direct Object Reference in Aspnet with Firestore

An Insecure Direct Object Reference (IDOR) in an ASP.NET application that uses Cloud Firestore occurs when an API endpoint exposes a database identifier (such as a document ID or collection path) without verifying that the requesting user has permission to access that specific resource. Because Firestore paths are often predictable and identifiers are easy to enumerate, attackers can manipulate parameters like documentId or collectionName to access or modify other users’ data.

Consider an endpoint /api/users/{documentId} that retrieves a user profile from a Firestore collection users. If the endpoint only checks that the caller is authenticated but does not verify that the authenticated user owns the requested documentId, the reference is direct and insecure. An attacker can change the ID to access another user’s document. Firestore security rules can mitigate this, but they must be carefully designed; rules that allow read access based only on path structure without validating requestor identity are insufficient when the API layer does not enforce ownership checks.

In an ASP.NET backend, this often arises when server-side code constructs a Firestore reference using an input parameter without confirming the caller’s relationship to that resource. For example, using the Firebase Admin SDK with a path built directly from user input can bypass intended isolation because the Admin SDK typically has elevated privileges. Even if client-side Firestore rules restrict access, a compromised or misconfigured Admin SDK context can read or write unintended documents if the ASP.NET layer does not enforce per-request authorization. Common patterns that lead to IDOR include using sequential IDs, UUIDs that are not tied to the user, or concatenating user identifiers without ownership validation.

Real-world attack patterns include changing numeric or UUID parameters to enumerate usernames, emails, or sensitive profile fields. In systems where Firestore collections are named with user identifiers (e.g., user_data_{uid}), predictable naming can make enumeration trivial. The risk is compounded when endpoints return detailed error messages that reveal document existence, aiding reconnaissance. Because Firestore rules can be complex, subtle misconfigurations—such as allowing read if a field matches a claim but not validating the document path—can leave IDOR vulnerabilities even when rules appear restrictive.

To detect IDOR during scanning, middleBrick runs checks that compare authenticated scenarios with unauthenticated access paths and evaluate whether access control is enforced at the resource level. Findings include whether identifiers are exposed, whether server-side code validates ownership, and whether Firestore rules align with the application’s authorization model. Remediation guidance emphasizes tying every Firestore reference to the requesting user’s identity, using server-side mapping between users and document paths, and avoiding direct exposure of internal document IDs to the client.

Remediation focuses on ensuring that every Firestore access from ASP.NET is scoped to the requesting user and validated server-side. Never rely solely on Firestore security rules to enforce ownership when the Admin SDK is used, because Admin SDK bypasses many rules. Instead, enforce user-to-document mapping in application logic.

Example: retrieving a user profile safely by mapping the authenticated user’s UID to a document path rather than trusting a client-supplied ID.

// Good: map authenticated user to their document path
[HttpGet("profile")]
public async Task<IActionResult> GetProfile()
{
    var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    if (string.IsNullOrEmpty(userId))
        return Unauthorized();

    var db = _firestoreDb;
    DocumentReference docRef = db.Collection("users").Document(userId);
    DocumentSnapshot snapshot = await docRef.GetSnapshotAsync();
    if (!snapshot.Exists)
        return NotFound();

    var profile = snapshot.ConvertTo<UserProfile>();
    return Ok(profile);
}

Example: updating a document with ownership check using a user-supplied document ID that is validated against a mapping stored in the user’s document.

// Good: validate that the requested settingsId belongs to the user
[HttpPut("settings/{settingsId}")]
public async Task<IActionResult> UpdateSettings(string settingsId, [FromBody] SettingsData data)
{
    var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    if (string.IsNullOrEmpty(userId))
        return Unauthorized();

    var db = _firestoreDb;
    // Fetch the user document to verify allowed settingsId
    DocumentReference userRef = db.Collection("users").Document(userId);
    DocumentSnapshot userSnap = await userRef.GetSnapshotAsync();
    if (!userSnap.Exists)
        return Unauthorized();

    // Assume user document contains an array/map of allowed setting IDs
    var allowedSettings = userSnap.GetValue<List<string>>("allowedSettings");
    if (allowedSettings == null || !allowedSettings.Contains(settingsId))
        return Forbid();

    DocumentReference settingsRef = db.Collection("user_settings").Document(settingsId);
    await settingsRef.SetAsync(data);
    return NoContent();
}

Example: using Firestore transactions to ensure consistency when linking resources to a user.

// Good: create a user-owned document within a transaction
[HttpPost("records")]
public async Task<IActionResult> CreateRecord([FromBody] RecordInput input)
{
    var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    if (string.IsNullOrEmpty(userId))
        return Unauthorized();

    var db = _firestoreDb;
    var recordRef = db.Collection("users").Document(userId).Collection("records").Document();
    var newRecord = new Record { Name = input.Name, CreatedAt = Timestamp.GetCurrentTimestamp() };

    await db.RunTransactionAsync(async transaction =>
    {
        transaction.Set(recordRef, newRecord);
        // Optionally update a user-side summary field
        var userRef = db.Collection("users").Document(userId);
        transaction.Update(userRef, "recordCount", FieldValue.Increment(1));
    });

    return CreatedAtAction(nameof(GetRecord), new { id = recordRef.Id }, newRecord);
}

These examples emphasize scoping Firestore operations to the authenticated user, validating inputs against server-side mappings, and avoiding direct use of raw IDs supplied by the client. middleBrick’s scans can surface IDOR indicators by correlating endpoint behavior with authentication states and Firestore access patterns; findings include specific remediation steps such as these mapping patterns and server-side authorization checks.