Bola Idor in Echo Go with Bearer Tokens

Broken Level of Access (BOLA) Insecure Direct Object References (IDOR) occur when an API exposes internal object references (e.g., record IDs) without verifying that the requesting identity has the right to access that specific resource. In Echo Go, this commonly happens when routes use path parameters like /users/{id}/profile and the handler loads the profile by ID from a data store, then checks whether the requesting user matches that ID. When Bearer Tokens are used for authentication, the vulnerability emerges if the token is validated but the handler never confirms that the resource being requested belongs to the authenticated subject.

Consider an Echo Go service that authenticates requests via a Bearer Token in the Authorization header and decodes the subject (e.g., user ID) from the token payload. If the route handler extracts a different identifier from the URL (such as targetUserId) and uses it directly to query a database or object store without comparing it to the subject in the token, an attacker can tamper with that identifier to access other users’ data. For example, User A with a valid Bearer Token could change the request to /users/123/profile where 123 is another user, and if the server only verifies the token is valid but does not enforce that the token’s subject matches the requested resource, User A can view or even modify User B’s profile. This is a classic IDOR/BOLA flaw: authorization is missing or incomplete despite authentication being present.

In Echo Go, this often surfaces when middleware decodes the Bearer Token and attaches claims to the request context, but subsequent business logic bypasses those claims or treats URL parameters as trusted input. Attack techniques include iterating over sequential IDs, swapping identifiers in query strings or headers, or leveraging predictable references (such as UUIDs that are not randomly assigned). Because the API surface is unauthenticated during scanning, middleBrick can detect such authorization gaps by comparing runtime behavior against the claims present in Bearer Tokens and observing whether access checks are enforced across different object references.

Real-world patterns that exacerbate this include using opaque tokens without proper audience/issuer validation, storing sensitive identifiers only in the token without server-side ownership checks, and implementing role-based checks but missing ownership checks. For instance, an endpoint might ensure the token carries an admin role but fail to ensure that a request to /accounts/{accountId} actually belongs to that admin’s permitted set of accounts. This combination of Bearer Tokens and missing ownership validation is a frequent root cause of BOLA/IDOR findings in API security scans, and it maps directly to OWASP API Top 10 A01:2023 Broken Object Level Authorization.

To fix BOLA/IDOR in Echo Go when using Bearer Tokens, always tie the authenticated subject from the token to the resource being requested. Do not trust URL or query parameters alone; enforce ownership or scope checks before accessing or modifying data. Below are concrete code examples that demonstrate secure patterns.

Example 1: Validate token subject against the requested user ID

Parse the Bearer Token, extract the subject claim, and compare it with the ID in the path before loading the resource.

// Assume a helper that validates the Bearer Token and returns a claims map
claims, err := parseBearerToken(r)
if err != nil {
    echoError(ctx, http.StatusUnauthorized, "invalid token")
    return
}

subject, ok := claims["sub"]
if !ok {
    echoError(ctx, http.StatusUnauthorized, "missing subject")
    return
}

// Extract target ID from path
userID := params.Get("userID")
if subject != userID {
    echoError(ctx, http.StatusForbidden, "access denied to this resource")
    return
}

// Proceed to fetch user data knowing subject matches requested ID
user, err := store.GetUser(userID)
if err != nil || user == nil {
    echoError(ctx, http.StatusNotFound, "user not found")
    return
}

ctx.JSON(http.StatusOK, user)

Example 2: Use role-based rules plus ownership for account endpoints

For endpoints that involve account-level access, combine role checks from the token with explicit ownership or allowed-list validation.

claims, err := parseBearerToken(r)
if err != nil {
    echoError(ctx, http.StatusUnauthorized, "invalid token")
    return
}

role, _ := claims["role"]
accountID := params.Get("accountID")

// Fetch the account to verify it exists and belongs to an allowed set
account, err := store.GetAccount(accountID)
if err != nil || account == nil {
    echoError(ctx, http.StatusNotFound, "account not found")
    return
}

// Enforce ownership or role-based scope
if role != "admin" && account.OwnerID != claims["sub"] {
    echoError(ctx, http.StatusForbidden, "insufficient permissions for this account")
    return
}

ctx.JSON(http.StatusOK, account)

Example 3: Centralized authorization middleware for Echo

Implement a reusable middleware that binds the subject from Bearer Tokens to the request context and provides helper functions for downstream handlers to assert ownership.

func AuthMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(ctx echo.Context) error {
        auth := ctx.Request().Header.Get("Authorization")
        if auth == "" {
            return echo.NewHTTPError(http.StatusUnauthorized, "authorization header missing")
        }

        // Expecting "Bearer <token>"
        parts := strings.Split(auth, " ")
        if len(parts) != 2 || parts[0] != "Bearer" {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid authorization format")
        }

        claims, err := parseBearerToken(parts[1])
        if err != nil {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid token")
        }

        // Attach subject and role to context for use in handlers
        ctx.Set("subject", claims["sub"])
        ctx.Set("role", claims["role"])
        return next(ctx)
    }
}

// Handler usage
func GetProfile(c echo.Context) error {
    subject := c.Get("subject").(string)
    requestedID := params.Get("userID")
    if subject != requestedID {
        return echo.NewHTTPError(http.StatusForbidden, "cannot access this profile")
    }
    profile, err := store.GetProfile(requestedID)
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound, "profile not found")
    }
    return c.JSON(http.StatusOK, profile)
}

Operational and testing guidance

• Ensure your Bearer Token validation checks issuer, audience, and expiration to prevent token substitution attacks.
• Use unpredictable identifiers (e.g., UUIDs) for resource IDs to reduce ID enumeration risk, but remember that unpredictability does not replace ownership checks.
• Log authorization failures for audit trails, but avoid exposing sensitive resource identifiers in error messages returned to clients.
• In CI/CD, you can use the middlebrick CLI to scan your Echo Go endpoints: middlebrick scan <url>, and with the Pro plan you can enable continuous monitoring so that regressions in authorization logic are caught early.