Auth Bypass in Strapi with Api Keys

Strapi supports API key authentication as a mechanism to allow access to endpoints without traditional session-based cookies. When API keys are used, they are typically passed via an HTTP header such as Authorization: Bearer <key> or a custom header like x-api-key. Auth Bypass occurs when an API key intended for a limited, scoped service is accepted by administrative or sensitive endpoints that should require elevated privileges or a user context.

In Strapi, if an API key has broad or misconfigured scopes and the application does not enforce strict ownership checks on top of key validation, an unauthenticated attacker who obtains or guesses a valid key may be able to access or modify data they should not reach. For example, if Strapi routes key-validated requests through a generic policy that skips user session checks but does not enforce per-model or per-action authorization, an attacker can perform BOLA/IDOR-like actions by leveraging the key to enumerate or alter resources.

Another common pattern is when API keys are accepted on endpoints that also expose GraphQL or REST routes without ensuring that each sensitive operation verifies both the key and the data ownership. This can lead to privilege escalation where a key with lower-privilege intent is used to invoke higher-privilege operations. Input validation failures around the key or associated parameters can further amplify the risk by allowing malformed or unexpected values to bypass intended restrictions.

Because middleBrick scans the unauthenticated attack surface and runs checks such as Authentication, BOLA/IDOR, and Property Authorization in parallel, it can detect whether an API key present in requests is accepted on administrative routes, whether responses expose data leakage tied to key usage, and whether the API key mechanism lacks binding to specific user permissions or scopes. These checks are especially important when OpenAPI specs define security schemes for API keys but the runtime behavior does not consistently enforce them across all paths and methods.

Remediation focuses on ensuring API keys are only accepted where intended and that each request is validated for scope and ownership. In Strapi, you can define granular policies and use the context object to enforce that an API key maps to a specific action or tenant.

Below is a syntactically correct example of a Strapi policy that validates an API key against a set of allowed keys stored in environment variables and ensures the key is only usable for a specific service scope:

// src/policies/validate-api-key.js
'use strict';

const allowedKeys = new Set([
  process.env.API_KEY_READONLY,
  process.env.API_KEY_CONTENT_SERVICE,
]);

module.exports = async (ctx, next) => {
  const providedKey = ctx.request.header['x-api-key'] || ctx.request.header['authorization']?.replace('Bearer ', '');

  if (!providedKey || !allowedKeys.has(providedKey)) {
    ctx.throw(401, 'Invalid or missing API key');
  }

  // Optionally bind key to scope in context for downstream policies/controllers
  ctx.state.apiKeyScope = providedKey === process.env.API_KEY_CONTENT_SERVICE ? 'content' : 'readonly';
  await next();
};

In your Strapi route configuration (src/api/routes/content/routes.json), attach this policy to endpoints that should require a valid key and ensure sensitive routes are not also open to unauthenticated access:

{
  "routes": [
    {
      "method": "GET",
      "path": "/articles",
      "handler": "article.find",
      "config": {
        "policies": ["validate-api-key"]
      }
    },
    {
      "method": "POST",
      "path": "/articles",
      "handler": "article.create",
      "config": {
        "policies": ["validate-api-key", "ownership-check"]
      }
    }
  ]
}

Additionally, ensure that the API key is not accepted on admin routes unless explicitly required, and that each key is associated with a specific permission set within Strapi’s Roles & Permissions panel. Use the ctx.state populated by the policy to enforce model-level ownership in controllers, preventing BOLA where a key might otherwise allow broad read/write access.