Mass Assignment in Chi with Dynamodb

Mass Assignment occurs when a Chi handler binds incoming JSON directly to a structure that is later used to construct a DynamoDB write operation without explicit field filtering. In this context, the handler might unmarshal request body into a Go struct or a map and then pass that data to PutItem or UpdateItem. Because Go allows decoding to structs with public fields or to map[string]interface{}, an attacker can supply extra keys that map to unexpected DynamoDB attribute names. These extra attributes may overwrite critical metadata, change partition key behavior, or inject unexpected type information used by downstream logic.

When the unmarshaled data is forwarded to DynamoDB, attributes that should be server-controlled—such as created_at, owner_id, or condition expression parameters—can be set by the client if the struct is too permissive. For example, a handler that decodes into a struct with omittedempty fields may still populate fields that the developer did not intend to be user-supplied. In DynamoDB, this can lead to privilege escalation (users updating other users' items), data corruption across partitions, or bypass of application-level authorization checks that rely on attribute values.

The risk is compounded when the Chi router uses liberal decoding patterns, such as binding request bodies to interface{} or using a global JSON decoder configuration that does not reject unknown fields. Since DynamoDB operations often rely on attribute-based condition expressions and key schema constraints, unchecked input can manipulate condition results or key attribute values, leading to Insecure Direct Object Reference (IDOR) or Business Logic Abuse. MiddleBrick scans identify this pattern during black-box testing by observing whether unchecked input fields propagate into DynamoDB write calls and by flagging missing validation or authorization checks as part of the Property Authorization and Input Validation checks.

Remediation focuses on strict input validation and separating user-supplied data from server-controlled metadata before constructing DynamoDB expressions. Use explicit structs with json:"-" for internal fields, and validate required fields before constructing request parameters for DynamoDB. Prefer binding to a DTO (Data Transfer Object) and mapping only approved fields into the DynamoDB attribute map.

Example: Safe PutItem with filtered mapping

// DOCTYPE: imports
import (
	"context"
	"encoding/json"
	"net/http"

	"github.com/go-chi/chi/v5"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

// SafeDTO limits what the client can set.
type SafeDTO struct {
	UserID   string `json:"userId" validate:"required"`
	ItemID   string `json:"itemId" validate:"required"`
	Quantity int    `json:"quantity" validate:"gte=0"`
	// Do not include fields like "created_at", "owner_id", or "version" here.
}

// Handler demonstrates controlled mapping to DynamoDB attributes.
func createItemHandler(db *dynamodb.Client) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		var dto SafeDTO
		if err := json.NewDecoder(r.Body).Decode(&dto); err != nil {
			http.Error(w, "invalid payload", http.StatusBadRequest)
			return
		}
		// Server-controlled metadata can be injected here.
		item := map[string]types.AttributeValue{
			"user_id": &types.AttributeValueMemberS{Value: dto.UserID},
			"item_id": &types.AttributeValueMemberS{Value: dto.ItemID},
			"quantity": &types.AttributeValueMemberN{Value: itoa(int64(dto.Quantity))},
			// Server-controlled attributes are added explicitly.
			"created_at": &types.AttributeValueMemberS{Value: "2024-01-01T00:00:00Z"}, // use time.Now().UTC() in practice
		}
		_, err := db.PutItem(r.Context(), &dynamodb.PutItemInput{
			TableName:                 aws.String("Items"),
			Item:                      item,
			ConditionExpression:       aws.String("attribute_not_exists(item_id)"),
		})
		if err != nil {
			http.Error(w, "failed to create item", http.StatusInternalServerError)
			return
		}
		w.WriteHeader(http.StatusCreated)
	}
}

Example: Safe UpdateItem with expression building

// UpdateItem safely merges user input with server-controlled expressions.
func updateItemHandler(db *dynamodb.Client) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		itemID := chi.URLParam(r, "itemID")
		var dto SafeDTO
		if err := json.NewDecoder(r.Body).Decode(&dto); err != nil {
			http.Error(w, "invalid payload", http.StatusBadRequest)
			return
		}
		updateInput := &dynamodb.UpdateItemInput{
			TableName: aws.String("Items"),
			Key: map[string]types.AttributeValue{
				"item_id": &types.AttributeValueMemberS{Value: itemID},
			},
			UpdateExpression: aws.String("set quantity = :q"),
			ExpressionAttributeValues: map[string]types.AttributeValue{
				":q": &types.AttributeValueMemberN{Value: itoa(int64(dto.Quantity))},
			},
			ConditionExpression: aws.String("attribute_exists(item_id)"),
		}
		_, err := db.UpdateItem(r.Context(), updateInput)
		if err != nil {
			http.Error(w, "failed to update item", http.StatusInternalServerError)
			return
		}
		w.WriteHeader(http.StatusOK)
	}
}

Additional measures include using server-side validation libraries, rejecting unknown JSON keys during decoding, and ensuring that DynamoDB condition expressions reference server-controlled attributes rather than user input. MiddleBrick can highlight insecure binding patterns and missing field-level authorization as part of its Property Authorization and Input Validation checks.