Sql Injection in Aspnet with Firestore

SQL Injection (SQLi) is commonly associated with relational databases, but when an Aspnet application builds dynamic queries for Firestore using string concatenation or unsafe interpolation, the risk shifts to NoSQL injection while retaining many SQLi-like characteristics. Firestore itself does not use SQL, yet if the application layer constructs queries by directly embedding user input into map lookups, collection group queries, or raw command objects, attackers can manipulate field paths, array operators, or logical conditions to bypass intended data access boundaries.

In an Aspnet context, this often occurs when developers treat Firestore as a generic document store and build filters or where clauses by concatenating strings. For example, using string interpolation to inject a collection name or field name derived from request parameters allows an attacker to traverse collections or trigger unexpected query behavior. The Firestore SDK does not parameterize these dynamic identifiers, so validation must happen before constructing queries. Without strict allowlisting and normalization, an attacker can supply a document ID like users; DROP TABLE sessions; -- (interpreted as a literal document name) or use dot notation to access nested data they should not see.

Because middleBrick scans the unauthenticated attack surface and runs checks including Input Validation and Property Authorization in parallel, it can detect endpoints where Firestore queries are constructed from unchecked user input. Findings may highlight endpoints that expose document IDs or collection paths directly derived from parameters, enabling path traversal or overprivileged read access. These patterns align with the broader OWASP API Top 10 category of Injection and can lead to data exposure or privilege escalation when combined with BOLA/IDOR. The scan does not fix the logic, but it provides prioritized findings with severity and remediation guidance mapped to compliance frameworks such as OWASP API Top 10 and GDPR.

When an Aspnet API exposes a Firestore endpoint without authentication and uses raw query inputs, middleBrick’s LLM/AI Security checks can additionally probe for prompt injection or output leakage if any AI components are involved. However, the primary concern remains input validation: ensuring that field paths, document IDs, and query constraints are strictly validated, use allowlists, and never reflect unchecked user data into query construction. This prevents attackers from leveraging Firestore’s operators and path syntax to infer data structures or escalate access across collections.

Remediation centers on strict input validation, allowlisting, and avoiding dynamic query construction from user-controlled data. In Aspnet, treat all incoming identifiers as untrusted and normalize them before using them with the Firestore SDK.

Example of unsafe code to avoid:

// UNSAFE: directly interpolating user input into a document path or field name
var userSuppliedCollection = HttpContext.Request.Query["collection"];
var docId = HttpContext.Request.Query["id"];
var docRef = db.Collection(userSuppliedCollection).Document(docId);
var snapshot = await docRef.GetSnapshotAsync();

Instead, use an allowlist for collections and validate identifiers:

// SAFE: restrict collection names to a known set and validate document IDs
var allowedCollections = new HashSet<string> { "products", "orders", "users_public" };
var userSuppliedCollection = HttpContext.Request.Query["collection"];
var docId = HttpContext.Request.Query["id"];

if (!allowedCollections.Contains(userSuppliedCollection)) {
    // return a 400 or a safe default
    throw new ArgumentException("Invalid collection");
}

// Optionally enforce ID format, e.g., alphanumeric and length limits
if (!System.Text.RegularExpressions.Regex.IsMatch(docId, "^[a-zA-Z0-9_-]{1,100}$")) {
    throw new ArgumentException("Invalid document ID");
}

var docRef = db.Collection(userSuppliedCollection).Document(docId);
var snapshot = await docRef.GetSnapshotAsync();

For queries that filter on fields, avoid building dynamic field names. Instead, use a map of allowed field names to Firestore column identifiers:

// SAFE: map user-friendly keys to Firestore field names
var fieldMap = new Dictionary<string, string> {
    { "productName", "name" },
    { "category", "categoryId" }
};

var userField = HttpContext.Request.Query["field"];
var userValue = HttpContext.Request.Query["value"];

if (!fieldMap.ContainsKey(userField)) {
    throw new ArgumentException("Invalid field");
}

var query = db.Collection("items").WhereEqualTo(fieldMap[userField], userValue);
var snapshot = await query.GetSnapshotAsync();

When using collection group queries, constrain the paths and avoid wildcard-based traversal that can be influenced by user input:

// SAFE: limit collection group to specific collections
var snapshot = await db.CollectionGroup("items")
    .WhereEqualTo("status", "published")
    .Limit(10)
    .GetSnapshotAsync();

Finally, apply principle of least privilege in Firestore security rules (if enforced server-side) and ensure that Aspnet middleware does not propagate raw query components into Firestore calls. middleBrick’s dashboard and CLI can be used to track these changes over time; the Pro plan supports continuous monitoring and can integrate with CI/CD to fail builds if risk scores degrade.