Cache Poisoning in Loopback with Basic Auth

Cache poisoning in a Loopback API with Basic Authentication occurs when an attacker manipulates cached responses so that sensitive or user-specific data is served to unauthorized clients. This typically arises when a response that should be personalized (e.g., containing the authenticated user’s data or an admin flag) is cached by an intermediary based on request path alone, ignoring critical authentication or authorization headers.

Basic Authentication encodes credentials in the Authorization header as a Base64 string. If a caching layer uses only the request URL as the cache key and does not include the Authorization header (or the user identity it conveys), responses for one user may be reused for another. For example, an authenticated request from a standard user to /api/users/me might return a 200 with user data and be cached. A subsequent request from an attacker using the same URL but different credentials could receive the cached, legitimate user’s response, effectively leaking data across user boundaries.

In Loopback, this is especially relevant when REST or GraphQL connectors are configured to cache at the HTTP layer (e.g., via an API gateway or reverse proxy) without considering authorization. If the application uses role-based access control (RBAC) but the cache key omits the effective permissions derived from Basic Auth, an attacker might also receive responses intended for higher-privilege roles, leading to privilege escalation via cached data. The 12 parallel security checks in middleBrick would flag this as a BOLA/IDOR and Data Exposure risk, noting that unauthenticated or improperly scoped caching can inadvertently expose one user’s data to another.

Moreover, if the Loopback application reflects request headers or cookies in cache keys without sanitizing, an attacker can probe endpoints with crafted Basic Auth credentials to learn whether cached responses differ, confirming the presence of cache poisoning. middleBrick’s unauthenticated scan can detect inconsistent responses across requests to the same path with different Authorization headers, indicating that authorization context is not part of the cache key. Remediation guidance focuses on ensuring that any caching mechanism incorporates user identity or authorization scope into the cache key and that sensitive endpoints either disable caching or validate authorization on every request.

To mitigate cache poisoning in Loopback when using Basic Authentication, ensure that the cache key includes a representation of the authenticated user or their effective permissions, and avoid caching sensitive responses unless necessary. Below are concrete steps and code examples.

1. Include user identity in cache keys

When using a caching proxy or custom cache middleware, derive the cache key from the user identity extracted from the Basic Auth credentials, not just the URL.

// Example: Loopback middleware to add user ID to cache key for REST connector
const loopback = require('loopback');
const app = loopback();

app.use((req, res, next) => {
  const auth = req.headers.authorization || '';
  const match = auth.match(/^Basic\s+(\S+)$/);
  req.cacheKeySuffix = match ? Buffer.from(match[1], 'base64').toString('utf8').split(':')[0] : 'anon';
  next();
});

// Configure a cache middleware (example using memory-cache)
const cache = require('memory-cache');
app.use((req, res, next) => {
  const key = req.originalUrl + '|user:' + req.cacheKeySuffix;
  const cached = cache.get(key);
  if (cached) {
    res.send(cached);
  } else {
    res.sendResponse = res.send;
    res.send = (body) => {
      cache.put(key, body, 30000); // 30s cache
      res.sendResponse(body);
    };
  }
  next();
});

2. Do not cache sensitive endpoints

For endpoints that return user-specific or role-specific data, explicitly disable caching by setting headers that prevent intermediary caches from storing responses.

// Example: Disable caching for user-specific routes in Loopback
app.interceptor('responses', 'no-cache-sensitive', (req, res) => {
  const auth = req.headers.authorization || '';
  if (auth.startsWith('Basic ')) {
    res.set('Cache-Control', 'no-store, no-cache, must-revalidate, private');
    res.set('Pragma', 'no-cache');
    res.set('Expires', '0');
  }
  return res;
});

3. Validate authorization on every request

Even if caching is used, ensure that each request re-validates permissions. Do not rely on cached authorization decisions. In Loopback, use built-in ACLs or custom boot components to enforce role checks at runtime.

// Example: Strong ACL in common/models/user.json
{
  "name": "User",
  "acls": [
    {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "DENY",
      "property": "find"
    },
    {
      "principalType": "ROLE",
      "principalId": "$authenticated",
      "permission": "ALLOW",
      "property": "find",
      "accessScope": "$"
    },
    {
      "principalType": "ROLE",
      "principalId": "admin",
      "permission": "ALLOW",
      "property": "find",
      "accessScope": "$"
    }
  ]
}

// Example: Custom boot script to enforce runtime checks (boot/acl-enforcer.js)
module.exports = function(app) {
  const User = app.models.User;
  User.observe('access', (ctx, next) => {
    const { accessToken } = ctx;
    if (!accessToken) {
      const err = new Error('Unauthorized');
      err.statusCode = 401;
      return next(err);
    }
    // Additional checks can use Basic Auth-derived identity if tokens are not present
    next();
  });
}; 

4. Use environment-aware caching configuration

In production, prefer token-based authentication with clear scope, but if Basic Auth is required, ensure that any caching layer is configured to exclude sensitive routes from shared caches. Document and test that cache keys incorporate authorization context to prevent cross-user leakage.