Bola Idor in Gorilla Mux with Dynamodb

BOLA (Broken Level of Authorization) / IDOR occurs when an API exposes a direct object reference and lacks authorization checks so that one user can view or modify another user’s resource. Using Gorilla Mux for routing together with Amazon DynamoDB as the backend can unintentionally create this condition when route parameters that identify an item are passed directly to DynamoDB without validating that the requesting user owns or is allowed to access that item.

In a typical Go service, you define a route like /users/{userID}/items/{itemID} with Gorilla Mux and extract both userID and itemID from the URL. If the handler then builds a DynamoDB GetItem or QueryInput using only itemID as the key (or a composite primary key where the partition key is derived from itemID) and does not also enforce that the userID in the route matches the owner of that item in DynamoDB, the endpoint becomes vulnerable. An attacker who knows or guesses another user’s itemID can issue requests with their own authenticated userID but supply the target itemID, and the service will retrieve or modify that item because no authorization check ties the item to the requesting user.

DynamoDB intensifies the risk in this pattern because primary keys are often designed for fast lookup rather than for enforcing ownership. For example, you might use a composite key like PK = USER#userID and SK = ITEM#itemID. If the handler only uses itemID to construct the key and omits the userID portion, or if it queries a Global Secondary Index that does not include user ownership, the same itemID may resolve to a different logical record across users. This enables horizontal privilege escalation: one user acting on another user’s resource. Common secondary indexes, such as a GSI on item metadata, can further obscure the missing ownership check because they may return items not intended for the caller’s scope.

Another subtlety arises when the route supplies only an itemID and the handler performs a scan or query on a GSI that lacks a userID filter expression. Without a proper FilterExpression that restricts results to the authenticated user’s partition, the query may return sensitive data. Real-world attack patterns include enumerating itemIDs sequentially or iterating through known keys, which is especially dangerous when responses include PII or secrets. These issues map directly to the OWASP API Top 10 (2023) and can also conflict with compliance frameworks such as SOC2 and GDPR if personal data is exposed across tenant boundaries.

To illustrate, consider a handler that extracts route variables and builds a GetItemInput without tying the request to the authenticated user. Even with TLS and authentication in place, the missing ownership check remains a logical authorization flaw. The fix is not to change DynamoDB’s data model, but to ensure every request validates that the resource being accessed belongs to the requester, typically by including the userID in the key construction and in any query filter expressions.

Remediation centers on enforcing ownership at the data-access layer. In Gorilla Mux, after extracting route parameters, you must combine the authenticated user identifier with the item identifier to form a complete primary key or to build a filter that guarantees the item belongs to the user. Below are concrete, idiomatic examples in Go using the AWS SDK for DynamoDB.

1. Proper key construction with composite primary keys

Design your DynamoDB table so that the partition key includes the user identifier. Then, in the handler, construct the key from both values. This ensures GetItem and DeleteItem affect only records under the requesting user.

// route: /users/{userID}/items/{itemID}
params := mux.Vars(r)
userID := params["userID"]
itemID := params["itemID"]

input := &dynamodb.GetItemInput{
    TableName: aws.String("UserItems"),
    Key: map[string]types.AttributeValue{
        "PK": &types.AttributeValueMemberS{Value: "USER#" + userID},
        "SK": &types.AttributeValueMemberS{Value: "ITEM#" + itemID},
    },
}
result, err := svc.GetItem(context.TODO(), input)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}
if result.Item == nil {
    http.Error(w, "not found", http.StatusNotFound)
    return
}
// result.Item is guaranteed to belong to userID

2. Query with explicit ownership filter on GSIs

If you must use a Global Secondary Index that does not include userID as the partition key, add a FilterExpression that asserts ownership. This prevents the index from returning items belonging to other users.

params := mux.Vars(r)
userID := params["userID"]
itemID := params["itemID"]

input := &dynamodb.QueryInput{
    TableName: aws.String("UserItems"),
    IndexName: aws.String("ItemMetadataIndex"),
    KeyConditionExpression: aws.String("metadataKey = :mk"),
    FilterExpression:       aws.String("userID = :uid"),
    ExpressionAttributeValues: map[string]types.AttributeValue{
        ":mk": &types.AttributeValueMemberS{Value: "METADATA#" + itemID},
        ":uid": &types.AttributeValueMemberS{Value: userID},
    },
}
result, err := svc.Query(context.TODO(), input)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}
if len(result.Items) == 0 {
    http.Error(w, "not found or access denied", http.StatusNotFound)
    return
}
// Only items where userID matches are returned

3. Avoid client-supplied keys where feasible; use user-scoped queries

Instead of trusting a client-provided itemID as the sole identifier, derive or list items under the user’s namespace. For example, query all items for a user with a begins_with on the SK prefix, or generate itemIDs server-side and return references that embed the user context.

params := mux.Vars(r)
userID := params["userID"]

input := &dynamodb.QueryInput{
    TableName: aws.String("UserItems"),
    KeyConditionExpression: aws.String("PK = :pk AND begins_with(SK, :skprefix)"),
    ExpressionAttributeValues: map[string]types.AttributeValue{
        ":pk": &types.AttributeValueMemberS{Value: "USER#" + userID},
        ":skprefix": &types.AttributeValueMemberS{Value: "ITEM#"},
    },
}
result, err := svc.Query(context.TODO(), input)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}
// Returns only items owned by the authenticated user

4. Validate and canonicalize identifiers

Ensure itemID values are normalized (e.g., trim spaces, enforce UUID format) before using them in key construction to avoid bypass attempts via encoded or malformed keys. Combine this with middleware that enforces authentication and extracts the user identity so handlers can rely on a verified userID.

5. Use middleware to inject user context

With Gorilla Mux, you can use middleware to attach the authenticated userID to the request context, which handlers then use when building DynamoDB inputs. This centralizes ownership checks and reduces the risk of accidentally omitting the userID in a given handler.

func AuthMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        userID := extractUserIDFromToken(r)
        ctx := context.WithValue(r.Context(), "userID", userID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// In handler
userID := r.Context().Value("userID").(string)
// use userID when constructing keys or filter expressions

By consistently combining the authenticated userID with DynamoDB key construction and filter expressions, you enforce authorization at the data layer and mitigate BOLA/IDOR risks in a Gorilla Mux service backed by DynamoDB.