Broken Access Control in Adonisjs with Basic Auth

Broken Access Control occurs when authorization checks are missing or incorrectly applied, allowing a subject to access or modify resources they should not. In AdonisJS, combining Basic Auth with inadequate route or policy enforcement creates a classic BOLA/IDOR and BFLA pattern. Even when Basic Auth is used to validate identity, failing to scope data access to the authenticated user means any authenticated account can traverse IDs or escalate privileges.

Basic Auth in AdonisJS is typically implemented via an authentication scheme that sets the current user from a username and password. If routes rely only on this authentication step without additional ownership or role checks, the API exposes endpoints that should be user-specific. For example, an endpoint like GET /users/:id that loads a user record by ID without verifying that the authenticated user’s ID matches :id allows horizontal privilege escalation across user accounts. Similarly, endpoints performing actions such as updating or deleting resources without validating that the resource belongs to the authenticated user enable vertical privilege escalation (BFLA), where a user without admin rights might perform admin actions if they guess or iterate IDs.

AdonisJS does not automatically enforce ownership on route parameters. Without explicit checks in route handlers or within policies, the framework will process requests based solely on the controller logic you provide. If the controller loads a model by ID and applies no guard to ensure the model’s user_id matches the authenticated user’s ID, the unauthenticated attack surface includes authenticated users accessing each other’s data. This is especially risky with Basic Auth because credentials are sent on every request; if an attacker compromises a low-privilege account, they can enumerate IDs and directly interact with other users’ data.

Real-world attack patterns mirror findings from OWASP API Top 10 A01:2023 broken access control and common IDOR scenarios. Consider an endpoint that updates a user’s profile:

// routes.ts
Route.put('/profile/:id', 'ProfileController.update')

If the controller does not assert that the authenticated user owns the :id, an authenticated user can change any profile by iterating IDs. This maps to CVE-adjacent patterns where missing ownership checks lead to unauthorized data exposure or modification. Similarly, inventory or admin endpoints that do not check roles or scopes enable BFLA when a non-admin user discovers they can perform admin operations by altering requests. middleBrick scans detect these authorization gaps by correlating OpenAPI/Swagger definitions with runtime behavior, highlighting endpoints that authenticate but do not properly authorize specific actions or data.

Remediation centers on ensuring that every data access and action is scoped to the authenticated subject and validated through explicit checks. Do not rely on authentication alone; enforce ownership and role-based checks in route handlers or policies. When using Basic Auth, always retrieve the authenticated user from the auth context and compare it against resource ownership before proceeding.

Example: secure route definition and handler that enforces ownership:

// routes.ts
Route.get('/users/:id', 'UsersController.show').middleware(['auth:basic'])

// app/Controllers/Http/UsersController.ts
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import User from 'App/Models/User'

export default class UsersController {
  public async show({ auth, params }: HttpContextContract) {
    const user = await User.findOrFail(params.id)
    // Ensure the authenticated user is accessing their own record
    if (user.id !== auth.user!.id) {
      throw new Error('Unauthorized: you can only access your own profile')
    }
    return user
  }
}

For actions that modify resources, use policies to centralize authorization logic:

// policies/UserPolicy.ts
import { BasePolicy } from '@ioc:Adonis/Addons/AdonisAcl'
import User from 'App/Models/User'

export default class UserPolicy extends BasePolicy {
  public async view(owner: User, viewerId: number) {
    return owner.id === viewerId
  }

  public async update(owner: User, viewerId: number) {
    return owner.id === viewerId
  }
}

// controllers/UsersController.ts
import User from 'App/Models/User'
import UserPolicy from 'Policies/UserPolicy'

export default class UsersController {
  public async update({ auth, params, request }: HttpContextContract) {
    const user = await User.findOrFail(params.id)
    // Policy enforces ownership
    await auth.authorize('update', user)
    user.merge(request.only(['name', 'email']))
    await user.save()
    return user
  }
}

When exposing list or search endpoints, avoid exposing other users’ data by scoping queries to the authenticated subject:

// controllers/UsersController.ts
public async index({ auth }: HttpContextContract) {
  // Only return the authenticated user’s record, not a list of users
  return User.query().where('id', auth.user!.id)
}

For endpoints that must act on other resources (e.g., admin operations), enforce role or scope checks rather than trusting sequential IDs:

// controllers/AdminController.ts
public async manageUsers({ auth }: HttpContextContract) {
  if (auth.user?.role !== 'admin') {
    throw new Error('Forbidden: admin access required')
  }
  // Safe to proceed with admin-specific logic
  return User.all()
}

middleBrick’s checks align with these practices by mapping findings to frameworks such as OWASP API Top 10 and providing prioritized remediation guidance. If you use the CLI (middlebrick scan <url>) or add the GitHub Action to your CI/CD pipeline, you can fail builds when authorization gaps are detected before deployment. The dashboard and Pro plan continuous monitoring help track improvements over time, while the MCP Server lets you run scans directly from AI coding assistants to catch issues early in development.