Insecure Direct Object Reference in Echo Go with Bearer Tokens

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes internal object references (e.g., numeric IDs, UUIDs) without verifying that the requesting identity has permission to access the specific resource. In Echo Go, this commonly arises when route handlers use path parameters such as /users/{id} and directly fetch or act on the record identified by id after validating a Bearer token, but without confirming that the authenticated subject owns or is authorized for that id.

Bearer tokens typically carry user identity (e.g., a subject claim like sub) but do not encode object-level permissions. If the API trusts the token’s identity yet fails to enforce authorization between that identity and the requested resource, BOLA/IDOR is introduced. For example, a token for user Alice might include sub: alice, but if the handler does not compare alice with the owner of the requested id, an attacker can increment or guess IDs to access other users’ data. This becomes an authenticated vulnerability: the presence of a valid Bearer token reduces suspicion and may bypass IP-based or network-level controls, increasing the impact compared to purely unauthenticated endpoints.

Consider an Echo Go handler that decodes a Bearer token to extract the subject, then uses the path ID without ownership validation:

package main

import (
	"net/http"

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

type UserService struct{}

func (s *UserService) GetProfile(c echo.Context) error {
	token := middleware.GetConfig(middleware.JWTConfig{}).TokenLookup[c.Request().Context()]
	claims, ok := token.Claims.(map[string]interface{})
	if !ok {
		return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid token claims"})
	}
	sub, ok := claims["sub"].(string)
	if !ok {
		return c.JSON(http.StatusUnauthorized, map[string]string{"error": "missing subject"})
	}

	// ID from path: /profile/{id}
	id := c.Param("id")

	// BOLA/IDOR risk: no check that sub owns id
	profile, err := s.fetchProfileByID(id)
	if err != nil {
		return c.JSON(http.StatusInternalServerError, map[string]string{"error": "unable to fetch"})
	}
	return c.JSON(http.StatusOK, profile)
}

func main() {
	e := echo.New()
	e.Use(middleware.JWTWithConfig(middleware.JWTConfig{
		SigningKey: []byte("secret"),
	})) // Bearer token required
	e.GET("/profile/:id", GetProfile)
	e.Logger.Fatal(e.Start(":8080"))
}

In this pattern, the token proves identity but does not prove authorization over the supplied :id. An attacker who obtains a valid Bearer token for Alice can request /profile/123 (where 123 belongs to Bob) and, without additional checks, receive Bob’s profile. The vulnerability is specific to the combination of ID-based routing and missing ownership or tenant checks after token validation. Tools like middleBrick detect this pattern by correlating the unauthenticated scan’s Bearer token handling with BOLA/IDOR checks, highlighting cases where path parameters are used as direct object references without authorization.

To align with frameworks such as OWASP API Top 10, this is classified under Broken Object Level Authorization (BOLA), which maps to common compliance frameworks including PCI-DSS and SOC2. middleBrick’s scans include this check among its 12 parallel security checks and will surface such BOLA findings with severity and remediation guidance.

Remediation focuses on ensuring that after Bearer token identity is established, every object-level operation validates that the identity is allowed to access the requested resource. In Echo Go, this means explicitly comparing the subject from the token with the ownership or ACL of the resource identified by the path parameter before performing any operation.

Below is a corrected handler that fetches the profile only when the subject matches the profile owner. This example assumes fetchProfileByOwner enforces ownership at the data layer, which is preferred over fetching then filtering in application code.

package main

import (
	"net/http"

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

type ProfileService struct{}

func (s *ProfileService) GetProfile(c echo.Context) error {
	token := middleware.GetConfig(middleware.JWTConfig{}).TokenLookup[c.Request().Context()]
	claims, ok := token.Claims.(map[string]interface{})
	if !ok {
		return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid token claims"})
	}
	sub, ok := claims["sub"].(string)
	if !ok {
		return c.JSON(http.StatusUnauthorized, map[string]string{"error": "missing subject"})
	}

	// ID from path: /profile/:id
	id := c.Param("id")

	// Enforce ownership: fetch only if subject owns id
	profile, err := s.fetchProfileByOwner(c.Request().Context(), sub, id)
	if err != nil {
		// Use a generic message to avoid leaking existence differences
		return c.JSON(http.StatusForbidden, map[string]string{"error": "access denied"})
	}
	return c.JSON(http.StatusOK, profile)
}

// Example signature; implement server-side filtering or row-level security.
func (s *ProfileService) fetchProfileByOwner(ctx context.Context, owner, id string) (map[string]interface{}, error) {
	// Ideally a query such as:
	// SELECT * FROM profiles WHERE id = $1 AND owner = $2
	// This ensures the ID cannot be accessed unless the subject is the owner.
	// Placeholder implementation:
	if owner == "alice" && id == "alice-profile" {
		return map[string]interface{}{"id": id, "owner": owner}, nil
	}
	return nil, http.ErrAbortHandler
}

func main() {
	e := echo.New()
	e.Use(middleware.JWTWithConfig(middleware.JWTConfig{
		SigningKey: []byte("secret"),
	})) // Bearer token required
	e.GET("/profile/:id", GetProfile)
	e.Logger.Fatal(e.Start(":8080"))
}

Additional recommendations include using UUIDs instead of sequential integers to reduce enumeration risk, applying row-level security in your data store, and ensuring that any caching layer respects tenant boundaries. middleBrick’s CLI can be used to validate these fixes by rescans; the GitHub Action can gate CI/CD if a BOLA finding persists above your chosen threshold, and the MCP Server allows you to trigger scans directly from your IDE while iterating on fixes.

Finally, combine these code-level checks with runtime monitoring and periodic scans. The Pro plan provides continuous monitoring for such changes, and the Dashboard lets you track how scores evolve as you address findings. Remember that middleBrick detects and reports—developers must apply the fixes and verify with scans.