Cache Poisoning in Echo Go with Bearer Tokens

Cache poisoning occurs when an attacker causes a cache to store malicious content that is then served to other users. In the Echo Go ecosystem, this risk can emerge when responses that include sensitive authorization metadata—specifically the presence and handling of Bearer Tokens—are cached based on insufficient or attacker-controlled inputs.

Bearer Tokens are typically passed via the Authorization header (Authorization: Bearer <token>). If an Echo Go application uses request attributes that are not strictly validated before being used to key cache entries, an attacker can manipulate those attributes to poison the cache. For example, a caching layer keyed by path and query parameters but ignoring or incorrectly normalizing the Authorization header may store a response that includes a token-specific representation for one user and then serve that cached response to another user, effectively leaking authorization context.

Consider an API endpoint that returns user profile information and uses a caching proxy or in-memory cache. If the cache key does not incorporate the Authorization header, two different users with different Bearer Tokens may receive the same cached response. User A’s token may grant access to admin data; if User B receives that cached response, they can see data they are not authorized to view. This is a form of broken access control and sensitive data exposure, and it maps to findings in the BOLA/IDOR and Data Exposure checks run by middleBrick.

Real-world attack patterns that mirror this issue include scenarios where an unauthenticated or low-privilege attacker manipulates a cache key to retrieve elevated-privilege responses. While this does not involve code execution, it can expose tokens, session identifiers, or other sensitive payloads that should not be shared across users. In the context of LLM/AI Security, if an LLM endpoint inadvertently caches or logs requests containing Authorization headers, output scanning becomes important to prevent token leakage in generated responses.

middleBrick detects these risks by analyzing the unauthenticated attack surface and checking whether responses that carry sensitive authorization metadata are properly isolated per-identity in caching scenarios. The scanner does not fix the cache logic but provides prioritized findings with remediation guidance, helping developers adjust cache keys, vary headers, and enforce proper authorization checks before returning cached data.

To mitigate cache poisoning related to Bearer Tokens in Echo Go, ensure that cache keys include a normalized representation of the Authorization header when user-specific data is served. Avoid caching responses that contain sensitive data in a shared cache unless you can guarantee isolation by token identity.

Example of an insecure pattern where the Authorization header is ignored for cache key derivation:

// Insecure: cache key ignores Authorization header
func getUserProfile(c echo.Context) error {
    userID := c.Param("id")
    cacheKey := fmt.Sprintf("profile:%s", userID)
    var profile Profile
    if found := cache.Get(cacheKey, &profile); found {
        return c.JSON(http.StatusOK, profile)
    }
    // fetch profile...
    cache.Set(cacheKey, profile, time.Minute*5)
    return c.JSON(http.StatusOK, profile)
}

An attacker can manipulate the id parameter or exploit shared cache entries to read another user’s profile if the Authorization header is not part of the cache key.

Secure remediation that incorporates the Bearer Token into the cache key:

// Secure: include Authorization header in cache key
func getUserProfile(c echo.Context) error {
    userID := c.Param("id")
    auth := c.Request().Header.Get("Authorization")
    // Normalize: "Bearer <token>" — include token or a token hash if appropriate
    cacheKey := fmt.Sprintf("profile:%s:%s", userID, auth)
    var profile Profile
    if found := cache.Get(cacheKey, &profile); found {
        return c.JSON(http.StatusOK, profile)
    }
    // fetch profile...
    cache.Set(cacheKey, profile, time.Minute*5)
    return c.JSON(http.StatusOK, profile)
}

Additional remediation practices:

• Do not cache responses that contain sensitive Authorization headers unless the cache is strictly user-isolated.
• Use the Vary header (e.g., Vary: Authorization) when caching at shared proxies to ensure different Authorization values are not served from the same cache entry.
• If you must cache authenticated responses, scope cache entries to the token or token hash and enforce strict access controls on cache eviction and inspection.
• Apply input validation and rate limiting to reduce the attack surface for parameter manipulation that could lead to cache poisoning.

middleBrick’s CLI can be used to verify that your endpoints do not inadvertently cache sensitive representations across users. Run middlebrick scan <url> from the terminal to get a JSON report highlighting findings related to Authorization handling and cache behavior. For CI/CD integration, the GitHub Action can fail builds if risk scores exceed your defined thresholds, and the Pro plan provides continuous monitoring to detect regressions in how Authorization is treated across scans.