Brute Force in Adonisjs

Brute force attacks target authentication endpoints to guess credentials at scale. In Adonisjs, this typically occurs when an API route lacks rate limiting or throttling. Adonisjs uses controllers with methods that handle POST requests to /login or similar endpoints. A typical controller might look like this:

import Hash from 'hash/crypto'

class AuthController {
  async login ({ request, response }) {
    const { email, password } = request.all()
    const user = await Database.from('users').where('email', email).first()
    
    if (!user || !Hash.verify(password, user.password)) {
      return response.status(401).json({ message: 'Invalid credentials' })
    }
    
    return response.json({ token: await this.generateToken(user) })
  }
}

This code performs no rate limiting. An attacker can script thousands of requests with different passwords, cycling through common wordlists. Because each request hits the database and runs the full verification logic, the system is vulnerable to enumeration attacks. If the response distinguishes between 'invalid email' and 'invalid password', attackers can confirm valid usernames. Adonisjs does not enforce rate limiting by default, making it susceptible to credential stuffing if deployed without additional safeguards.

Another vector involves token-based endpoints. When using JWT or session-based authentication, an attacker may repeatedly POST to /auth/refresh or /auth/validate with stolen tokens. Without exponential backoff or lockout mechanisms, these endpoints can be brute-forced. Adonisjs applications often expose such endpoints unprotected, especially in development or staging environments. The framework's modularity means developers frequently implement custom logic for token validation without inheriting security defaults, increasing exposure.

middleBrick detects brute force risks by analyzing API endpoints for high cardinality request patterns and lack of throttling signals. When scanning an Adonisjs endpoint like /api/auth/login, middleBrick sends multiple requests with varying payloads and observes response consistency. If responses differ between invalid email and invalid password, it flags potential enumeration. The scanner also checks for the absence of RateLimit middleware or custom throttling logic in route definitions.

For example, middleBrick identifies missing rate limiting by inspecting route configurations in start/routes.js. If the route lacks a use([ throttle() ]) directive or a custom middleware that limits requests per IP, middleBrick marks it as high risk. It also correlates with OpenAPI specs: if the /login endpoint has no x-rate-limit extension or retry-after header guidance, it triggers a Finding with severity 'high' and remediation guidance linking to Adonisjs documentation on throttling.

Additionally, middleBrick examines authentication flows for session fixation or token reuse. In Adonisjs, if the login method sets a session cookie without regenerating session IDs, it may allow session replay. middleBrick detects this by analyzing response headers and payload patterns. These checks are part of its Authentication category scan, which includes 12 parallel tests, ensuring no false negatives due to misconfigured middleware.

To mitigate brute force in Adonisjs, implement rate limiting using built-in middleware or third-party packages. Add the throttle middleware to sensitive routes. For example:

// start/kernel.js
const AuthMiddleware = require('App/Middleware/Auth')

module.exports = {
  middleware: ['throttle'],
  // Apply to specific routes
  routes: {
    'POST /login': 'AuthController.login',
    'POST /refresh': 'AuthController.refresh'
  }
}

Then, configure throttling rules in config/throttle.js:

module.exports = {
  maxAttempts: 5,
  windowTime: 900, // 15 minutes
  minInterval: 2000 // 2 seconds between attempts
}

This limits each IP to 5 login attempts every 15 minutes. For stricter control, use packages like adonisjs-lucid with custom logic to lock accounts after repeated failures. Another approach is to obscure error messages: always return Invalid credentials regardless of whether the email or password is wrong. This prevents user enumeration. Modify the login response to a generic message:

return response.status(401).json({ message: 'Invalid credentials' })

Finally, enable HTTPS and enforce strong password policies. Use Adonisjs's validator module to enforce minimum password length and complexity. middleBrick validates these configurations during scans and will downgrade the risk score if throttling is detected and error messages are standardized. Remediation is not automatic — middleBrick only reports findings and provides links to Adonisjs security guides.