Broken Access Control in Gorilla Mux with Mongodb

Broken Access Control occurs when authorization checks are missing or inconsistent, allowing attackers to access resources they should not. The combination of Gorilla Mux and MongoDB can unintentionally expose this vulnerability when route parameters are used to construct database queries without validating that the authenticated subject has permission to access the targeted document.

In a typical REST setup using Gorilla Mux, an endpoint like /users/{userID}/profile extracts userID from the URL path. If the handler directly uses that userID to query MongoDB with a filter such as {"_id": userID} and omits a server-side ownership or role check, any authenticated user can change the userID in the request to view or modify another user’s data. This is a classic Insecure Direct Object Reference (IDOR), which is a subset of Broken Access Control.

Another scenario involves privilege escalation when Gorilla Mux routes differentiate behavior based on claims in a JWT (e.g., role: user vs role: admin). If the handler relies only on the client-supplied role embedded in the token and does not re-validate authorization against MongoDB — for example, by checking a user’s admin flag stored in the database — an attacker who obtains or guesses an admin’s ID can perform actions reserved for administrators. MongoDB does not enforce application-level permissions by itself; it enforces access at the connection and database level. Therefore, if the application does not enforce per-document authorization, the database will return data the user should not see or allow updates the user should not perform.

BOLA (Broken Object Level Authorization) often manifests when an API uses predictable identifiers, such as MongoDB ObjectIDs, and fails to ensure that the requesting user’s identity matches the object’s owner. For instance, a handler might fetch a document by ID and return it without verifying that the authenticated subject has the right to access that specific document. Because MongoDB returns the document if the ID exists and the connection has sufficient privileges, the application must implement explicit checks. Without these checks, the API surface becomes vulnerable to unauthorized read and write operations across different resource types, including nested resources like /organizations/{orgID}/settings.

Middleware in Gorilla Mux can mitigate some of these risks by inspecting claims or session state before reaching the handler, but it must enforce consistent rules that align with MongoDB document ownership. Relying solely on route-level restrictions or client-provided identifiers without server-side validation shifts the burden to the developer and increases the likelihood of insecure direct object references and privilege escalation.

Remediation centers on ensuring that every MongoDB query includes a tenant or ownership filter tied to the authenticated subject, and that role or permission checks are performed against the database state rather than client-supplied claims alone.

Example 1: User-specific endpoint with proper ownership check. The handler validates that the requested profile belongs to the authenticated user by including the user ID in the MongoDB filter.

// Gorilla Mux handler with MongoDB ownership check
func getProfileHandler(store *MongoStore) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        requestedUserID := vars["userID"]
        // authenticated subject from context or token validation
        subjectID := r.Context().Value("userID").(string)
        if requestedUserID != subjectID {
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }
        var profile Profile
        // MongoDB filter includes both ID and ensures users only access their own data
        err := store.Collection("profiles").FindOne(r.Context(), bson.M{"_id": subjectID}).Decode(&profile)
        if err != nil {
            http.Error(w, "not found", http.StatusNotFound)
            return
        }
        json.NewEncoder(w).Encode(profile)
    }
}

Example 2: Admin-scoped endpoint with role verification from MongoDB. Instead of trusting a role claim in the JWT, the handler fetches the user document from MongoDB and confirms admin status server-side.

// Gorilla Mux handler with MongoDB role verification
func adminHandler(store *MongoStore) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        subjectID := r.Context().Value("userID").(string)
        var user User
        err := store.Collection("users").FindOne(r.Context(), bson.M{"_id": subjectID}).Decode(&user)
        if err != nil || !user.IsAdmin {
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }
        // Proceed with admin logic
        var settings bson.M
        store.Collection("settings").FindOne(r.Context(), bson.M{"orgID": user.OrgID}).Decode(&settings)
        json.NewEncoder(w).Encode(settings)
    }
}

Example 3: Scoped access to organization resources. The handler ensures the authenticated user belongs to the requested organization by checking a membership collection in MongoDB.

// Gorilla Mux handler with MongoDB membership check
func orgSettingsHandler(store *MongoStore) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        orgID := vars["orgID"]
        subjectID := r.Context().Value("userID").(string)
        var membership Membership
        // Verify user is a member of the organization
        err := store.Collection("memberships").FindOne(r.Context(), bson.M{"userID": subjectID, "orgID": orgID}).Decode(&membership)
        if err != nil {
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }
        var settings bson.M
        err = store.Collection("settings").FindOne(r.Context(), bson.M{"orgID": orgID}).Decode(&settings)
        if err != nil {
            http.Error(w, "not found", http.StatusNotFound)
            return
        }
        json.NewEncoder(w).Encode(settings)
    }
}

These patterns enforce authorization in the application layer and ensure that MongoDB queries always include filters that align the database scope with the authenticated subject’s permissions. Using parameterized queries and avoiding direct concatenation of user input into filters prevents injection and reduces the attack surface for Broken Access Control.