Credential Stuffing in Strapi with Api Keys

Credential stuffing is an automated attack where attackers use lists of previously leaked username and password pairs to gain unauthorized access. When API keys are used in Strapi as the sole authentication mechanism for public or weakly protected endpoints, the attack surface shifts from user credentials to long-lived tokens. If an API key is exposed—through source code repositories, logs, or insecure client-side code—it becomes a high-value credential that can be reused in bulk credential stuffing campaigns against the Strapi instance.

Strapi’s default behavior does not inherently rotate or revoke API keys automatically. Once an API key is compromised, it remains valid until manually revoked. Attackers who obtain a key can run automated scripts to access or modify content types, escalate privileges via role-based permissions, or dump datasets. This is especially risky when the key is scoped to administrative roles or includes broad permissions such as create, read, update, and delete. In a black-box scan, middleBrick checks for unauthenticated or over-privileged API key usage and flags findings that align with BOLA/IDOR and unsafe consumption patterns, helping to surface weak key governance before an attacker does.

Because Strapi APIs are often consumed by frontend JavaScript or mobile clients, keys embedded in client-side bundles are trivial to extract. These extracted keys can then be fed into tooling that performs distributed credential stuffing against login or token-introspection endpoints that rely on the same key-based identity. Unlike session cookies, API keys do not inherently carry short-lived session context, so the risk persists across time and requests. The combination of predictable key formats, weak rate limiting, and overly permissive roles enables scalable abuse. middleBrick’s checks for rate limiting, authentication, and property authorization help highlight whether Strapi deployments adequately throttle and scope key usage.

Attack patterns observed in the wild include rapid enumeration of user identifiers, token replay across subdomains, and exploitation of weakly defined scopes in Strapi policies. For example, a key that allows find and findOne on content types containing sensitive profile data can be abused to harvest emails, usernames, and other PII. If the key also has create or update rights, attackers can inject or modify records, leading to further compromise. By scanning with active probes, middleBrick detects missing or inconsistent authorization rules and surfaces findings mapped to OWASP API Top 10 and common compliance frameworks, emphasizing the need for scoped keys, short lifetimes, and strict policy definitions in Strapi.

Remediation focuses on reducing the blast radius of API keys, enforcing strict scoping, and integrating short-lived tokens where possible. Always avoid embedding long-lived API keys in client-side code. Instead, use environment variables and server-side proxies to mediate access. In Strapi, define multiple API keys with minimal scopes and rotate them regularly. Below are concrete code examples that demonstrate secure usage patterns.

Environment-based key configuration

Store API key values in environment variables and reference them via process.env. This prevents accidental commits of secrets and enables runtime injection by your hosting platform.

// In .env
API_KEY_CONTENT_MANAGER=sk_live_abc123rotateoften
API_KEY_PUBLIC_READONLY=sk_live_viewer456limited

Using scoped keys in Strapi policies

Define policies that validate the incoming key against an allowlist and enforce role-based scopes. This example shows a custom policy that checks an X-API-Key header and attaches a restricted context to the request.

// ./api/my-policy/policy.js
'use strict';

module.exports = async (ctx, next) => {
  const allowedKeys = {
    'sk_live_abc123rotateoften': { role: 'content-manager', scopes: ['find', 'findOne', 'create'] },
    'sk_live_viewer456limited': { role: 'public-reader', scopes: ['find'] },
  };

  const key = ctx.request.header['x-api-key'];
  if (!key || !allowedKeys[key]) {
    ctx.status = 401;
    ctx.body = { error: 'Invalid API key' };
    return;
  }

  ctx.state.user = { role: allowedKeys[key].role, scopes: allowedKeys[key].scopes };
  await next();
};

Enforcing key scope in controller logic

Within controllers, check the assigned scopes before performing actions. This prevents privilege escalation even if a key is leaked and ensures compliance with the principle of least privilege.

// ./api/my-content/controllers/my-content.js
'use strict';

module.exports = {
  async find(ctx) {
    const userScopes = ctx.state.user?.scopes || [];
    if (!userScopes.includes('find')) {
      ctx.status = 403;
      ctx.body = { error: 'Scope "find" required' };
      return;
    }

    const entities = await strapi.entityService.findMany('api::my-content.my-content', {
      filters: ctx.request.query.filters,
      pagination: ctx.request.query.pagination,
    });
    ctx.body = entities;
  },
};

Rate limiting and monitoring

Apply rate limits at the platform or proxy layer to reduce the effectiveness of credential stuffing. Complement this with logging of key usage and alerts on anomalous patterns. middleBrick’s checks for rate limiting and authentication support detecting configurations that may allow excessive requests with a single key.

Rotation and revocation workflow

Establish a process to rotate keys periodically and immediately revoke compromised keys. In Strapi, this typically involves generating new keys in the admin panel or via scripts that update environment variables and restart services as needed. Combine this with middleware that validates key validity against a centralized store for larger deployments.