Bola Idor in Echo Go with Api Keys

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce access controls at the object level, allowing one user to read or modify another user’s resources. In Echo Go, this often arises when endpoints rely only on API keys for authentication and use an identifier such as :id or :owner in the route without verifying that the requesting entity owns that object.

Consider an Echo Go handler that retrieves a user profile using an API key for authentication but does not check whether the profile belongs to the key owner:

func GetProfile(c echo.Context) error {
    apiKey := c.Request().Header.Get("X-API-Key")
    userID := c.Param("user_id")

    // Fetch user by API key (e.g., from a lookup map or DB)
    owner, err := lookupUserByAPIKey(apiKey)
    if err != nil {
        return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid api key"})
    }

    // BOLA: No check that userID == owner.ID
    profile, err := getProfileByID(userID)
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "server error"})
    }
    return c.JSON(http.StatusOK, profile)
}

An attacker who knows another user’s numeric ID can call this endpoint with their own valid API key but supply the victim’s user_id. Because the handler does not enforce that the requested user_id matches the owner derived from the API key, this is a BOLA vulnerability. The API key provides authentication (who you are) but not proper authorization (what you are allowed to access).

This combination is especially risky when API keys are long-lived or shared across services, increasing the chance of inadvertent exposure. Without object-level checks, horizontal BOLA allows lateral access across accounts at the same privilege level, while vertical BOLA can permit lower-privilege keys to access admin-like data if identifiers are predictable.

In Echo Go, the risk is amplified when route parameters are cast to numeric types without verifying ownership and when middleware only validates the presence of a key rather than its scope. Attack patterns such as ID enumeration and tampered parameters become straightforward if object-level authorization is omitted.

To fix BOLA in Echo Go when using API keys, ensure that every object request validates the relationship between the authenticated subject (derived from the key) and the requested resource. Below is a secure pattern that performs this check before accessing the object.

func GetProfile(c echo.Context) error {
    apiKey := c.Request().Header.Get("X-API-Key")
    userID := c.Param("user_id")

    // Authenticate: resolve API key to an owner
    owner, err := lookupUserByAPIKey(apiKey)
    if err != nil {
        return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid api key"})
    }

    // Authorize: ensure the requested ID matches the authenticated owner
    if owner.ID != userID {
        return c.JSON(http.StatusForbidden, map[string]string{"error": "access denied to this resource"})
    }

    profile, err := getProfileByID(userID)
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "server error"})
    }
    return c.JSON(http.StatusOK, profile)
}

Additional defensive measures include using opaque identifiers (e.g., UUIDs) instead of sequential integers to reduce ID enumeration, enforcing least-privilege scopes in key metadata, and validating parameters before casting. Middleware can centralize ownership checks to avoid repetition:

func RequireResourceOwner(c echo.Context, next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        apiKey := c.Request().Header.Get("X-API-Key")
        resourceID := c.Param("resource_id")

        owner, err := lookupUserByAPIKey(apiKey)
        if err != nil {
            return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid api key"})
        }

        if owner.ID != resourceID {
            return c.JSON(http.StatusForbidden, map[string]string{"error": "access denied to this resource"})
        }

        // Attach owner to context for downstream handlers
        c.Set("owner", owner)
        return next(c)
    }
}

When integrating with third-party services or microservices, propagate the authenticated subject (owner ID) alongside the API key and enforce authorization at each boundary. Regularly rotate keys and monitor anomalous access patterns to reduce exposure from compromised credentials.