Broken Authentication in Aspnet with Firestore

Broken Authentication in an ASP.NET application that uses Cloud Firestore as the backing store often stems from mismatched identity handling and insecure session management. Firestore itself does not provide a built-in user identity system; it enforces security rules based on the authenticated principal supplied by the caller. When ASP.NET does not properly establish and validate that principal, or when tokens or credentials are handled insecurely, the Firestore rules may evaluate requests as authenticated even when they are not.

One common pattern is using Firestore with custom tokens in ASP.NET without strict token validation and secure storage. If an endpoint generates or exchanges credentials without verifying the user’s identity, an attacker can supply arbitrary custom tokens or session identifiers to access documents they should not. For example, a developer might use the Firebase Admin SDK with elevated privileges to generate custom tokens without ensuring the calling user is who they claim to be. Because Firestore rules rely on the UID in the token, spoofing that UID grants access according to those rules.

Additionally, weak session handling in ASP.NET can expose session identifiers or authentication cookies to theft or replay. If authentication cookies are not marked Secure and HttpOnly, or if session identifiers are predictable, an attacker can steal tokens and impersonate users across Firestore reads and writes. Insecure deserialization of user data stored in Firestore can also lead to authentication bypass when application logic trusts client-supplied roles or permissions without re-verifying them server-side.

Consider an endpoint that accepts a uid query parameter to fetch user data without validating that the caller is that same user. With Firestore rules that allow read access based on request.auth.uid, an attacker can simply change the uid parameter to view other users’ documents. This is a Broken Authentication issue (C2- Broken Authentication in the OWASP API Security Top 10) that is amplified by trusting unverified input and misconfigured rule assumptions. Even when Firestore rules are strict, ASP.NET code must ensure the identity is verified and bound to the request context before constructing any database calls.

Real-world attack patterns include token manipulation, credential stuffing against weak authentication endpoints, and exploiting overly permissive Firestore rules that assume the caller’s UID is trustworthy. Because Firestore performs authorization at read/write time based on the request token, any weakness in how ASP.NET establishes that token or identity becomes a direct path to data exposure. Regular security scans that include authentication checks and BOLA/IDOR testing are essential to detect these issues early.

Remediation centers on ensuring that every Firestore operation is backed by a verified, server-authoritative identity and that tokens are handled securely. In ASP.NET, use a robust identity provider (such as ASP.NET Core Identity with a secure cookie scheme or OpenID Connect) and do not rely on client-supplied identifiers for Firestore access control. Always resolve the user identity on the server before generating or using any Firestore token or UID.

When using Firebase authentication, verify the ID token on each request using the Firebase Admin SDK, and map the verified UID to your application identity. Never accept a UID from query strings or request bodies for authorization decisions. Instead, bind the UID from the verified token to the Firestore rules and to your data access logic.

Example: Secure sign-in and token verification in ASP.NET Core.

using FirebaseAdmin;
using FirebaseAdmin.Auth;
using Google.Apis.Auth.OAuth2;
using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using System.Threading.Tasks;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        FirebaseApp.Create(new AppOptions()
        {
            Credential = GoogleCredential.FromFile("path/to/serviceAccountKey.json")
        });

        services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
            .AddCookie(options =>
            {
                options.LoginPath = "/Account/Login";
                options.AccessDeniedPath = "/Account/AccessDenied";
            });
        services.AddAuthorization();
        services.AddControllersWithViews();
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseAuthentication();
        app.UseAuthorization();
        app.UseEndpoints(endpoints => endpoints.MapControllers());
    }
}

Example: Verify Firebase ID token in a controller and map to a secure data access method.

using FirebaseAdmin.Auth;
using Google.Apis.Auth.OAuth2;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using System.Threading.Tasks;

[ApiController]
[Route("api/[controller]")]
public class UserController : ControllerBase
{
    [HttpGet("{requestedUid}")]
    [Authorize]
    public async Task GetUserData(string requestedUid)
    {
        // Do NOT use requestedUid for authorization; derive UID from verified token
        var firebaseToken = await HttpContext.User.GetFirebaseTokenAsync();
        if (firebaseToken == null)
        {
            return Unauthorized();
        }

        string verifiedUid = firebaseToken.Uid;
        if (verifiedUid != requestedUid)
        {
            return Forbid();
        }

        // Proceed with Firestore access using verifiedUid
        var userDoc = await FirestoreDb
            .Instance
            .GetDocumentAsync($"users/{verifiedUid}");
        return Ok(userDoc.ToDictionary());
    }
}

Example: Secure Firestore rule that relies on request.auth.uid verified server-side.

In Firestore security rules, ensure that reads/writes are scoped strictly to request.auth.uid and never to client-supplied identifiers:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Use ASP.NET to generate short-lived custom tokens only after verifying credentials, and store session identifiers in secure, HttpOnly cookies. Rotate secrets used for token generation and avoid logging raw authentication tokens. Combine these practices with continuous scanning that includes authentication and BOLA/IDOR checks to reduce the risk of Broken Authentication when working with Firestore-backed ASP.NET services.