Race Condition in Echo Go with Api Keys

A race condition in an Echo Go service that uses API keys typically arises when key validation is not performed atomically with request processing. For example, consider an endpoint that reads a key from the request, looks up its permissions in a shared map or database, and then proceeds to authorize the request. If the key metadata can be changed concurrently (e.g., key rotation, scope updates, or revocation) without proper synchronization, a window exists where a request may be validated against stale data.

In Echo Go, this can occur when handlers access a key store that is modified by background processes or administrative endpoints. A classic pattern that is vulnerable looks like this:

var keys = map[string]KeyState{
    "abc123": {Scope: "read", Revoked: false},
}

func keyMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        key := c.Request().Header.Get("X-API-Key")
        state, ok := keys[key]
        if !ok || state.Revoked {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid key")
        }
        return next(c)
    }
}

If another handler updates keys concurrently—say, to revoke a key—Go’s map is not safe for concurrent read and write. This can lead to undefined behavior, including missed revocation enforcement. Even without crashes, a race can allow a request authenticated with a recently revoked key to pass validation because the read occurs before the write completes.

The risk is compounded when API keys are tied to authorization decisions such as scope checks or rate limiting. An attacker who can trigger key updates (e.g., via an administrative API) while issuing rapid requests may exploit the timing mismatch to perform actions beyond their intended permissions. This maps to BOLA/IDOR-style authorization issues and can violate the principle of least privilege encoded in the key’s intended scope.

middleBrick detects such patterns during its unauthenticated scan by analyzing how API endpoints handle key validation and concurrent access, flagging missing synchronization where applicable. Findings include severity, guidance to apply safe concurrency practices, and references to secure coding patterns that eliminate the window for inconsistent state.

To remediate race conditions in Echo Go when using API keys, ensure all access and mutation of key state are synchronized using appropriate concurrency controls. The standard approach in Go is to guard shared structures with a mutex or use channels to serialize access.

Below is a secure version of the earlier example, using a sync.RWMutex to protect reads and writes:

import "sync"

type KeyState struct {
    Scope  string
    Revoked bool
}

var (
    keys = map[string]KeyState{
        "abc123": {Scope: "read", Revoked: false},
    }
    keysMu sync.RWMutex
)

func keyMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        key := c.Request().Header.Get("X-API-Key")
        keysMu.RLock()
        state, ok := keys[key]
        keysMu.RUnlock()
        if !ok || state.Revoked {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid key")
        }
        // Optionally attach key metadata to context for downstream use
        c.Set("key_scope", state.Scope)
        return next(c)
    }
}

func rotateKey(newKey string, scope string) {
    keysMu.Lock()
    defer keysMu.Unlock()
    keys[newKey] = KeyState{Scope: scope, Revoked: false}
}