Cache Poisoning in Loopback with Bearer Tokens

Cache poisoning in a Loopback API occurs when an attacker causes a cached response to be stored under a key that includes or is derived from a user-specific value such as an authorization token. When Bearer Tokens are used for authorization but are inadvertently reflected in cache keys or URLs, a cache may treat distinct token values as distinct cache entries. This can lead to one user’s cached response being served to another user, exposing data across accounts.

Consider an endpoint that proxies requests to an upstream service and uses a caching layer keyed by the full request URL. If the URL includes the Bearer Token as a query parameter (for example, /api/reports?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...), the cache may store a response keyed by that token. A subsequent request from a different user with a different token but the same resource path could mistakenly receive the cached response meant for the first user, bypassing intended access controls.

Even when tokens are sent in the Authorization header, misconfigured caches that normalize cache keys by stripping or transforming headers might incorrectly treat different token values as equivalent, or worse, include fragments of the header in cache keys. In Loopback, if custom caching logic or a reverse proxy uses header values to build cache keys without sanitization, an attacker who can influence the token format might force cache collisions. This can facilitate horizontal privilege escalation: one user reads another user’s data without needing to authenticate as them.

Loopback applications that integrate with external APIs or microservices and cache those responses must ensure that sensitive request attributes like Bearer Tokens are excluded from cache keys. The risk is compounded when responses contain sensitive data or when the upstream service relies on token scope to enforce authorization. Cache poisoning in this context does not alter server-side logic but corrupts the integrity of cached data, leading to information leakage and potential bypass of access controls.

Active LLM security probing is not designed to detect cache poisoning, but the scanner’s authentication and authorization checks can surface indications of sensitive data exposure through caches by observing inconsistent responses across authenticated contexts. Proper remediation requires architectural changes to ensure tokens never influence cache behavior.

To remediate cache poisoning risks related to Bearer Tokens in Loopback, ensure tokens are never used to derive cache keys and are stripped from any cache-normalization logic. Below are concrete patterns you can apply.

1. Avoid token-in-URL patterns

Never pass Bearer Tokens as query parameters. Instead, always use the Authorization header. If your client code is constructing URLs with tokens, refactor as follows.

// Unsafe: token in query string (do not use)
const url = `https://api.example.com/reports?access_token=${userToken}`;

// Safe: use Authorization header
const request = {
  url: 'https://api.example.com/reports',
  headers: {
    Authorization: `Bearer ${userToken}`
  }
};

2. Configure HTTP caching to ignore Authorization headers

If you use a reverse proxy or cache in front of Loopback, configure it to exclude the Authorization header from cache key computation. For example, in an Nginx layer, ensure proxy_cache_key does not include the Authorization header.

# Nginx configuration snippet
proxy_cache_key "$scheme$request_method$host$request_uri";
# Do NOT include $http_authorization

3. Sanitize cache keys in Loopback middleware

When using custom caching middleware in Loopback, explicitly exclude sensitive headers and request attributes from the cache key. The following Express-style middleware illustrates one approach.

app.use((req, res, next) => {
  // Create a cache-safe key that excludes Authorization and other sensitive headers
  const cacheKey = [
    req.method,
    req.path,
    JSON.stringify(req.query)
  ].join(':');
  req.cacheKey = cacheKey;
  next();
});

4. Use role- or user-scoped caches rather than token-derived keys

Instead of keying cache entries by token, scope caches by user ID or role, ensuring that tokens are never part of the cache identity. This pattern is especially useful when integrating with external services where responses vary by permissions but not by ephemeral tokens.

// Example: cache by userId instead of token
const getScopedCacheKey = (userId, path, query) => {
  return `user:${userId}:${path}:${JSON.stringify(query)}`;
};

// Use in a service method
async function getReport(userId, reportId) {
  const key = getScopedCacheKey(userId, '/reports', { id: reportId });
  // lookup/store using key
  return cache.get(key) || fetchReportFromUpstream(userId, reportId);
}

5. Validate token usage in Loopback models and datasources

Ensure that datasources or connectors do not inadvertently log or forward Authorization headers to caching layers. Review datasource configurations and remote HTTP hooks to confirm headers are handled securely.