Insecure Deserialization in Fiber with Mongodb

Insecure deserialization occurs when an application accepts untrusted data and reconstructs objects from it without sufficient validation. In a Fiber application that uses MongoDB as a data store, risk arises when request bodies, query parameters, or custom headers are deserialized into Go structs and subsequently used to build MongoDB queries or to directly decode stored documents.

Consider a typical endpoint that looks up a user by an ID provided in the URL path. If the ID is deserialized from a string into a more complex type (for example, a custom wrapper that also carries metadata), and that value is later concatenated into a MongoDB filter without sanitization, an attacker may be able to inject unexpected operators or documents. Similarly, if your application stores raw BSON or JSON documents in MongoDB and later deserializes them into interface{} or map[string]interface{} in Go, an attacker who can influence what is stored may craft payloads that execute unintended logic when the document is reconstructed. Common attack patterns include type confusion, unexpected method execution during unmarshaling, and injection of MongoDB update operators into documents that are later used with UpdateOne or UpdateMany.

With the middleBrick LLM/AI Security checks, this class of issue is probed through active prompt injection and output scanning, but for API security the focus remains on how data flows between the HTTP layer and the database. Because Fiber lets you plug middleware freely, it is easy to inadvertently chain a deserialization step to a MongoDB operation without validating types or field constraints. The scanner tests endpoints that accept JSON or form data, then maps findings to the OWASP API Top 10 and related compliance frameworks to highlight insecure deserialization alongside data exposure risks.

Secure handling in Fiber requires strict separation between incoming request data and the structures used to build MongoDB filters. Always deserialize into concrete, validated structs and avoid passing raw interface{} values directly to database operations. Use the MongoDB Go driver’s built-in filtering helpers and explicit type assertions to ensure only expected values are used.

Example 1: Safe lookup by ID with proper type handling.

import (
    "context"
    "github.com/gofiber/fiber/v2"
    "go.mongodb.org/mongo-driver/bson"
    "go.mongodb.org/mongo-driver/mongo"
    "go.mongodb.org/mongo-driver/mongo/options"
    "strings"
)

type User struct {
    ID   string `json:"id"`
    Name string `json:"name"`
}

// Assume client *mongo.Client is already connected and database selected
func GetUser(c *fiber.Ctx) error {
    id := c.Params("id")
    // Validate and sanitize the ID before using it in a filter
    if id == "" || strings.ContainsAny(id, "$.[]{}") {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid id"})
    }
    var user User
    err := collection.FindOne(c.Context(), bson.M{"_id": id}).Decode(&user)
    if err == mongo.ErrNoDocuments {
        return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "not found"})
    }
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "database error"})
    }
    return c.JSON(user)
}

Example 2: Using explicit filters for updates instead of raw deserialized documents.

import (
    "context"
    "fmt"
    "github.com/gofiber/fiber/v2"
    "go.mongodb.org/mongo-driver/bson"
    "go.mongodb.org/mongo-driver/bson/primitive"
    "go.mongodb.org/mongo-driver/mongo"
)

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

func UpdateUser(c *fiber.Ctx) error {
    id := c.Params("id")
    objectID, err := primitive.ObjectIDFromHex(id)
    if err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid id format"})
    }
    var dto UpdateUserDTO
    if err := c.BodyParser(&dto); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid payload"})
    }
    // Build an update document explicitly; do not forward raw DTO to $set
    update := bson.M{"$set": bson.M{}
    if dto.Name != "" {
        update["$set"].(bson.M)["name"] = dto.Name
    }
    if dto.Email != "" {
        update["$set"].(bson.M)["email"] = dto.Email
    }
    if update["$set"].(bson.M) == nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "no fields to update"})
    }
    _, err = collection.UpdateOne(c.Context(), bson.M{"_id": objectID}, update)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "update failed"})
    }
    return c.SendStatus(fiber.StatusNoContent)
}

Additional measures include enabling schema validation in MongoDB for collections, applying strict JSON unmarshaling rules (e.g., DisallowUnknownFields on structs), and reviewing stored procedures or aggregation pipelines for dynamic code execution. The middleBrick CLI can scan your endpoints to surface insecure patterns, and the GitHub Action can enforce a maximum risk score before merging changes that affect database interaction code.