Bola Idor in Gin with Basic Auth

Broken Level of Authorization (BOLA) is an API-specific manifestation of IDOR where a user can access or modify resources that should belong to another user, typically because authorization checks are missing or insufficient. When Basic Auth is used in a Gin application without a strict one-to-one mapping between authenticated identity and resource ownership, BOLA becomes likely.

In Gin, Basic Auth is commonly implemented via middleware that extracts credentials from the Authorization header, decodes the base64-encoded username:password, and attaches the username (or a parsed user object) to the request context. A vulnerable pattern looks up a user by the provided username but then constructs resource URLs using an input parameter such as :id without verifying that the resource belongs to that user. For example, a route like GET /users/:id/profile may authenticate the user and decode Basic Auth credentials into ctx.Set("user", user), yet the handler may directly use params("id") to fetch a profile. If the ID in the URL does not map to the authenticated user, an attacker can enumerate numeric or predictable IDs and read or alter other users’ profiles.

Consider an endpoint designed to return a user’s settings:

// Vulnerable example: no ownership check
func GetUserSettings(c *gin.Context) {
    userID := c.Param("id")
    var settings UserSettings
    if err := db.Where("user_id = ?", userID).First(&settings).Error; err != nil {
        c.JSON(404, gin.H{"error": "not found"})
        return
    }
    c.JSON(200, settings)
}

An authenticated request with Basic Auth for user alice can change the id in the URL to /users/bob-id/profile and obtain Bob’ data if the handler does not compare the authenticated user identity with the requested ID. Because Basic Auth does not inherently bind the token to a resource scope, the server must enforce ownership explicitly. Attack patterns include iterating over integer IDs (horizontal BOLA) or manipulating UUIDs or slugs to access unauthorized tenant data (vertical BOLA).

OpenAPI specifications can inadvertently support BOLA when path parameters and security schemes are defined without constraining the relationship between subject and object. A spec may declare that an endpoint requires an API key or Basic Auth but omit a description that the identifier in the path must match the authenticated principal. Runtime scanning can detect these gaps by correlating authentication requirements with the presence of user-controlled identifiers in paths and missing authorization checks in handler logic.

Remediation centers on ensuring that every access to a user-specific resource validates that the resource belongs to the authenticated identity. Do not rely on obscurity or path isolation; enforce ownership checks in the handler or via a shared authorization layer.

1) Bind authenticated identity to the request context and enforce ownership in the handler:

// User represents a minimal authenticated principal
type User struct {
    ID       uint
    Username string
}

// BasicAuthMiddleware extracts credentials and attaches a User to context
func BasicAuthMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, password, ok := c.Request.BasicAuth()
        if !ok {
            c.AbortWithStatusJSON(401, gin.H{"error": "missing credentials"})
            return
        }
        // Validate credentials against your store (pseudo-lookup)
        var u User
        if err := db.Where("username = ?", user).First(&u).Error; err != nil {
            c.AbortWithStatusJSON(401, gin.H{"error": "invalid credentials"})
            return
        }
        // Attach the authenticated user to context
        c.Set("user", u)
        c.Next()
    }
}

// Protected handler with ownership check
func GetUserProfile(c *gin.Context) {
    authUser, _ := c.Get("user")
    authenticated := authUser.(User)

    requestedID := c.Param("id")
    var profile Profile
    // Ensure the profile belongs to the authenticated user
    if err := db.Where("user_id = ? AND id = ?", authenticated.ID, requestedID).First(&profile).Error; err != nil {
        c.JSON(403, gin.H{"error": "forbidden"})
        return
    }
    c.JSON(200, profile)
}

2) Centralize authorization to reduce duplication and mistakes. Create an authorization helper that compares authenticated ID to resource ID:

func EnsureSameUser(c *gin.Context, resourceUserID uint) bool {
    u, _ := c.Get("user")
    auth := u.(User)
    return auth.ID == resourceUserID
}

// Usage in a handler
func UpdateSettings(c *gin.Context) {
    var req struct {
        ID     uint `json:"id" validate:"required"`
        Theme  string
    }
    if err := c.ShouldBindJSON(&req); err != nil {
        c.JSON(400, gin.H{"error": "bad request"})
        return
    }

    var existing UserSettings
    if err := db.First(&existing, req.ID).Error; err != nil {
        c.JSON(404, gin.H{"error": "not found"}); return
    }

    if !EnsureSameUser(c, existing.UserID) {
        c.JSON(403, gin.H{"error": "forbidden"}); return
    }

    existing.Theme = req.Theme
    db.Save(&existing)
    c.JSON(200, existing)
}

3) In your routes, require authentication and avoid exposing raw IDs when unnecessary. Use UUIDs or opaque identifiers that do not leak enumeration patterns, but still validate ownership:

r := gin.Default()
r.Use(BasicAuthMiddleware())

// Prefer binding ID from authenticated context when possible
r.GET("/me/profile", func(c *gin.Context) {
    u, _ := c.Get("user")
    user := u.(User)
    var settings UserSettings
    if err := db.Where("user_id = ?", user.ID).First(&settings).Error; err != nil {
        c.JSON(404, gin.H{"error": "not found"})
        return
    }
    c.JSON(200, settings)
})

These patterns ensure that even when Basic Auth identifies a user, the application explicitly verifies that each resource access is authorized for that user, effectively mitigating BOLA in Gin services.