Pii Leakage in Aspnet with Firestore

When an ASP.NET application integrates with Google Cloud Firestore, PII leakage often arises from insecure data modeling, overly permissive Firestore rules, and insufficient server-side filtering. Firestore stores documents in collections and subcollections; if the security rules do not enforce ownership and least-privilege access, one user can read or export another user’s data by manipulating document IDs or queries. In ASP.NET, this commonly occurs when the backend builds Firestore queries using user-supplied identifiers without validating that the resource belongs to the requesting user or tenant.

For example, consider a profile endpoint that retrieves a user document by concatenating a user-provided UID with a fixed collection name. If the endpoint trusts the client-supplied UID and does not cross-check it with the authenticated identity from the ASP.NET authentication context (e.g., claims from Identity or JWT), an attacker can enumerate or modify the UID to access other users’ PII such as email, phone, or address fields stored in Firestore documents.

Additionally, Firestore’s flexible schema can inadvertently expose PII when fields like email, phone, or ssn are stored in plaintext and the rules permit broad read access. Insecure rules that use allow read: if true; or that only check the existence of a document without validating ownership are a common root cause. Even when the ASP.NET layer performs some checks, missing validation on array fields or nested maps can allow sensitive data to be returned to unauthorized clients, especially if the client queries a collection group without proper constraints.

Another vector specific to Firestore is over-fetching via collection group queries. If an ASP.NET service uses a collection group read (e.g., querying all profiles across subcollections) without scoping by tenant or user ID, it may return PII belonging to many users. This risk is amplified when indexes are misconfigured or when the service merges results from multiple queries without applying strict access controls. PII leakage can also occur through error messages or logs when Firestore exceptions expose document paths or internal identifiers.

Effective mitigation requires combining ASP.NET identity checks with rigorously designed Firestore security rules. Rules should scope reads and writes to documents where the resource’s owner ID matches the authenticated user’s UID, and should reject collection group queries unless explicitly required and safe. On the ASP.NET side, always derive document references from the authenticated user’s claim, avoid using raw client input to form document paths, and apply server-side field filtering to limit returned data to what is strictly necessary.

Remediation centers on two pillars: secure Firestore security rules and disciplined server-side handling in ASP.NET. On the Firestore rules side, enforce ownership checks using request.auth and document-level fields. Avoid wildcards that permit broad access, and prefer rules that explicitly define create, read, update, and delete per collection or subcollection.

Example Firestore security rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only read/write their own profile document
    match /profiles/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    // Posts owned by the user; comments are subcollections with similar ownership
    match /posts/{postId} {
      allow read, write: if request.auth != null && request.auth.uid == request.resource.data.userId;
      match /comments/{commentId} {
        allow read, write: if request.auth != null && request.auth.uid == request.resource.data.userId;
      }
    }
    // Deny collection group reads unless explicitly scoped and safe
    match /restricted/{doc=**} {
      allow read: if false;
    }
  }
}

ASP.NET example with explicit ownership check

In your ASP.NET controller or service, resolve the document reference from the authenticated user’s UID rather than from client input. Use the Firebase Admin SDK or the appropriate Firestore client to build a safe reference.

using Google.Cloud.Firestore;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class ProfileController : ControllerBase
{
    private readonly FirestoreDb _firestore;

    public ProfileController(FirestoreDb firestore)
    {
        _firestore = firestore;
    }

    [HttpGet("{userId}")]
    [Authorize]
    public async Task<ActionResult<UserProfile>> GetProfile(string userId)
    {
        // Use the authenticated user's UID from claims, not from route/query
        var userIdentity = User.FindFirst(System.Security.Claims.ClaimTypes.NameIdentifier)?.Value;
        if (string.IsNullOrEmpty(userIdentity) || userIdentity != userId)
        {
            return Forbid();
        }

        DocumentReference docRef = _firestore.Collection("profiles").Document(userId);
        DocumentSnapshot snapshot = await docRef.GetSnapshotAsync();
        if (!snapshot.Exists)
        {
            return NotFound();
        }

        // Explicitly map only needed fields to avoid over-exposure
        var profile = new UserProfile
        {
            DisplayName = snapshot.GetValue("displayName"),
            Email = snapshot.GetValue("email"),
            // Do not include sensitive fields like SSN or phone unless explicitly required and permitted
        };
        return Ok(profile);
    }
}

public class UserProfile
{
    public string DisplayName { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
}

Additional hardening steps include: using Firestore’s select-like field masks on the server to limit returned fields, avoiding collection group queries unless necessary, and validating that any query filters include the ownership predicate. In ASP.NET, always bind identifiers from claims or route data that you have verified, and never pass raw client input directly into Firestore document paths. Combine these practices with regular scans using tools that test API security, such as middleBrick, to detect misconfigurations and PII leakage early.