Password Spraying in Adonisjs with Jwt Tokens

Password spraying is an authentication attack where an adversary uses a small list of commonly used passwords against many accounts. When the backend is built with AdonisJS and JWT tokens are used for stateless session handling, the interaction between the framework’s authentication flow and JWT issuance can unintentionally aid an attacker.

In AdonisJS, the typical login flow resolves credentials, validates them via the auth provider, and then issues a JWT using packages such as jwt or lucide-jwt. If the endpoint does not enforce rate limits per identity and uniformly returns the same generic error for invalid credentials, it becomes easier for an attacker to enumerate valid usernames or emails without triggering account lockouts. Once a valid account is discovered, the attacker can obtain a signed JWT for that account, which the API will accept on subsequent requests as proof of authentication.

JWT tokens themselves do not prevent password spraying; they simply standardize the payload (claims) and are verified using a secret or public key. If an API relies only on JWT for authentication and lacks additional protections, a token issued after a successful spray login can be replayed until expiration. Moreover, if tokens contain excessive claims or are not bound to a session revocation mechanism, the blast radius of a leaked token increases. The scanner checks for weak or missing rate limiting across authentication endpoints and flags cases where token issuance does not correlate with additional signals such as MFA or suspicious context.

From a framework perspective, misconfigured guards or an incomplete auth.js configuration can expose endpoints to unauthenticated probing. For example, if the jwt driver is used without requiring fresh credentials on each request or without short token lifetimes, replay becomes more practical. The scanner’s Authentication and BOLA/IDOR checks, run in parallel, test whether authentication bypass or insecure direct object references coexist with JWT usage, increasing the likelihood of detecting a weak authentication surface.

To reduce the risk of password spraying when using JWT tokens in AdonisJS, apply defense-in-depth controls at the endpoint, token, and monitoring levels. The following code examples demonstrate concrete, framework-aware remediations.

1. Enforce rate limiting on the login route

Use AdonisJS RateLimiter to throttle authentication attempts per identity and IP. This prevents an attacker from spraying many passwords against a single user without being throttled.

// start/handlers.ts or a dedicated Route middleware
import { RateLimiter } from '@ioc:Adonis/Addons/RateLimiter'

Route.post('login', async ({ request, auth, response }) => {
  const email = request.input('email')
  // Apply rate limit keyed by email and IP
  await RateLimiter.throttle(`login:${email}:${request.ip()}`).check(5, 60)

  const token = await auth.use('jwt').attempt(email, request.input('password'))
  return response.send({ token: token.toJwt() })
})

2. Use consistent error responses and avoid user enumeration

Return the same generic message regardless of whether the account exists. Combine with short JWT lifetimes to reduce the usefulness of a stolen token.

// app/Controllers/Http/AuthController.ts
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { schema } from '@ioc:Adonis/Core/Validator'

export default class AuthController {
  public async login({ request, auth, response }: HttpContextContract) {
    const validatorSchema = schema.create({
      email: schema.string({ trim: true, normalize: true }),
      password: schema.string.optional()
    })
    const validated = await request.validate({ schema: validatorSchema })

    try {
      const token = await auth.use('jwt').attempt(validated.email, request.input('password'))
      return response.json({ token: token.toJwt() })
    } catch {
      // Always return the same shape and status to avoid leaking account existence
      return response.unauthorized({ message: 'Invalid credentials' })
    }
  }
}

3. Strengthen JWT payload and verification

Include minimal claims, set short expirations, and bind tokens to the user agent or IP where appropriate. Verify signatures strictly and avoid exposing sensitive data in the payload.

// config/jwt.ts snippet
import { jwtConfig } from '#types/jwt'

const jwt = {
  guard: 'jwt',
  secret: process.env.JWT_SECRET,
  token: {
    expiresIn: '15m',
    issuer: 'adonis-app',
    audience: 'adonis-api'
  },
  async handlePayload(payload: any, user: any) {
    return {
      sub: user.id,
      email: user.email,
      iat: Date.now(),
      ua: payload.ua // optional: bind to user-agent hash
    }
  }
} satisfies jwtConfig

export default jwt

4. Add suspicious activity monitoring and token revocation

Track repeated failures per identity and, when paired with the dashboard or custom hooks, revoke suspicious sessions. The scanner flags missing revocation or anomaly detection as a potential finding.

// app/Services/TokenRevocation.ts
import { DateTime } from 'luxon'

export default class TokenRevocation {
  private static revoked = new Set()

  static revoke(jti: string) {
    this.revoked.add(jti)
  }

  static isRevoked(jti: string) {
    return this.revoked.has(jti)
  }

  static cleanup() {
    // periodic cleanup logic
  }
}

5. Combine with Multi-Factor Authentication (MFA)

Require a second factor for high-risk actions or for accounts flagged by rate limiting. This reduces the impact of a token obtained via spraying.

// Example guard check before issuing sensitive token
if (await User.query().where('id', userId).preload('mfa').first()) {
  // require MFA verification before returning a long-lived token
  return response.badRequest({ mfaRequired: true })
}