Information Disclosure in Adonisjs with Basic Auth
Information Disclosure in Adonisjs with Basic Auth — how this specific combination creates or exposes the vulnerability
When AdonisJS applications use HTTP Basic Authentication without additional protections, they can inadvertently contribute to information disclosure in several concrete ways. Basic Auth sends credentials in an Authorization header encoded with Base64, which is easily reversible and does not provide confidentiality in transit. If the application does not enforce HTTPS consistently, an attacker on the network can capture the header and decode credentials, leading to unauthorized access and subsequent data exposure.
Even when HTTPS is used, misconfiguration can cause information leakage. For example, AdonisJS may include detailed error messages in responses when authentication fails. These messages can reveal whether a username exists, whether credentials were malformed, or which authentication driver is in use. Attackers can use this feedback to enumerate valid users, a technique often seen in tandem with BOLA/IDOR scenarios where knowing a valid identifier is half the battle. Such user enumeration is a classic information disclosure vector tied to authentication mechanisms.
Another specific risk arises when route definitions or controller logic expose sensitive data in logs, debug pages, or response payloads. AdonisJS applications that include verbose stack traces or debug information in development mode can leak paths, configuration details, or internal method names when authentication is partially misapplied. In API contexts, if an endpoint returning sensitive resources does not properly scope authorization to the authenticated identity, an attacker may leverage a broken access control to access data that should be restricted. This is directly relevant to the BOLA/IDOR category, where insecure direct object references allow one user to view or modify another’s resources.
The interplay with OpenAPI/Swagger spec analysis further highlights how documentation can unintentionally disclose implementation details. If your spec defines authentication via Basic Auth but does not clearly indicate which endpoints require it, a scanner can correlate documented routes with runtime behavior to identify inconsistencies. Missing security schemes on sensitive operations, or incorrect security requirement arrays, can cause clients and developers to assume protection that does not exist, inadvertently guiding attackers toward weakly protected endpoints.
Additionally, when Basic Auth credentials are reused across services or stored insecurely in client-side code or environment configurations, the attack surface expands. An exposed .env file or a hardcoded credential in a repository can lead to credential leakage, which in turn enables attackers to probe other APIs using the same credentials. middleBrick scans detect such misconfigurations by testing unauthenticated attack surfaces and identifying endpoints that either incorrectly allow access or reveal too much in error and response headers, providing findings mapped to frameworks like OWASP API Top 10 and PCI-DSS to guide remediation.
Basic Auth-Specific Remediation in Adonisjs — concrete code fixes
To mitigate information disclosure risks when using Basic Auth in AdonisJS, apply explicit transport security, strict error handling, and precise route protection. Always enforce HTTPS via middleware to prevent credential interception. Configure AdonisJS to disable detailed stack traces in production and ensure error responses do not reveal enumeration hints.
Use AdonisJS authentication providers with clear role and scope definitions, and validate authorization at the resource level to prevent accidental data exposure. The following code examples demonstrate secure implementation patterns.
Enforce HTTPS and secure headers
// start/kernel.ts
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
export default class AppMiddleware {
public async handle(ctx: HttpContextContract, next: () => Promise) {
if (process.env.NODE_ENV === 'production' && !ctx.request.secure) {
ctx.response.status(403).send({ error: 'HTTPS required' })
return
}
ctx.response.addHeader('strict-transport-security', 'max-age=63072000; includeSubDomains')
await next()
}
}
Configure Authentication with clear provider mapping
// config/auth.ts
import { AuthConfig } from '@ioc:Adonis/Addons/Auth'
const authConfig: AuthConfig = {
default: 'basicAuthDriver',
guards: {
basicAuthDriver: {
driver: 'basic',
provider: 'users',
},
},
providers: {
users: {
driver: 'lucid',
model: () => import('#models/user'),
},
},
}
export default authConfig
Implement a custom Basic Auth handler with safe error responses
// start/hooks.ts
import { BaseAuthProvider } from '@ioc:Adonis/Addons/Auth'
import User from '#models/user'
export class BasicAuthProvider extends BaseAuthProvider {
public async authenticate() {
const username = this.ctx.request.header('authorization')?.split(' ')[1]
const password = this.ctx.request.header('authorization')?.split(' ')[2]
if (!username || !password) {
this.ctx.response.status(400).send({ error: 'Invalid authorization header format' })
return null
}
const user = await User.query()
.where('username', username)
.preload('roles')
.first()
if (!user || !(await user.verifyPassword(password))) {
// Generic message to avoid user enumeration
this.ctx.response.status(401).send({ error: 'Invalid credentials' })
return null
}
return user
}
}
Protect routes and scope data access
// routes/api.ts
import Route from '@ioc:Adonis/Core/Route'
import User from 'App/Models/User'
Route.get('/profile', async ({ auth, response }) => {
const user = await User.find(auth.user!.id)
if (!user) {
return response.status(404).send({ error: 'Not found' })
}
return user.only(['id', 'username', 'email'])
}).middleware(['auth:basicAuthDriver'])
Disable verbose errors in production
// start/app.ts
import { Application } from '@ioc:Adonis/Core/Application'
if (Application.env === 'production') {
Application.debug = false
Application.showErrors = false
}
By combining transport security, controlled error messaging, and explicit authorization checks, you reduce the risk that Basic Auth implementations inadvertently disclose sensitive information through logs, errors, or inconsistent protection.