Mass Assignment in Fiber with Basic Auth

Mass Assignment in the Fiber HTTP framework occurs when an endpoint binds incoming JSON directly to a struct or map without filtering fields, allowing an attacker to set sensitive properties that should be immutable. When Basic Auth is used for authentication but authorization is not enforced at the handler level, the risk is compounded: the request may be authenticated as a low-privilege user, yet the application applies unchecked input to a privileged operation or model.

Consider a user profile update endpoint that uses Basic Auth to identify the account but does not restrict which fields can be updated. An authenticated user can send extra fields such as is_admin or role, and if the handler decodes the JSON into a broader struct, those fields may be applied silently. This becomes a BOLA/IDOR vector when the endpoint uses the authenticated user’s identity to locate a record (e.g., via a user ID in the URL) but does not ensure that the authenticated subject is allowed to modify sensitive attributes.

With OpenAPI/Swagger analysis, middleBrick can detect mismatches between the documented request schema and the runtime behavior when unauthenticated scanning reveals endpoints that accept unexpected fields. In a black-box scan against a Fiber service using Basic Auth, middleBrick tests input validation and Property Authorization by submitting payloads with over-permissive fields to confirm whether the server applies them. Findings include insecure deserialization patterns and missing field-level authorization, mapped to the OWASP API Top 10 and relevant compliance frameworks.

Real-world examples include endpoints that decode into a struct like UserUpdate containing sensitive booleans or IDs, where an attacker supplies {"name":"hacker","is_admin":true} and the server applies the update because no explicit allowlist is used. This is distinct from general injection issues; it is a privilege escalation concern enabled by permissive binding combined with weak authorization checks.

Remediation focuses on explicit field allowlisting, scoping updates to the authenticated subject, and avoiding broad struct binding. In Fiber, use a dedicated input struct that includes only the fields a user is permitted to modify, and validate ownership before applying changes.

Example of a vulnerable handler that enables Mass Assignment:

//go
package main

import (
    "github.com/gofiber/fiber/v2"
)

type UserUpdate struct {
    Name     string `json:"name"`
    Email    string `json:"email"`
    IsAdmin  bool   `json:"is_admin"` // dangerous, should not be user-settable
    Role     string `json:"role"`     // dangerous
}

app.Post("/users/:id", func(c *fiber.Ctx) error {
    var u UserUpdate
    if err := c.BodyParser(&u); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid body"})
    }
    // ID from URL, but no check that the authenticated user owns this ID or is allowed to set IsAdmin/Role
    // ... update logic ...
    return c.JSON(fiber.Map{"status": "ok"})
})

Secure version with explicit allowlisting and ownership check:

//go
package main

import (
    "github.com/gofiber/fiber/v2"
)

type UserUpdateSafe struct {
    Name  string `json:"name" validate:"required,max=255"`
    Email string `json:"email" validate:"required,email"`
}

// Assume a helper that retrieves the authenticated user identity from Basic Auth context
func getCurrentUserID(c *fiber.Ctx) (string, error) {
    user := c.Locals("user")
    if user == nil {
        return "", fiber.ErrUnauthorized
    }
    id, ok := user.(string)
    if !ok {
        return "", fiber.ErrUnauthorized
    }
    return id, nil
}

app.Post("/users/:id", func(c *fiber.Ctx) error {
    targetID := c.Params("id")
    currentID, err := getCurrentUserID(c)
    if err != nil || targetID != currentID {
        return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "not allowed"})
    }

    var u UserUpdateSafe
    if err := c.BodyParser(&u); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid body"})
    }
    // Apply only Name and Email; IsAdmin/Role are excluded from binding
    // ... update profile for currentID with u.Name, u.Email ...
    return c.JSON(fiber.Map{"status": "ok"})
})

Additional measures include using middleware to enforce scope-based authorization after authentication, and validating that sensitive fields are absent or ignored rather than merely checked for values. middleBrick can verify these patterns by scanning the unauthenticated surface and confirming that endpoints do not accept or apply disallowed properties.