Nosql Injection in Fiber

Nosql injection in Fiber applications typically occurs when user input is directly incorporated into MongoDB queries without proper sanitization. Fiber's clean API design and Go's type safety can create a false sense of security, leading developers to overlook injection vectors in database operations.

The most common pattern involves using fiber.Ctx.Query() or fiber.Ctx.Params() values directly in MongoDB queries. Consider this vulnerable Fiber route:

app := fiber.New()
app.Get("/users", func(c *fiber.Ctx) {
    db := mongoInstance.Database("mydb")
    col := db.Collection("users")
    
    // VULNERABLE: Direct query injection
    name := c.Query("name", "")
    query := bson.M{"name": name}
    
    cursor, err := col.Find(context.Background(), query)
    // ...
})

An attacker can manipulate the name parameter to inject MongoDB operators. For example, requesting /users?name[$ne]= returns all users regardless of name, while /users?name[$exists]=true achieves the same result. More sophisticated attacks can use $where clauses to execute arbitrary JavaScript:

curl "http://localhost:3000/users?name[$where]=this.password.length>5"

ObjectID manipulation presents another injection vector. When user IDs from URL parameters are converted to ObjectID without validation:

app.Get("/users/:id", func(c *fiber.Ctx) {
    id := c.Params("id")
    objID, _ := primitive.ObjectIDFromHex(id) // No error handling!
    
    result := col.FindOne(context.Background(), bson.M{"_id": objID})
    // ...
})

An attacker can supply malformed ObjectIDs that cause different query behavior or errors that leak information about the database schema.

Update operations are equally vulnerable. Consider this Fiber handler:

app.Patch("/users/:id", func(c *fiber.Ctx) {
    id := c.Params("id")
    updates := c.BodyParser(&bson.M{}) // Directly uses request body
    
    col.UpdateOne(context.Background(), bson.M{"_id": id}, bson.M{"$set": updates})
    // ...
})

Here, an attacker can craft JSON payloads that modify unintended fields or escalate privileges by including operators like $inc, $set, or $unset in unexpected places.

Detecting NoSQL injection in Fiber applications requires examining both the code patterns and runtime behavior. The most effective approach combines static analysis of your Fiber handlers with dynamic scanning of running endpoints.

Code-level indicators include:

• Direct use of c.Query(), c.Params(), or c.BodyParser() values in MongoDB queries without sanitization
• Missing validation of ObjectID conversions from URL parameters
• Use of primitive.D or bson.M with user input as keys
• Dynamic query construction based on request data

middleBrick's scanner specifically tests for these Fiber-specific patterns by submitting crafted payloads to your API endpoints. The scanner attempts operator injection using MongoDB's query language syntax, testing for BOLA (Broken Object Level Authorization) and data exposure vulnerabilities.

For example, middleBrick will test if your endpoint responds differently to:

GET /api/users?name[$ne]=
GET /api/users?role[$ne]=admin
GET /api/orders?status[$in]=pending,shipped,delivered

The scanner also validates that error responses don't leak database information. A properly secured Fiber application should return generic error messages rather than MongoDB stack traces or database schema details.

middleBrick's LLM security module adds another layer of detection for AI-enhanced Fiber applications. If your Fiber API serves as a backend for an AI application, the scanner tests for:

• System prompt leakage through error responses
• Prompt injection vulnerabilities in AI endpoints
• Excessive agency in AI tool calls

The GitHub Action integration allows you to automate these security checks in your CI/CD pipeline, ensuring NoSQL injection vulnerabilities are caught before deployment to production.

Securing Fiber applications against NoSQL injection requires a defense-in-depth approach. The most effective remediation combines input validation, query parameterization, and proper error handling.

Input validation should be the first line of defense. Use Go's type system and validation libraries to constrain user input:

type UserQuery struct {
    Name  string `query:"name" validate:"omitempty,alpha"`
    Email string `query:"email" validate:"omitempty,email"`
}

app.Get("/users", func(c *fiber.Ctx) {
    var query UserQuery
    if err := c.QueryParser(&query); err != nil {
        c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "Invalid query parameters"})
        return
    }
    
    // Now safe to use in MongoDB query
    mongoQuery := bson.M{}
    if query.Name != "" {
        mongoQuery["name"] = query.Name
    }
    if query.Email != "" {
        mongoQuery["email"] = query.Email
    }
    
    cursor, err := col.Find(context.Background(), mongoQuery)
    // ...
})

For ObjectID parameters, always validate the format before conversion:

app.Get("/users/:id", func(c *fiber.Ctx) {
    id := c.Params("id")
    if !bson.IsObjectIdHex(id) {
        c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "Invalid user ID"})
        return
    }
    
    objID, err := primitive.ObjectIDFromHex(id)
    if err != nil {
        c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "Invalid user ID"})
        return
    }
    
    result := col.FindOne(context.Background(), bson.M{"_id": objID})
    // ...
})

Update operations require strict field whitelisting:

type UserUpdate struct {
    Name  *string `json:"name"`
    Email *string `json:"email"`
}

app.Patch("/users/:id", func(c *fiber.Ctx) {
    var update UserUpdate
    if err := c.BodyParser(&update); err != nil {
        c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "Invalid update data"})
        return
    }
    
    updateOps := bson.M{}
    if update.Name != nil {
        updateOps["name"] = *update.Name
    }
    if update.Email != nil {
        updateOps["email"] = *update.Email
    }
    
    if len(updateOps) == 0 {
        c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "No valid fields to update"})
        return
    }
    
    col.UpdateOne(context.Background(), bson.M{"_id": objID}, bson.M{"$set": updateOps})
    // ...
})

middleBrick's CLI tool can verify your remediations by scanning the secured endpoints and confirming the security score improvement. After implementing these fixes, you should see the NoSQL injection findings resolved in your middleBrick report.

For production deployments, integrate middleBrick's GitHub Action to scan your staging API before each release. Configure it to fail the build if critical vulnerabilities are detected, ensuring NoSQL injection flaws never reach production.