Beast Attack in Echo Go with Bearer Tokens

A Beast Attack (BOLA/IDOR) in an Echo Go service that uses Bearer Tokens can occur when authorization checks are incomplete or misaligned with token claims. Even when tokens are presented via the Authorization header as Bearer <token>, an endpoint may incorrectly trust path or query parameters to identify the resource owner, allowing an attacker to modify IDs to access other users' data.

In Echo Go, this typically arises when a route like /users/:id/profile extracts the parameter with c.Param("id") and uses it directly to query a database without verifying that the authenticated subject (from the Bearer Token) owns that ID. The token may still be valid and accepted, so the request passes authentication, but the missing or weak authorization step turns the call into an Insecure Direct Object Reference (IDOR). If the token has broad scopes or lacks fine-grained claims, the risk increases because the server may not enforce per-user boundaries at the data layer.

An attacker can intercept or generate a Bearer Token for a low-privilege account, then send crafted requests to other IDs, testing for predictable numeric or UUID identifiers. If Echo Go does not enforce a consistent policy that ties the token’s subject (e.g., sub claim) to the resource ID on every request, the API exposes a BOLA/IDOR vector. This is a broken access control issue mapped to OWASP API Top 10 A1: Broken Object Level Authorization and can be discovered by scanners that cross-reference OpenAPI spec definitions with runtime behavior, highlighting mismatches between declared security schemes and actual enforcement.

For example, an OpenAPI spec may define a security scheme using bearerAuth with a bearer format, but the handler might skip verifying ownership when the token is accepted. The scanner checks whether endpoints that require a token also validate resource ownership against the authenticated subject, producing findings with severity and remediation guidance. Continuous monitoring helps detect regressions when changes to routes or token usage alter the authorization surface.

Remediation centers on ensuring that every request validates both the Bearer Token and the resource ID against the authenticated subject. In Echo Go, extract identity from the token and enforce ownership before querying data.

package main

import (
	"net/http"
	"strings"

	"github.com/labstack/echo/v4"
	"github.com/labstack/echo/v4/middleware"
)

type Claims struct {
	Sub string `json:"sub"`
}

// JWT middleware example using middleware.JWT
func authMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
	return func(c echo.Context) error {
		user := c.Get("user")
		claims, ok := user.(*Claims)
		if !ok {
			return echo.NewHTTPError(http.StatusUnauthorized, "invalid token claims")
		}
		c.Set("subject", claims.Sub)
		return next(c)
	}
}

// Handler that safely ties resource ID to token subject
func GetUserProfile(c echo.Context) error {
	subject := c.Get("subject").(string)
	requestedID := c.Param("id")
	if subject != requestedID {
		return echo.NewHTTPError(http.StatusForbidden, "access denied")
	}
	// proceed to fetch profile for subject
	return c.JSON(http.StatusOK, map[string]string{"id": subject, "profile": "..."})
}

func main() {
	e := echo.New()
	e.Use(middleware.JWTWithConfig(middleware.JWTConfig{
		SigningKey:    []byte("your-secret"),
		ClaimsParser:  func(token *jwt.Token) (interface{}, error) { return &Claims{}, nil },
		ContextKey:    "user",
		AuthScheme:    "Bearer",
	}))
	e.GET("/users/:id/profile", authMiddleware(GetUserProfile))
	e.Logger.Fatal(e.Start(":8080")))
}

The example shows how to configure JWT middleware with Bearer scheme, parse a custom Claims type that includes a subject, and enforce that the subject matches the :id path parameter. This ensures that even when a valid Bearer Token is presented, a user cannot access another user’s profile by altering the ID.

For broader protection, apply similar checks across all endpoints, especially those with predictable identifiers. Combine this with input validation for IDs and use the CLI tool to scan from terminal with middlebrick scan <url> to detect remaining BOLA/IDOR risks. If you need continuous coverage and CI/CD enforcement, the Pro plan supports continuous monitoring and can integrate as a GitHub Action to fail builds when risk scores drop below your chosen threshold.