Mass Assignment in Chi with Basic Auth

Mass Assignment in the Chi web toolkit occurs when request payload fields are mapped directly to domain models without explicit allowlisting. Chi does not provide built-in model binding that filters attributes, so developers commonly bind JSON or form values straight into structs or maps. When Basic Auth is used for endpoint protection, the perception of safety can encourage less scrutiny of input handling, since authentication is treated as the primary gate. However, authentication and authorization are distinct controls: confirming identity does not limit which properties a user may set.

Consider a Chi route that authenticates with Basic Auth and then decodes JSON into a struct:

// Example: Basic Auth in Chi with unchecked binding
import (
    "encoding/base64"
    "net/http"
    "strings"
)

type UserUpdate struct {
    Email string
    Role  string // sensitive, should not be user-settable
    Active bool
}

func basicAuth(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        userPass, ok := r.BasicAuth()
        if !ok || userPass != "alice:correcthorse" {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return
        }
        next.ServeHTTP(w, r)
    })
}

func updateUser(w http.ResponseWriter, r *http.Request) {
    var u UserUpdate
    if err := json.NewDecoder(r.Body).Decode(&u); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    // If Role is present in JSON, it will be set — no filtering
    // An attacker can change Role via Mass Assignment
    _ = u // handler logic
}

func main() {
    r := chi.NewRouter()
    r.Use(basicAuth)
    r.Put("/users/{id}", updateUser)
    http.ListenAndServe(":8080", r)
}

In this setup, Basic Auth confirms the request comes from alice, but the handler does not prevent an authenticated user from supplying Role in the JSON body. Because Chi routes treat the body as an opaque payload by default, any extra fields can populate struct fields that the developer did not intend to expose. This is Mass Assignment: the attacker assigns a privilege (Role) through a parameter the application should never bind. The vulnerability is not in Basic Auth itself, but in the unchecked binding combined with an assumption that authentication equals safe input handling.

An authenticated PUT to /users/123 with body {"email": "[email protected]", "role": "admin", "active": false} would silently update Role to admin if the struct field name matches (case-insensitive in some bindings) or if reflection-based binding is used. This maps directly to the OWASP API Top 10 1:2023 — Broken Object Level Authorization (BOLA)/IDOR and can also intersect with 2:2023 — Mass Assignment when frameworks allow over-posting.

middleBrick scans would flag this as a BOLA/IDOR and Property Authorization finding, noting that authentication does not enforce property-level permissions. Reports include remediation guidance emphasizing explicit field filtering and schema validation rather than relying on authentication to limit operations.

Remediation focuses on strict input allowlisting and avoiding automatic mapping of all request fields. In Chi, use explicit decoding into a temporary struct or map, then copy only permitted fields into your domain model. Do not rely on Basic Auth to protect property assignment.

1) Explicit allowlist with decoding to a temporary struct:

import (
    "encoding/json"
    "net/http"
)

type userUpdateDTO struct {
    Email string `json:"email"`
    // Do not include Role or Active here
}

type User struct {
    Email string
    Role  string
    Active bool
}

func updateUser(w http.ResponseWriter, r *http.Request) {
    var dto userUpdateDTO
    if err := json.NewDecoder(r.Body).Decode(&dto); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    id := chi.URLParam(r, "id")
    // Fetch existing user from store
    var u User
    // ... load u by id
    u.Email = dto.Email // only copy allowed fields
    // Role and Active remain unchanged unless explicitly managed elsewhere
    // Save updated user
    _ = u
}

2) Using a map with key checks for extra fields:

func updateUserMap(w http.ResponseWriter, r *http.Request) {
    var raw map[string]json.RawMessage
    if err := json.NewDecoder(r.Body).Decode(&raw); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    allowed := map[string]bool{"email": true}
    var email string
    if v, ok := raw["email"]; ok && allowed["email"] {
        if err := json.Unmarshal(v, &email); err != nil {
            http.Error(w, "invalid email", http.StatusBadRequest)
            return
        }
    } else {
        http.Error(w, "email is required", http.StatusBadRequest)
        return
    }
    // Ignore any other keys; do not decode them into domain structs
    // Proceed with email update only
}

3) If you use a binding library, configure it to ignore unsettable fields or use a denylist for sensitive properties. However, prefer explicit allowlists as shown above. Basic Auth should remain a separate authentication layer and not be coupled with permissive binding strategies.

These patterns ensure that even when Basic Auth verifies identity, Mass Assignment cannot elevate privileges through unexpected parameters. The handler retains control over which fields are mutable, aligning with secure design principles for API input handling.