Auth Bypass in Strapi with Bearer Tokens

An authentication bypass in Strapi involving Bearer tokens occurs when access controls are not enforced on API endpoints that should require valid authentication. Strapi, by default, protects the admin panel and can secure REST and GraphQL endpoints with JWTs or session cookies, but developers sometimes expose controller actions or custom routes without verifying the presence and validity of a Bearer token. When a route is configured to accept Bearer tokens but does not validate the token’s signature, expiration, or scope, an unauthenticated attacker can send requests with a missing, malformed, or forged Authorization header and still reach sensitive operations.

This misconfiguration is especially risky when custom controllers or plugin routes handle elevated actions such as user updates, content publication, or administrative queries. For example, a route mapped to PUT /users/:id might expect a Bearer token in the Authorization header, but if the underlying policy or middleware is omitted or incorrectly ordered, the request will proceed without verifying identity or permissions. Because Strapi’s ORM may directly map parameters to database records, an attacker can combine missing Bearer token validation with insecure direct object references to modify other users’ data.

In some setups, CORS misconfigurations can further weaken the intended protection. If preflight requests are too permissive or the backend incorrectly treats an Origin header as trustworthy, an attacker may forge requests from a malicious site that include an Authorization header with a guessed or leaked Bearer token. Even when tokens are issued after login, if token validation is skipped on certain endpoints, the system effectively allows authenticated-style operations without actual authentication, resulting in an auth bypass. The risk is compounded when tokens are long-lived or not rotated properly, increasing the window for abuse.

During a black-box scan, such vulnerabilities can be detected by sending requests to authenticated endpoints without a token, with an empty Authorization header, or with an invalid Bearer token, and observing whether the response reveals sensitive data or allows unauthorized actions. Because Strapi’s OpenAPI spec may document these endpoints as requiring security schemes, discrepancies between the spec and runtime behavior often highlight where authorization checks are missing. Attack patterns like IDOR frequently accompany auth bypass, enabling attackers to iterate over identifiers and access or modify resources they should not touch.

middleBrick detects these issues by running parallel security checks that include Authentication, Authorization, and BOLA/IDOR assessments, comparing the declared OpenAPI security requirements with actual runtime behavior. If endpoints accept Bearer tokens but lack proper validation or enforcement, findings are surfaced with severity, technical context, and remediation guidance. This helps teams align implementation with the intended security model described in the spec and avoid relying on implicit protections that can be bypassed.

To remediate Bearer token-related authentication bypass in Strapi, enforce consistent token validation across controllers, policies, and custom routes, and ensure that permissions are checked before data access. Below are concrete code examples that demonstrate secure handling of Authorization headers using Bearer tokens.

First, validate the token in a custom policy so that it applies to multiple routes. Create a policy file at src/policies/validate-bearer.js with the following content:

module.exports = async (ctx, next) => {
  const authHeader = ctx.request.header.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    ctx.throw(401, 'Unauthorized: Bearer token missing');
  }
  const token = authHeader.split(' ')[1];
  if (!token) {
    ctx.throw(401, 'Unauthorized: Malformed Authorization header');
  }
  try {
    // Replace verifyWithJWKSet or equivalent with your validation logic
    const payload = await verifyWithJWKSet(token, ctx.request.ip);
    ctx.state.user = payload;
    await next();
  } catch (err) {
    ctx.throw(401, 'Unauthorized: Invalid token');
  }
};

Then apply this policy to specific controllers or globally. For example, in config/policies.json:

{
  "controllers": {
    "users": {
      "find": ['validate-bearer'],
      "update": ['validate-bearer'],
      "delete": ['validate-bearer']
    },
    "articles": {
      "create": ['validate-bearer'],
      "updateStatus": ['validate-bearer']
    }
  }
}

For custom routes defined in a plugin’s routes.json, ensure the policy is referenced so requests are checked before reaching the controller:

{
  "routes": [
    {
      "method": "PUT",
      "path": "/users/:id/promote",
      "handler": "user.promote",
      "config": {
        "policies": ["validate-bearer"]
      }
    }
  ]
}

In the controller, avoid trusting parameters that identify resources. Instead, use the authenticated context to scope updates:

module.exports = {
  async promote(ctx) {
    const userId = ctx.params.id;
    const currentUser = ctx.state.user;
    if (!currentUser || currentUser.sub !== userId) {
      ctx.throw(403, 'Forbidden: insufficient permissions');
    }
    const updated = await strapi.entityService.update('api::user.user', userId, {
      data: { role: 'admin' }
    });
    ctx.body = updated;
  }
};

When using JSON Web Tokens, ensure token verification uses a reliable library and checks issuer, audience, expiration, and scope. Do not rely solely on the presence of a token; always validate it and bind operations to the subject and permissions encoded in the token. Regularly rotate signing keys and prefer short-lived tokens with refresh mechanisms to reduce the impact of a leaked Bearer token.