Cross Site Request Forgery in Aspnet with Firestore

Cross Site Request Forgery (CSRF) in an ASP.NET application that uses Cloud Firestore as a backend can expose destructive state-changing behavior when anti-forgery protections are absent or misconfigured. In this combination, an attacker can trick a signed-in user’s browser into issuing authenticated Firestore writes or deletes via crafted HTML forms or malicious GET requests that trigger POST endpoints.

ASP.NET provides built-in CSRF protections via anti-forgery tokens (e.g., @Html.AntiForgeryToken() in Razor and [ValidateAntiForgeryToken] on controllers). When these are omitted, or when developers assume Firestore security rules alone are sufficient, the application becomes vulnerable. Firestore security rules are permission-based and do not distinguish between a legitimate user-initiated request and a forged request coming from a malicious site, as long as the user’s credentials (e.g., session cookie) are present.

A concrete scenario: an ASP.NET page includes a form that deletes a Firestore document using a document ID supplied by the user. If the form lacks an anti-forgery token and the endpoint does not validate [ValidateAntiForgeryToken], an attacker can host a page with a hidden form whose action points to that endpoint and whose input sets the target document ID. When the victim visits the attacker’s page, the browser sends the user’s authentication cookie, the ASP.NET endpoint authorizes the request, and the Firestore rule evaluates to allowed, resulting in an unintended delete or write.

Because Firestore rules often permit authenticated users to modify their own data (e.g., allow update if request.auth != null), the risk is amplified: a single compromised user session can lead to mass data manipulation if the application does not enforce per-request CSRF checks. The stateless nature of Firestore also means there is no built-in cross-request context; it is the application’s responsibility to bind each mutation to a validated intent through tokens or custom headers that cannot be forged by third-party sites.

To detect this pattern, scanners test endpoints that perform write operations without requiring a valid anti-forgery token, and they check whether the Firestore rules rely solely on authentication without ensuring request origin integrity. This combination highlights a critical gap where authentication is present but origin validation is missing, enabling forged requests to execute privileged Firestore operations.

Remediation centers on enforcing anti-forgery validation on all state-changing endpoints and ensuring Firestore rules complement rather than replace CSRF controls. Below are concrete ASP.NET patterns and Firestore code examples that reduce risk.

1. Use anti-forgery tokens in Razor Pages and MVC

Include the anti-forgery token in every form that performs writes, and validate it on the server. For a Razor Page that deletes a document:

&@page
@model DeleteDocumentModel
@using Microsoft.AspNetCore.Antiforgery

<form method="post">
    <input type="hidden" asp-for="DocumentId" />
    <button type="submit">Delete</button>
    <input name="__RequestVerificationToken" type="hidden" value="@Antiforgery.GetAndStoreTokens(Context).RequestToken" />
</form>

On the server, ensure the handler validates the token:

public async Task OnPostAsync()
{
    if (!Antiforgery.IsRequestTokenValid(Context))
    {
        StatusCode = 400;
        return;
    }

    var db = _firestoreDb;
    await db.Collection("documents").Document(DocumentId).DeleteAsync();
    RedirectToPage("./Index");
}

2. Validate anti-forgery tokens in MVC controllers

For traditional controllers, decorate write actions with [ValidateAntiForgeryToken]:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task Delete(string documentId)
{
    var db = _firestoreDb;
    var docRef = db.Collection("documents").Document(documentId);
    await docRef.DeleteAsync();
    return RedirectToAction("Index");
}

3. Use custom headers and same-site cookies for API-style endpoints

If your ASP.NET app serves an API consumed by JavaScript, require a custom header (e.g., X-Requested-With) and configure anti-forgery to read it. Also set SameSite cookies:

services.AddAntiforgery(options =>
{
    options.HeaderName = "X-CSRF-TOKEN";
});

services.ConfigureApplicationCookie(options =>
{
    options.Cookie.SameSite = SameSiteMode.Strict;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});

On the Firestore side, ensure rules require authentication and bind operations to the authenticated UID to prevent horizontal privilege escalation:

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

4. Avoid unsafe GET endpoints that perform writes

Never allow GET requests to delete or modify Firestore data. Use POST/PUT/PATCH with validated tokens. Example of a safe POST handler:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> UpdateDocument(string documentId, string content)
{
    var db = _firestoreDb;
    await db.Collection("documents").Document(documentId).UpdateAsync("content", content);
    return Ok();
}

By combining ASP.NET’s anti-forgery mechanisms with disciplined Firestore rules and safe HTTP method usage, the application prevents CSRF attacks while preserving Firestore’s flexible access model.