Excessive Data Exposure in Adonisjs with Basic Auth

Excessive Data Exposure occurs when an API returns more information than necessary for a given operation. In AdonisJS applications that rely on HTTP Basic Authentication, this risk is amplified when endpoints return complete domain objects, internal identifiers, or sensitive fields that should remain restricted. Because Basic Auth transmits credentials in an easily decoded format, an attacker who intercepts or gains access to a valid credential pair can leverage overly verbose responses to map the data model, identify privileged accounts, or chain findings with other vulnerabilities such as BOLA/IDOR.

Consider an endpoint like GET /api/users/:id that uses Basic Auth for access control. If the handler returns the full user record—including password hashes, email addresses, roles, and internal metadata—an unauthenticated or low-privilege attacker can harvest data that would normally be protected by additional authorization layers. This exposure is especially problematic when combined with weak authorization checks, because the attacker can iterate over user IDs and collect a dataset far beyond what the business logic intends to expose.

AdonisJS often uses Lucid models directly in route handlers, and it is common to serialize models with model.serialize() or return them from controller methods. Without explicit filtering, this may expose fields such as reset_token, two_factor_secret, or audit columns like created_at and updated_at that reveal operational patterns. In a black-box scan, middleBrick tests these surfaces by probing unauthenticated endpoints and analyzing the response for sensitive data categories such as PII, API keys, and credential hints. When responses include full objects, the scan flags this as Data Exposure with guidance to reduce the payload to only required fields.

Another vector involves nested relationships. For example, returning a user object that includes related tokens or profiles can unintentionally expose linked records. If those nested resources are also protected only by Basic Auth and lack granular checks, an attacker can traverse associations to infer internal architecture or harvest tokens for downstream abuse. middleBrick’s LLM/AI Security checks complement this by detecting whether responses contain patterns that resemble system prompts or structured secrets, but the root cause remains the unchecked breadth of serialized data.

Real-world mappings include references to OWASP API Top 10 API5:2023 (Excessive Data Exposure) and can intersect with SSRF when external identifiers are echoed back in error messages or debug payloads. The framework itself does not introduce the flaw; rather, it is the developer’s choice to expose complete models without projection or filtering. By treating Basic Auth as the sole protective mechanism while returning rich domain objects, the application effectively widens the attack surface that an automated scanner like middleBrick evaluates during its 5–15 second test window.

To validate the issue in practice, a scan submits targeted requests and inspects response payloads for sensitive fields. Findings include severity ratings and remediation guidance that emphasize schema-level minimization, use of serialization scopes, and strict field selection. The goal is not to change the authentication method, but to ensure that even when credentials are validated, the data returned adheres to the principle of least disclosure.

Remediation focuses on reducing the data footprint returned to the client while preserving the use of Basic Auth for credential validation. The key is to avoid returning Lucid models directly and instead construct lean response objects that contain only the fields required by the consumer. This can be achieved through explicit serialization, projection in queries, or dedicated resource transformers.

One approach is to use query selects to limit database columns at the ORM level. For example:

const User = use('App/Models/User')

async show ({ request, response }) {
  const user = await User.query()
    .select('id', 'username', 'email')
    .where('id', request.param('id'))
    .first()

  return response.status(200).send(user)
}

This ensures that fields such as password_hash or two_factor_secret are never part of the response, even if the model contains them. It also reduces database load and network exposure.

Another robust method is to define a serializer or use a resource class. AdonisJS supports transformer patterns where you map only safe fields:

const UserTransformer = {
  transform (user) {
    return {
      id: user.id,
      username: user.username,
      email: user.email,
      role: user.role
    }
  }
}

// In a controller
async show ({ request, response }) {
  const user = await User.findOrFail(request.param('id'))
  const payload = UserTransformer.transform(user)
  return response.status(200).send(payload)
}

When using HTTP Basic Auth, ensure that the authentication layer validates credentials without leaking details. A typical middleware or hook might look like:

const BasicAuth = use('BasicAuth')

async handle ({ request, response, next }) {
  const authHeader = request.header('authorization')
  if (!authHeader || !authHeader.startsWith('Basic ')) {
    return response.status(401).send({ error: 'Unauthorized' })
  }

  const base64 = authHeader.split(' ')[1]
  const [username, password] = Buffer.from(base64, 'base64').toString().split(':')

  const user = await User.findBy('username', username)
  if (!user || user.password_hash !== hashPassword(password)) {
    return response.status(401).send({ error: 'Invalid credentials' })
  }

  // Attach minimal user context for downstream checks
  request.authUser = { id: user.id, role: user.role }
  await next()
}

Note that this example handles credential validation manually to avoid returning the full model. The authorization check for the specific resource should still occur in the route or via a policy to prevent BOLA/IDOR, but at least the response body is now constrained. middleBrick’s checks for Authorization and Property Authorization validate that such controls are present and that responses do not expose excessive fields.

Finally, combine these practices with environment-aware configurations. In development, verbose errors can be helpful, but in production, ensure that stack traces and model internals are never surfaced. middleBrick’s Data Exposure and Encryption checks will highlight endpoints where sensitive data appears in unauthenticated responses, guiding you toward minimal, secure payloads while continuing to use Basic Auth for initial credential verification.