Nosql Injection in Fiber with Jwt Tokens

NoSQL injection is a class of injection that manipulates the query language of databases such as MongoDB or CouchDB. When a Go API built with the Fiber framework processes untrusted input and embeds it directly into a NoSQL query, the application can be forced to return or modify data it should not. JWT tokens are commonly used in Fiber to carry identity claims, and if the contents of a token are used to construct NoSQL queries without validation or escaping, the trust boundary between authentication and data access is compromised.

Consider a scenario where a Fiber handler decodes a JWT and uses the sub (subject) claim to look up a user document in MongoDB. If the code concatenates the token payload directly into a query map, an attacker who can influence the token (via a weak signing key, algorithm confusion, or a compromised client) can inject query operators. For example, a token with {"sub": {"$ne": null}} can turn a lookup into a logic bypass, or a token with {"sub": "user_id", "$where": "return false"} can alter execution flow. Because the scan runs unauthenticated, it can detect endpoints that accept user-controlled parameters derived from JWT claims and flag them as BOLA/IDOR or unsafe consumption risks when the resulting queries expose other users’ data or bypass intended filters.

In a real test, middleBrick exercises 12 security checks in parallel, including Authentication, BOLA/IDOR, and Unsafe Consumption. When JWT tokens influence NoSQL queries, findings often include insecure direct object references and missing property-level authorization, because the scanner observes that query logic can be altered by token claims. The scanner also checks input validation routines and data exposure paths; if encoded or decoded token fields are reflected in responses or logs, additional risks such as information leakage appear. This is particularly relevant when the API exposes endpoints that accept query parameters that map directly to document fields, and those parameters are derived from or influenced by JWT payloads.

middleBrick’s OpenAPI/Swagger analysis (supporting 2.0, 3.0, and 3.1 with full $ref resolution) correlates the API contract with runtime behavior. If the spec defines a path like /users/{id} and the implementation pulls id from a JWT claim rather than from a validated source, the scan can highlight a mismatch between declared authentication and actual authorization logic. The LLM/AI Security checks do not apply here, but the scanner’s inventory management and authentication checks ensure that endpoints relying on tokens are tested for whether they correctly isolate resources and enforce boundaries.

To illustrate the risk with real code, the following Fiber example shows a vulnerable pattern where a JWT’s sub is used to build a MongoDB selector without sanitization:

// Vulnerable: JWT subject used directly in NoSQL query
claims := jwtClaims["sub"]
userFilter := bson.D{{"user_id", claims}}
var user bson.M
if err := collection.FindOne(c.Context(), userFilter).Decode(&user); err != nil {
    c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid token"})
    return
}
c.JSON(fiber.Map{"profile": user})

An attacker who controls the token can set sub to {"$ne": null} to return the first user document they can access, effectively bypassing identity isolation. The same issue arises if token fields are used in update operations, where operators like $set or $inc are injected via claims. Because JWTs are often considered trusted after verification, developers may overlook the need to treat claims as untrusted input when constructing NoSQL queries.

Remediation focuses on strict validation, type-safe extraction, and avoiding direct injection of token payloads into NoSQL queries. In Fiber, you should treat JWT claims as untrusted input, validate and sanitize them before use, and parameterize queries rather than building them via concatenation or map injection.

First, enforce strong type definitions for claims and validate against expected formats. Do not assume the sub claim is a simple string or that numeric fields remain numeric. Use explicit type assertions and schema checks.

// Secure: Validate and type-assert JWT claims before use
type CustomClaims struct {
    Subject string `json:"sub"`
    UserID  primitive.ObjectID `json:"user_id"`
}
var claims CustomClaims
token, err := middleware.ParseToken(c, func(token *jwt.Token) (interface{}, error) { return []byte(secret), nil })
if err != nil {
    c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid token"})
    return
}
if claims.UserID.IsZero() {
    c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "missing user identifier"})
    return
}
userFilter := bson.D{{"_id", claims.UserID}}
var user bson.M
if err := collection.FindOne(c.Context(), userFilter).Decode(&user); err != nil {
    c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "user not found"})
    return
}
c.JSON(fiber.Map{"profile": user})

Second, avoid using token fields as operators or query modifiers. If a token carries roles or scopes, map them to an allowlist in Go rather than passing them into the query builder. For updates, use explicit field names and avoid dynamic key construction from claims.

// Secure: Use claims for authorization checks, not query construction
roles, ok := token.Claims.(jwt.MapClaims)["roles"]
if !ok || !contains(roles, "admin") {
    c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "insufficient scope"})
    return
}
update := bson.D{{"$set", bson.D{{"status", "approved"}}}}
if _, err := collection.UpdateOne(c.Context(), bson.D{{"_id", claims.UserID}}, update); err != nil {
    c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "update failed"})
    return
}

Third, configure JWT middleware to reject tokens with unexpected algorithms and to enforce issuer/audience validation. This reduces the risk of algorithm confusion attacks that could allow an attacker to supply a malicious token with an injected sub.

// Configure JWT middleware with strict validation
config := middleware.JWTConfig{
    SigningKeys: [][]byte{[]byte(secret)},
    SigningMethod: "HS256",
    TokenLookup: "header:Authorization",
    AuthScheme: "Bearer",
    Validate: func(token *jwt.Token) (interface{}, error) {
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
        }
        return []byte(secret), nil
    },
}
app.Use(middleware.JWTWithConfig(config))

By combining strict claim validation, typed extraction, and parameterized queries, you ensure that JWT tokens influence authentication but not the structure of NoSQL queries. This aligns with secure coding practices and reduces the attack surface for NoSQL injection in Fiber applications.