Broken Access Control in Echo Go with Api Keys

Broken Access Control occurs when API endpoints do not properly enforce authorization checks, allowing one user to access or modify another user's resources. In Echo Go, a common pattern is to use API keys for authentication but omit or misapply authorization checks at the handler level. When API keys are validated but the application does not verify that the requesting user is allowed to access the specific resource (e.g., by checking ownership or role), the endpoint becomes vulnerable to Broken Access Control (BOLA/IDOR).

Consider an Echo Go handler that retrieves user profile data using a path parameter userID. If the handler only validates the presence of a valid API key and returns the profile for the provided userID without confirming that the key's owner matches that ID, an attacker can iterate through numeric or predictable IDs to view or modify any user's data. This is a classic IDOR scenario enabled by weak authorization logic. For example, an attacker could change their own request from /profiles/123 to /profiles/124 and access profile 124 if the server does not enforce that the authenticated API key corresponds to the requested profile.

Echo Go applications that rely solely on API keys without tying them to a user or scope model are especially at risk. API keys are often long-lived secrets; if they are leaked or intercepted, and the API lacks per-request ownership checks, the attacker gains broad access. Insecure direct object references can also appear in query parameters or headers that the handler trusts without re-verifying against the key's allowed resources. The combination of a permissive CORS policy, verbose error messages, and missing authorization logic amplifies the risk, making it easier to discover and exploit predictable resource identifiers.

Real-world attack patterns include enumeration of IDs in URLs or headers, manipulation of JSON payload fields that the server uses to look up objects, and exploitation of missing ownership checks in administrative endpoints. These patterns map to OWASP API Top 10:2023 #1 Broken Object Level Authorization and can lead to unauthorized read, update, or deletion of data. Proper authorization must validate not only that a key is valid, but also that the key grants the requested action on the specific object, using checks that are consistent across all endpoints.

To remediate Broken Access Control in Echo Go when using API keys, bind key validation to user or scope context and enforce ownership or role checks in every handler. Avoid treating API keys as global permissions; instead, associate each key with an owner or set of permissions and verify those permissions against the target resource.

Below is a secure Echo Go example that demonstrates API key validation with ownership checks. The key is looked up to determine the associated user ID, and the handler ensures the requested resource matches the key owner before proceeding.

// secure_handler.go
package main

import (
    "net/http"
    "strconv"

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

// KeyStore simulates a lookup of API key to user context.
type KeyStore struct{}

type KeyInfo struct {
    OwnerID int
    Scopes  []string
}

func (ks *KeyStore) ValidateKey(key string) (*KeyInfo, bool) {
    // In production, validate against a secure store (e.g., database, vault).
    // This mapping is illustrative.
    switch key {
    case "valid-key-for-user-1":
        return &KeyInfo{OwnerID: 1, Scopes: []string{"read:profile", "write:profile"}}, true
    case "admin-key":
        return &KeyInfo{OwnerID: 0, Scopes: []string{"read:profile", "write:profile", "admin"}}, true
    }
    return nil, false
}

// ProfileHandler retrieves a profile only if the key owner matches the requested ID.
func ProfileHandler(ks *KeyStore) echo.HandlerFunc {
    return func(c echo.Context) error {
        apiKey := c.Request().Header.Get("X-API-Key")
        if apiKey == "" {
            return echo.NewHTTPError(http.StatusUnauthorized, "missing api key")
        }
        keyInfo, ok := ks.ValidateKey(apiKey)
        if !ok {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid api key")
        }

        userID, err := strconv.Atoi(c.Param("userID"))
        if err != nil {
            return echo.NewHTTPError(http.StatusBadRequest, "invalid user id")
        }

        // Critical authorization check: ensure the key owner is the requested user.
        if keyInfo.OwnerID != userID && !hasScope(keyInfo.Scopes, "admin") {
            return echo.NewHTTPError(http.StatusForbidden, "access denied to this resource")
        }

        // Fetch and return the profile for userID, which is guaranteed to be accessible.
        profile, err := getProfileByUserID(userID)
        if err != nil {
            return echo.NewHTTPError(http.StatusNotFound, "profile not found")
        }
        return c.JSON(http.StatusOK, profile)
    }
}

func hasScope(scopes []string, scope string) bool {
    for _, s := range scopes {
        if s == scope {
            return true
        }
    }
    return false
}

// getProfileByUserID is a placeholder for your data access logic.
func getProfileByUserID(id int) (map[string]interface{}, error) {
    // Return a mock profile for demonstration.
    return map[string]interface{}{
        "id":   id,
        "name": "User " + strconv.Itoa(id),
    }, nil
}

Key points in this remediation:

• API key validation returns contextual information (owner ID and scopes) rather than a boolean.
• Each handler explicitly checks that the owner ID matches the requested resource ID unless the key has elevated scopes (e.g., admin).
• Invalid or missing keys result in 401; insufficient permissions result in 403, ensuring clear separation between authentication and authorization failures.

For broader protection, apply this pattern consistently across all endpoints, use middleware to centralize ownership checks where appropriate, and ensure error messages do not leak sensitive information. middleBrick can help detect missing authorization logic through its BOLA/IDOR and Authentication checks, and the Pro plan provides continuous monitoring to catch regressions as your API evolves.