Cache Poisoning in Strapi with Bearer Tokens

Cache poisoning occurs when an attacker tricks a caching layer into storing a malicious response for subsequent users. In Strapi, this can arise when authenticated requests that include Bearer Tokens are inadvertently cached based only on parts of the URL (e.g., path or query parameters) and not on the Authorization header. If a caching proxy or CDN caches responses per endpoint rather than per user, a token-bearing user’s private or role-specific data might be served to another user who happens to hit the same cache key.

Strapi can expose this risk when APIs rely on query parameters for caching while also using Bearer Tokens for authorization. For example, an endpoint like /api/articles might use the Authorization: Bearer <token> header to determine which records a user can see, but if the cache key ignores the Authorization header, one user’s cached, filtered list can be returned to another user. This can lead to horizontal privilege escalation where one user sees another user’s data, or vertical escalation if administrative content is cached and served to lower-privilege users.

During a scan, middleBrick tests unauthenticated attack surfaces and can surface findings when responses vary by Authorization yet cache keys do not consider it. Attack patterns such as BOLA/IDOR and BFLA/Privilege Escalation map to this risk when tokens are not part of cache derivation. Even without credentials, scanners can detect inconsistencies in responses that suggest improper cache segregation, which is an indicator that authenticated caching behavior should be reviewed.

Common root causes include misconfigured CDN rules that exclude the Authorization header from cache keys, application-level caching that uses only request path and query params, and default HTTP caches that treat Authorization as opaque but still allow caching of authenticated responses when vary headers are missing or incorrect. Without a proper Vary: Authorization header, shared caches may serve a cached response to different authenticated users, effectively leaking data across users.

To assess this, middleBrick runs parallel checks including Authentication, BOLA/IDOR, BFLA/Privilege Escalation, and Property Authorization, alongside Input Validation and Rate Limiting, to identify whether responses differ by token but lack appropriate cache controls. Findings include severity, remediation guidance, and mappings to frameworks like OWASP API Top 10 and PCI-DSS, helping teams understand the impact and how to address it without assuming automatic fixes.

Remediation focuses on ensuring cache keys incorporate the Authorization header or disabling caching for authenticated responses. Strapi Enterprise users can leverage response middleware to set appropriate cache headers, while self-hosted setups can configure caching behavior in the proxy or application layer.

Example: Configure Strapi to add a Vary header based on Authorization for sensitive endpoints. In a custom middleware, you can set headers before the response is sent:

// src/middlewares/auth-cache/index.js
module.exports = (config, { strapi }) => {
  return async (ctx, next) => {
    await next();
    const auth = ctx.request.header['authorization'];
    if (auth && auth.startsWith('Bearer ')) {
      ctx.response.vary('Authorization');
      // Ensure caches do not retain authenticated responses across users
      ctx.response.set('Cache-Control', 'no-store');
    }
  };
};

Example: Express-style proxy configuration that ensures the Authorization header is part of the cache key when using a reverse proxy. This is not Strapi code but a common deployment pattern that complements Strapi’s behavior:

# Nginx snippet to include Authorization in cache key
location /api/ {
  proxy_cache_key "$request_method|$host|$request_uri|$http_authorization";
  proxy_pass http://strapi_backend;
  proxy_hide_header Set-Cookie;
  add_header X-Content-Type-Options nosniff;
}

Example: Strapi controller that avoids caching authenticated responses by setting headers explicitly:

// src/api/article/controllers/article.js
'use strict';
module.exports = {
  async find(ctx) {
    const auth = ctx.request.header['authorization'];
    if (auth && auth.startsWith('Bearer ')) {
      ctx.response.vary('Authorization');
      ctx.response.set('Cache-Control', 'private, no-store, no-cache');
    }
    // Proceed with service logic
    return strapi.entityService.findMany('api::article.article', {
      filters: ctx.query,
    });
  },
};

In the middleBrick CLI, you can run middlebrick scan https://your-strapi.example.com to detect inconsistencies in vary headers and cache behavior when Bearer Tokens are present. The dashboard and CLI outputs highlight findings tied to authentication and privilege escalation, enabling teams to prioritize fixes. The Pro plan’s continuous monitoring can track these headers over time, and the GitHub Action can fail builds if risk thresholds are exceeded, supporting secure deployment gates.

When using the MCP Server in AI coding assistants, you can scan APIs directly from your IDE to validate that cache-related headers are present and correct during development, catching misconfigurations early before they reach production.