Bola Idor in Echo Go with Cockroachdb

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce proper authorization checks between a user and a specific resource identifier. In an Echo Go service using CockroachDB, the typical pattern is a route like /users/{userID}/profile where userID is taken from the URL and directly used in SQL queries. If the handler does not verify that the authenticated user matches the requested userID, an attacker can change the ID to access another user’s data.

When CockroachDB is the backend, the risk is shaped by how identifiers are stored and joined. For example, if user profiles are stored in a profiles table with a user_id column and the handler constructs a query like:

rows, err := db.Query("SELECT email, display_name FROM profiles WHERE user_id = $1", userID)

and returns the first row without confirming that the authenticated subject owns that user_id, the endpoint becomes vulnerable. An attacker authenticated as user A can simply replace userID in the request with user B’s ID and retrieve or modify data they should not see or edit. This is a classic BOLA/IDOR finding identified by middleBrick’s BOLA/IDOR check, which tests whether the server enforces ownership on a per-resource basis.

Echo Go applications often exacerbate this when route parameters are loosely typed or when multiple data sources are joined. For instance, consider a handler that first fetches a tenant_id from a user_tenants join table using the provided userID, then uses that tenant_id to query tenant-specific settings:

var tenantID string
err := db.QueryRow("SELECT tenant_id FROM user_tenants WHERE user_id = $1", userID).Scan(&tenantID)

If the second query uses tenantID without revalidating that the authenticated user belongs to that tenant, horizontal privilege escalation across tenants becomes possible. middleBrick’s property-level authorization checks look for such gaps where a reference value from the database is used to constrain queries without corresponding access checks.

Because CockroachDB supports complex joins and secondary indexes, developers may assume that database constraints alone are sufficient. However, BOLA is an application-layer issue: the API must assert that the requesting subject has permission for the specific resource. middleBrick’s scan will flag this when it observes that runtime responses differ from spec-defined authorization expectations, especially when an unauthenticated or low-privilege context can retrieve data by manipulating IDs.

To fix BOLA in Echo Go with CockroachDB, enforce ownership checks in every handler that accesses user-specific resources. Use the authenticated subject from the session or token, compare it with the ID in the URL, and only then build the SQL query. Avoid relying on client-supplied IDs for row ownership.

Below is a secure pattern using github.com/labstack/echo/v4 and github.com/lib/pq (or a CockroachDB-compatible driver) with explicit subject-to-ID validation:

func getProfile(c echo.Context) error {
    // Authenticated subject from JWT or session, set by middleware
    subjectID := c.Get("user_id").(string)
    // URL parameter provided by the client
    userID := c.Param("userID")

    // BOLA mitigation: ensure the subject matches the requested ID
    if subjectID != userID {
        return echo.NewHTTPError(http.StatusForbidden, "access denied")
    }

    var email, displayName string
    // Use parameterized queries to avoid injection; CockroachDB supports $1-style placeholders
    err := db.QueryRow(context.Background(),
        "SELECT email, display_name FROM profiles WHERE user_id = $1", userID).Scan(&email, &displayName)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError, err.Error())
    }

    return c.JSON(http.StatusOK, map[string]string{
        "email":        email,
        "display_name": displayName,
    })
}

For multi-tenant scenarios, validate the tenant relationship explicitly rather than inferring it from the user ID alone:

func getTenantSettings(c echo.Context) error {
    subjectID := c.Get("user_id").(string)
    requestedUserID := c.Param("userID")

    var tenantID string
    // Confirm the user belongs to the tenant they are trying to access
    err := db.QueryRow(context.Background(),
        "SELECT tenant_id FROM user_tenants WHERE user_id = $1", requestedUserID).Scan(&tenantID)
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound, "user not found")
    }

    // Ensure the authenticated subject is a member of this tenant
    var membership bool
    err = db.QueryRow(context.Background(),
        "SELECT has_tenant_access($1, $2)", subjectID, tenantID).Scan(&membership)
    if err != nil || !membership {
        return echo.NewHTTPError(http.StatusForbidden, "tenant access denied")
    }

    var settings map[string]interface{}
    err = db.QueryRow(context.Background(),
        "SELECT settings FROM tenant_settings WHERE tenant_id = $1", tenantID).Scan(&settings)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError, err.Error())
    }

    return c.JSON(http.StatusOK, settings)
}

Additionally, apply principle of least privilege to the CockroachDB role used by the service. Avoid using a superuser; instead, define a role with SELECT/INSERT/UPDATE only on the necessary tables. This reduces the impact of any residual misconfiguration. middleBrick’s CLI can be used to verify that these controls are reflected in the runtime behavior by running:

middlebrick scan <your-api-url>

In the dashboard, you can track how these fixes affect your security score over time, and with the Pro plan you can enable continuous monitoring so that regressions are caught before deployment. The GitHub Action can fail a build if a BOLA pattern is detected in the scan results, and the MCP Server allows you to run checks directly from compatible AI coding assistants.