Injection Flaws in Fiber with Mongodb

Injection flaws in a Fiber API that uses MongoDB typically arise when user-controlled input is concatenated into database queries or pipeline stages without proper validation or serialization. Because Fiber is a fast, unopinioned web framework, it does not enforce any schema or query conventions; the developer is responsible for ensuring that data passed to MongoDB is safe. When dynamic values such as req.Params, req.Query, or body fields are used directly in bson.D, bson.M, or aggregation pipelines, an attacker can inject operators or documents that change query semantics.

For example, an endpoint like /users/:id that builds a filter as bson.M{"_id": req.Params("id")} is generally safe because _id casting and BSON representation are well behaved. However, constructing a filter with raw user input used as a key or embedding user input inside nested documents can enable injection-like behavior. More critically, if user input reaches aggregation stages such as $match, $project, or $addFields, an attacker may supply operators like {"$ne": ""} or {"$exists": true} to bypass intended filters or extract additional fields. This becomes a server-side injection vector against MongoDB when the API reflects query structure or error messages, and it can be chained with other issues such as IDOR or excessive data exposure.

Unauthenticated endpoints increase risk because an attacker can probe query behavior without credentials. In a black-box scan, injection findings often surface through error-based detection or anomalous data returns. Because middleBrick tests input validation and property authorization in parallel, it checks whether filters and projections are constrained to expected properties and whether operators supplied by the caller can alter query logic. This is especially important for aggregation pipelines where stage boundaries are less obvious than in simple Find queries.

In the context of compliance mappings, injection-related findings are often tied to OWASP API Top 10 A03:2023 Injection, and can intersect with data exposure when over-fetching occurs due to permissive match stages. Unlike traditional SQL injection, MongoDB injection in Fiber is usually about unsafe document construction or pipeline manipulation rather than string concatenation, but the operational impact can be equally severe in terms of data leakage or unintended writes.

Remediation focuses on strict schema validation, avoiding direct use of user input as operators or keys, and leveraging MongoDB’s built-in query patterns. Prefer static structures and avoid dynamic stage assembly unless absolutely necessary, and if required, validate each component against an allowlist.

• Use strongly typed filters and avoid concatenating raw strings into queries. Instead of building a filter with user input as a key, map known fields to canonical keys:

// Safe: map user input to known fields
allowedFields := map[string]string{
    "name":  "name",
    "email": "email",
}
field, ok := allowedFields[req.Params("sortBy")]
if !ok {
    field = "name"
}
cursor, err := collection.Find(ctx, bson.M{"status": "active"}, options.Find().SetSort(bson.D{{field, 1}}))

• When using aggregation, validate each stage and avoid passing raw user input into operator values. For $match, restrict conditions to known fields and values:

// Safe: parameterized $match without dynamic operators
matchStage := bson.D{{"$match", bson.D{{"status", "active"}, {"role", bson.D{{"$in", []string{"user", "admin"}}}}}}}
pipeline := mongo.Pipeline{matchStage}
cursor, err := collection.Aggregate(ctx, pipeline)

• Do not allow user input to dictate operators such as $eq, $ne, or $exists. If filtering behavior must be dynamic, implement a dispatcher that only permits safe operations and rejects any payload containing operator-like syntax:

// Reject keys or values that look like operators
func isSafeValue(v any) bool {
    // basic guard: reject strings starting with $ or containing .
    if s, ok := v.(string); ok && (strings.HasPrefix(s, "$") || strings.Contains(s, ".")) {
        return false
    }
    return true
}

for k, v := range userFilters {
    if strings.HasPrefix(k, "$") || !isSafeValue(v) {
        http.Error(resp, "invalid filter", http.StatusBadRequest)
        return
    }
}

• For ObjectID and numeric IDs, always parse and cast explicitly rather than relying on implicit coercion, which prevents malformed IDs from producing unexpected query behavior:

objID, err := primitive.ObjectIDFromHex(req.Params("id"))
if err != nil {
    http.Error(resp, "invalid id", http.StatusBadRequest)
    return
}
var user User
err = collection.FindOne(ctx, bson.M{"_id": objID}).Decode(&user)

These patterns reduce the attack surface by ensuring that user input cannot reshape query logic, and they align with the checks performed by middleBrick’s input validation and property authorization tests. The scanner does not modify code; it highlights where unsafe patterns exist and provides remediation guidance like the examples above.