Insecure Direct Object Reference in Echo Go with Api Keys

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes internal object identifiers (such as numeric IDs or UUIDs) without verifying that the authenticated subject has permission to access the specific resource. In Echo Go, this commonly arises when route parameters like :id are used directly to index into a data store without an authorization check tied to the request.

When API keys are used for authentication rather than a full identity (e.g., JWT with user claims), the risk of BOLA/IDOR increases if the API key is treated as a surrogate owner. For example, an API key may be issued to a tenant or organization, but if the handler only validates the presence of the key and not that the resource identified by :id belongs to that tenant, an attacker can iterate over numeric IDs and access other tenants’ data. This is a BOLA/IDOR issue because the authorization boundary is enforced at the key level rather than at the resource-owner level.

Echo Go handlers often look like this in vulnerable form:

func getProfile(c echo.Context) error {
    apiKey := c.Request().Header.Get("X-API-Key")
    if apiKey == "{KEY_FROM_DB}" {
        id := c.Param("id")
        profile, err := store.GetProfile(id) // No check that profile belongs to the API key owner
        if err != nil {
            return echo.NewHTTPError(http.StatusNotFound)
        }
        return c.JSON(http.StatusOK, profile)
    }
    return echo.NewHTTPError(http.StatusUnauthorized)
}

In this pattern, store.GetProfile(id) retrieves a profile by ID, but there is no check that the profile’s tenant or owner matches the API key’s scope. Because the scan testing performed by middleBrick includes BOLA/IDOR checks in parallel with authentication and authorization analyses, it can detect that the endpoint exposes an object reference without proper ownership validation. Even though the API key confirms some form of access, the absence of a resource-to-owner mapping enables horizontal privilege escalation across users sharing the same key scope.

Compounding the issue, if the API key is leaked or shared, the attack surface grows: an attacker who knows the endpoint structure can iterate over IDs without needing user credentials. MiddleBrick’s unauthenticated scan surface testing exercises paths like this with crafted parameter variations to confirm whether object references are safely scoped. The finding will typically map to OWASP API Top 10 A01:2023 — Broken Object Level Authorization and may intersect with compliance frameworks such as PCI-DSS and SOC2 where data separation is required.

To summarize, the combination of Echo Go endpoints, API keys used for authentication, and missing resource ownership checks creates a BOLA/IDOR vulnerability. The API key verifies identity at a coarse granularity but does not prevent an attacker from traversing other objects within the same authorization scope, because the handler never validates that the requested object belongs to the key’s subject.

Remediation focuses on ensuring that every access to a resource validates both the API key and the ownership or scope of that resource. Instead of treating the API key as a global permission, bind the key to a tenant or owner and enforce that binding in the handler.

First, model the relationship between API keys and owners. For example, maintain a lookup that maps a key to a tenant ID:

// KeyToTenant maps an API key to its owning tenant ID
var keyToTenant = map[string]string{
    "abc123": "tenant-a",
    "def456": "tenant-b",
}

// ProfileStore abstracts data access
type ProfileStore struct { /* ... */ }

func (s *ProfileStore) GetProfileByTenant(tenantID, id string) (*Profile, error) {
    // SELECT * FROM profiles WHERE tenant_id = $1 AND id = $2
    // Return profile or error
}

Then update the handler to derive the tenant from the key and pass it to the data layer:

func getProfile(c echo.Context) error {
    apiKey := c.Request().Header.Get("X-API-Key")
    tenantID, ok := keyToTenant[apiKey]
    if !ok {
        return echo.NewHTTPError(http.StatusUnauthorized)
    }

    id := c.Param("id")
    profile, err := store.GetProfileByTenant(tenantID, id) // Tenant-aware fetch
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound)
    }
    return c.JSON(http.StatusOK, profile)
}

This change ensures that even if an attacker guesses or iterates over IDs, they cannot access resources outside their tenant because the query is scoped by tenantID. The mapping between API keys and tenants should be stored securely and rotated if compromised; consider short-lived keys or additional context (such as JWTs) for richer authorization in higher-tier plans.

For more flexibility, you can attach owner metadata to the key at lookup time and assert it against the resource’s owner field. MiddleBrick’s scans will re-check BOLA/IDOR after such fixes to confirm that object-level permissions now align with the key’s scope. In the Pro plan, continuous monitoring can alert you if new endpoints introduce similar flaws, and the GitHub Action can gate merges when risk scores exceed your defined thresholds.

Finally, ensure that error messages do not leak whether a key is valid but insufficiently scoped; use generic not-found responses to avoid information disclosure that could aid enumeration.