Ssrf Server Side in Aspnet with Firestore

Server-side request forgery (SSRF) in an ASP.NET application that interacts with Google Cloud Firestore occurs when the server-side code accepts an attacker-controlled URL or host and uses it to form Firestore operations or related HTTP calls. Because Firestore clients typically rely on service account credentials and metadata endpoints, SSRF can expose internal metadata services, reach restricted cloud resources, or be used for data exfiltration through the Firestore API or chained requests.

In ASP.NET, this often manifests when a developer builds a proxy or dynamic client that resolves a user-supplied host to a Firestore endpoint or uses the supplied input to influence request targets. For example, if an endpoint accepts a document path or a custom host header and directly passes it into an HttpClient or Firestore client without strict allowlisting, the server may be tricked into making unintended requests to internal metadata services (e.g., the instance metadata endpoint at http://169.254.169.254) or to external services that the Firestore credentials can also reach.

Firestore-specific risks include using SSRF to enumerate project IDs, discover internal services via the metadata API, or abuse Firestore’s REST or gRPC endpoints to perform operations under the compromised service account. Attack patterns such as exploiting the metadata service for credentials or chaining SSRF with misconfigured IAM to escalate access are common. Because Firestore libraries in ASP.NET often rely on Application Default Credentials, an SSRF vulnerability can effectively expose the identity and permissions of the service account, leading to broader cloud impact.

middleBrick detects SSRF as part of its 12 security checks, flagging unsafe URL handling and dangerous request patterns in unauthenticated scans. The scanner does not fix the issue but provides findings with remediation guidance to help developers redesign request handling and remove reliance on untrusted inputs for network destinations.

Remediation focuses on strict input validation, allowlisting, and avoiding dynamic construction of Firestore client requests from untrusted data. Do not use user input to determine hosts, paths, or credentials. Instead, use fixed endpoints and validated identifiers.

1. Avoid dynamic hosts and use fixed Firestore endpoints

Never forward user input to determine the target host for Firestore or any HTTP call. Use the official Google Cloud Firestore client with default project configuration.

// BAD: using a user-supplied host (SSRF risk)
// var host = Request.Query["host"];
// var url = $"https://{host}/v1/projects/myproject/databases/(default)/documents/items/1";
// var resp = await _httpClient.GetAsync(url);

// GOOD: fixed endpoint, validated document path segment only
public async Task<DocumentSnapshot> GetDocumentSafe(string documentPath)
{
    // Allow only alphanumeric, underscores, hyphens, and slashes for document segments
    if (!System.Text.RegularExpressions.Regex.IsMatch(documentPath, @"^[a-zA-Z0-9_\-\/]+$"))
    {
        throw new ArgumentException("Invalid document path.");
    }
    DocumentReference docRef = _firestoreDb.Document(documentPath);
    return await docRef.GetSnapshotAsync();
}

2. Validate and restrict resource identifiers

Treat IDs, collection names, and document IDs as opaque strings. Do not concatenate them into arbitrary URLs. Use Firestore’s idioms to reference documents safely.

// GOOD: using Firestore idioms with validated IDs
public async Task<DocumentSnapshot> GetDocumentById(string collectionName, string documentId)
{
    // Strict allowlist for collection names
    var allowedCollections = new HashSet<string> { "users", "products", "orders" };
    if (!allowedCollections.Contains(collectionName))
    {
        throw new ArgumentException("Invalid collection.");
    }
    if (string.IsNullOrWhiteSpace(documentId) || documentId.Length > 500)
    {
        throw new ArgumentException("Invalid document ID.");
    }
    DocumentReference docRef = _firestoreDb.Collection(collectionName).Document(documentId);
    return await docRef.GetSnapshotAsync();
}

3. Secure credentials and disable metadata service access where possible

Ensure service account credentials are scoped narrowly. On environments where you control the runtime (e.g., Compute Engine, GKE), avoid allowing outbound requests to the metadata server from application code. Use environment-based configuration to enforce restricted network policies.

// Example: Ensure outbound calls are restricted via network policy, not code.
// Do not attempt to call metadata endpoints from application code.
// Configure firewall or VPC Service Controls to block 169.254.169.254 if not required.

4. Use middleware to sanitize inputs in ASP.NET

Add request validation middleware to reject or sanitize potentially malicious inputs before they reach business logic that may interact with Firestore.

// ASP.NET Core middleware snippet
app.Use(async (context, next) =>
{
    if (context.Request.Query.ContainsKey("redirectUrl"))
    {
        var redirect = context.Request.Query["redirectUrl"].ToString();
        if (!Uri.TryCreate(redirect, UriKind.Absolute, out var uri) ||
            !uri.Host.EndsWith("example.com", StringComparison.OrdinalIgnoreCase))
        {
            context.Response.StatusCode = 400;
            await context.Response.WriteAsync("Invalid redirect.");
            return;
        }
    }
    await next();
});

5. Prefer Firestore SDKs over raw HTTP for Firestore operations

The Firestore client libraries handle authentication and endpoint resolution safely. Avoid building REST calls manually using user input.

// GOOD: using Firestore SDK with project-scoped credentials
FirestoreDb db = FirestoreDb.Create(projectId);
DocumentReference doc = db.Collection("users").Document(userId);
DocumentSnapshot snapshot = await doc.GetSnapshotAsync();

By combining these practices, you reduce the attack surface for SSRF and ensure that Firestore interactions remain confined to intended resources and identities. middleBrick’s scans can help identify risky patterns, but remediation requires code-level changes and infrastructure controls.