Bola Idor in Strapi

BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object References) vulnerabilities in Strapi often arise from the framework's flexible content management system and dynamic routing. Strapi's admin panel and API endpoints expose object identifiers that, when not properly validated, allow attackers to access or modify data belonging to other users.

The most common Strapi-specific BOLA pattern occurs in dynamic routes where the object ID is passed as a parameter. For example, a typical Strapi REST API endpoint like /api/posts/:id might look secure at first glance, but if the backend doesn't verify that the authenticated user has permission to access the specific post ID, an attacker can simply increment the ID value to access other users' content.

// Vulnerable Strapi controller code
async find(ctx) {
  const { id } = ctx.params;
  return await strapi.query('post').findOne({ id });
}

This controller blindly trusts the ID parameter without checking user ownership. An authenticated user could access /api/posts/1, /api/posts/2, etc., regardless of whether they created those posts.

Strapi's plugin system introduces additional BOLA surfaces. The users-permissions plugin's dynamic role and permission system can create subtle authorization gaps. For instance, if a content manager role is granted find permission on a model but not findOne, an attacker might exploit this inconsistency to access specific records.

Another Strapi-specific pattern involves the populate feature in queries. When models have relationships, improper population can expose related objects without proper authorization checks:

// Vulnerable population exposing related data
async find(ctx) {
  return await strapi.query('author')
    .find(ctx.query, ['books', 'articles']);
}

If the user querying isn't the owner of the related books or articles, this could expose data they shouldn't access. The population happens at the database level without Strapi's authorization layer being applied to the related entities.

Detecting BOLA in Strapi requires understanding both the framework's architecture and common attack patterns. Manual testing involves systematically testing API endpoints with modified object IDs while authenticated as different users.

For Strapi specifically, start by examining your config/routes.json and api/{model}/controllers/{model}.js files. Look for endpoints that accept ID parameters without ownership verification. Pay special attention to:

• Dynamic routes in config/routes.json that use :id parameters
• Controller methods that call findOne, update, or delete without authorization checks
• Service methods that perform database queries with user-supplied IDs

middleBrick's scanner specifically detects Strapi BOLA vulnerabilities by analyzing the runtime API behavior. It tests endpoints by making authenticated requests with modified IDs and checking if the system returns data from other users' accounts. The scanner's black-box approach is particularly effective for Strapi because it doesn't require source code access—it interacts with the running API just like an attacker would.

middleBrick's Strapi-specific checks include:

• Authentication bypass attempts on ID parameters
• Cross-account data access in REST endpoints
• GraphQL query analysis for unauthorized field access
• Plugin-specific authorization gaps in users-permissions

The scanner runs 12 parallel security checks, including BOLA/IDOR testing, and provides a security score with severity levels and remediation guidance. For Strapi deployments, it specifically flags endpoints that expose object IDs without proper authorization validation.

Another detection method is reviewing Strapi's lifecycle hooks. Strapi allows beforeFindOne, beforeUpdate, and beforeDelete hooks where authorization should be implemented. Missing or improperly implemented hooks are a red flag for BOLA vulnerabilities.

Remediating BOLA in Strapi involves implementing proper authorization checks at the framework level. Strapi provides several native mechanisms to prevent unauthorized object access.

The most effective approach is using Strapi's built-in strapi.api.{model}.services.{model}.fetch method with ownership verification. Here's a Strapi-specific remediation pattern:

// Secure Strapi controller with ownership check
async findOne(ctx) {
  const { id } = ctx.params;
  const entity = await strapi.query('post').findOne({ id });
  
  // Verify ownership
  if (entity.author !== ctx.state.user.id) {
    return ctx.unauthorized('You do not have permission to access this resource');
  }
  
  return entity;
}

For more complex authorization scenarios, Strapi's users-permissions plugin allows defining granular permissions. You can configure role-based access control in the admin panel or programmatically:

// Programmatic permission check in Strapi
async find(ctx) {
  const { id } = ctx.params;
  const entity = await strapi.query('post').findOne({ id });
  
  // Use Strapi's permission service
  const hasPermission = await strapi.plugins['users-permissions']
    .services.permissions.can(ctx.state.user, 'posts', 'find', entity);
  
  if (!hasPermission) {
    return ctx.unauthorized('Access denied');
  }
  
  return entity;
}

Strapi's lifecycle hooks provide another remediation layer. Implement beforeFindOne to enforce authorization before database queries execute:

// Lifecycle hook for BOLA prevention
module.exports = {
  lifecycles: {
    async beforeFindOne(data) {
      const entity = await strapi.query('post').findOne({ id: data.id });
        throw new Error('Unauthorized access');
      }
    }
  }
}

For Strapi's GraphQL API, implement authorization directives or use Strapi's built-in @auth directive to protect queries:

# Strapi GraphQL schema with authorization
type Post {
  id: ID!
  title: String!
  author: User!
}

type Query {
  post(id: ID!): Post @auth(requires: [isAuthenticated])
}

middleBrick's remediation guidance for Strapi includes specific code snippets for each vulnerability type, mapping findings to Strapi's native APIs and best practices. The scanner's reports prioritize findings by severity and provide exact code locations where BOLA vulnerabilities exist.