Api Rate Abuse in Strapi with Api Keys

Strapi is a headless CMS that exposes GraphQL and REST endpoints. When API keys are used without complementary rate controls, an attacker who obtains a single key can generate a high volume of requests. This is API rate abuse: authenticated but unbounded requests that exhaust server resources, degrade performance, or amplify the impact of other issues such as data exposure or unsafe consumption.

In Strapi, API keys are typically managed via plugins or custom policies that validate a key header or query parameter. If a key is issued broadly (for example, to frontend JavaScript or third party partners) and the endpoint lacks per-key rate limits, the key becomes an implicit authorization token that any holder can reuse aggressively. Unlike per-user limits, key-based limits apply to all users sharing that key, which can enable token sharing, replay, and credential leakage across clients. Attack patterns include credential stuffing where leaked keys are reused, or automated scraping that leverages the key to bypass IP-based restrictions.

Because Strapi’s GraphQL endpoint can resolve nested relations and perform mutations, unthrottled requests with a valid API key may trigger expensive operations or large data exports. This amplifies data exposure risks and can interact poorly with other checks such as Property Authorization if field-level controls are incomplete. For example, a query that traverses relationships and returns many records may be valid under the schema but abusive under high volume.

When you run a scan with middleBrick against a Strapi instance that uses API keys but lacks rate limiting, one of the 12 parallel checks—Rate Limiting—will flag the absence of per-key or per-client thresholds. The tool does not fix the issue; it reports the finding with severity, context, and remediation guidance. This helps teams understand that API keys alone are not sufficient to prevent abuse and that controls must be applied at the endpoint or gateway layer.

To remediate API rate abuse when using API keys in Strapi, apply rate limiting at the point where keys are validated, typically in a policy or a dedicated rate limiter service. Below are two approaches with syntactically correct code examples.

Approach 1: Policy-based rate limiting with a simple in-memory store

This example uses a policy to check a key identifier and enforce a request count per window. It is suitable for low-volume deployments or as a starting point before moving to Redis.

// api/strapi/config/policies/key-rate-limit.js
const rateLimits = new Map();

module.exports = async (ctx, next) => {
  const key = ctx.request.header['x-api-key'] || ctx.request.query.api_key;
  if (!key) {
    return ctx.unauthorized('API key required');
  }

  const now = Date.now();
  const windowMs = 60 * 1000; // 1 minute
  const maxRequests = 100;

  if (!rateLimits.has(key)) {
    rateLimits.set(key, { count: 1, startTime: now });
  } else {
    const record = rateLimits.get(key);
    if (now - record.startTime > windowMs) {
      record.count = 1;
      record.startTime = now;
    } else {
      record.count += 1;
    }
    if (record.count > maxRequests) {
      return ctx.status(429).send('Too Many Requests');
    }
  }

  await next();
};

Apply this policy to specific routes in config/policies.json, for example:

{
  "controllers": {
    "api::article.article": {
      "find": ["key-rate-limit"],
      "create": ["key-rate-limit"]
    }
  }
}

Approach 2: Using a Redis-backed rate limiter for distributed environments

This approach is more robust for clustered or horizontally scaled Strapi deployments. It uses the ioredis client and implements a sliding window with Lua scripting for accuracy.

// api/strapi/config/policies/redis-key-rate-limit.js
const Redis = require('ioredis');
const { promisify } = require('util');

const redis = new Redis({
  host: process.env.REDIS_HOST || '127.0.0.1',
  port: 6379,
});

const evalAsync = promisify(redis.eval).bind(redis);

const script = `
  local key = KEYS[1]
  local limit = tonumber(ARGV[1])
  local window = tonumber(ARGV[2])
  local now = redis.call('TIME')[1]
  local windowStart = now - window

  redis.call('ZREMRANGEBYSCORE', key, 0, windowStart)
  local count = redis.call('ZCARD', key)

  if tonumber(count) >= limit then
    return 0
  end

  redis.call('ZADD', key, now, now .. ':' .. math.random())
  redis.call('EXPIRE', key, window)
  return 1
`;

module.exports = async (ctx, next) => {
  const key = ctx.request.header['x-api-key'] || ctx.request.query.api_key;
  if (!key) {
    return ctx.unauthorized('API key required');
  }

  const allowed = await evalAsync(script, 1, `ratelimit:${key}`, 100, 60);
  if (allowed === 0) {
    return ctx.status(429).send('Too Many Requests');
  }

  await next();
};

Use the Redis version when running Strapi in production across multiple nodes to ensure consistent limits. You can integrate these policies into Strapi’s policy stack via config/policies.json and reference them in route configurations.

Complementary measures

Rotate API keys regularly and avoid embedding them in client-side code. Combine rate limiting with other checks such as Authentication and Input Validation. middleBrick’s continuous monitoring in the Pro plan can alert you when rate limit configurations drift or when new endpoints are introduced without appropriate controls.