Open Redirect in Aspnet with Firestore

An open redirect in an ASP.NET application that uses Cloud Firestore typically occurs when a controller or page accepts a user-supplied URL or redirect target and then uses Firestore to look up additional data before performing the redirect. If the application places the user-provided value into the redirect response without strict validation, an attacker can supply a malicious URI. Even though Firestore itself does not execute or parse the target URL, its presence in the request flow can indirectly enable the open redirect: the application may read a document ID or collection path from Firestore based on user input, then use a value stored in Firestore (such as a configured redirect URL or a tenant-specific landing page) to construct the final redirect. If the stored values are not strictly constrained or the Firestore query is parameterized only by an uncontrolled input, the attacker can manipulate which document is retrieved or which field is used, ultimately steering the redirect to a malicious site.

For example, an endpoint might accept a returnUrl query string and a tenantId, use the tenantId to fetch a tenant document from Firestore, and then combine the tenant-specific base URL with the user-supplied returnUrl. If the tenant document contains a redirect target or the application concatenates values without validation, an attacker who can influence the Firestore document (via IDOR or BOLA) or supply a malicious tenantId can cause the application to redirect to an arbitrary external domain. This pattern is problematic because the trust placed in Firestore data may obscure the fact that the final destination is user-influenced. The vulnerability belongs to the category BOLA/IDOR when different tenants or documents are accessible via predictable identifiers, and to BFLA/Privilege Escalation when roles or policies are not properly enforced on the Firestore queries.

Additionally, the risk is compounded if the ASP.NET app exposes an unauthenticated endpoint that reads from Firestore and redirects without an allowlist of trusted domains. Because the scan includes checks for authentication, BOLA/IDOR, and BFLA/Privilege Escalation across unauthenticated attack surfaces, such a combination can be flagged as a high-severity finding. Remediation requires validating and restricting redirect targets, tightening Firestore access controls, and ensuring that any data used to build redirect URLs is treated as untrusted input rather than trusted configuration.

To remediate open redirect risks in ASP.NET when using Firestore, apply strict allowlisting and canonicalization to any user-influenced values that contribute to the redirect target. Avoid concatenating raw user input to URLs, even if the base URL is stored in Firestore. Instead, treat Firestore fields as configuration that must be validated and constrained. Below are concrete code examples that demonstrate a secure approach.

• Validate redirect targets against an allowlist of permitted domains. Before using any URL from Firestore or user input, resolve and compare the host against a known set of allowed hosts.

using System;
using System.Linq;
using Google.Cloud.Firestore;
using Microsoft.AspNetCore.Mvc;

public class RedirectController : Controller
{
    private readonly FirestoreDb _firestore;
    private static readonly string[] AllowedHosts = { "app.example.com", "trusted.partner.com" };

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

    [HttpGet("/landing")]
    public async Task<IActionResult> Landing(string tenantId, string path)
    {
        // Canonicalize and validate tenantId
        if (!Guid.TryParse(tenantId, out _))
        {
            return BadRequest("Invalid tenant identifier.");
        }

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

        // Firestore field used for configuration, not direct redirect input
        string baseUrl = snapshot.GetValue<string>("RedirectBaseUrl");
        if (!Uri.TryCreate(baseUrl, UriKind.Absolute, out Uri baseUri) ||
            !AllowedHosts.Contains(baseUri.Host))
        {
            return StatusCode(500, "Invalid redirect configuration.");
        }

        // Validate path to prevent directory traversal or open redirect via path
        if (string.IsNullOrWhiteSpace(path) || path.Contains("..") || path.Contains(":"))
        {
            return BadRequest("Invalid path.");
        }

        // Build final URL safely
        Uri target = new Uri(baseUri, $"/{path.TrimStart('/')}");
        if (!AllowedHosts.Contains(target.Host))
        {
            return BadRequest("Redirect target not allowed.");
        }

        return Redirect(target.ToString());
    }
}

• Use Firestore to store only trusted configuration and enforce strict access controls. Ensure Firestore rules and ASP.NET authorization policies prevent IDOR/BOLA so that one tenant cannot read another tenant’s redirect configuration.

// Firestore security rules (conceptual)
service cloud.firestore {
  match /databases/{database}/documents {
    match /tenants/{tenantId} {
      allow read: if request.auth != null && request.auth.token.tenant_id == tenantId;
      allow write: if false; // configuration should be managed via admin SDK
    }
  }
}

• In the ASP.NET pipeline, prefer predefined redirect mappings (e.g., enum-to-URL) over raw Firestore values for common destinations, and log suspicious inputs. For the CI/CD and monitoring needs mentioned in the product context, the Pro plan’s continuous monitoring can help detect anomalous redirect patterns across scans, while the CLI can be integrated into build scripts to validate configuration as code.