Dictionary Attack in Adonisjs with Dynamodb

A dictionary attack in an AdonisJS application that uses DynamoDB typically exploits weak authentication endpoints, most commonly the login route. In this scenario, an attacker submits a high-volume list of credential pairs (username/email and password) against the authentication handler. Because AdonisJS does not enforce strict rate limiting or account lockout by default on unauthenticated endpoints, the request flow proceeds to the DynamoDB query layer.

The DynamoDB interaction usually occurs via the AWS SDK to fetch the user record by a unique attribute such as email. If the application does not use constant-time comparison for password verification and returns distinct responses for user not found versus invalid password, the attacker can enumerate valid usernames or emails. This behavior turns DynamoDB into a side-channel that confirms the existence of an account based on response differences or timing.

Another contributing factor is the use of unauthenticated API surface. If the login endpoint is publicly reachable and lacks robust input validation, an attacker can leverage the AWS SDK’s query structure to probe backend behavior. While DynamoDB itself is not inherently vulnerable, the way the application constructs requests—such as using a direct get or query without proper rate controls—can amplify the impact of rapid-fire requests.

Consider a typical sign-in route in AdonisJS:

import User from '#models/user.js'
import { validate } from '#validators/user.js'

export default class SessionsController {
  async store({ request, auth, response }) {
    const payload = await validate(request.all(), UserLoginValidator)
    const user = await User.findBy('email', payload.email)

    if (!user || !(await verifyPassword(payload.password, user.password))) {
      return response.unauthorized({ message: 'Invalid credentials' })
    }

    const token = auth.use('jwt').generate(user)
    return response.ok({ token })
  }
}

In this example, if User.findBy maps to a DynamoDB getItem or query, each request generates a distinct call. Without additional protections—such as request throttling, exponential backoff at the application level, or integration with a managed service like AWS WAF—the endpoint becomes susceptible to high-volume dictionary attacks. The attacker iterates through credential lists, measuring response differences and potentially harvesting valid accounts.

Additionally, if the application logs failed attempts with verbose detail or exposes stack traces, it may inadvertently aid the attacker in refining the strategy. The combination of an expressive ORM layer over DynamoDB, permissive HTTP methods, and insufficient monitoring creates a practical attack path that is detectable through behavioral analysis and request fingerprinting.

To mitigate dictionary attacks in AdonisJS when interfacing with DynamoDB, implement layered defenses that address both application logic and request handling. Begin by standardizing responses so that user enumeration is not possible. Always return the same generic message and HTTP status for failed authentication, regardless of whether the user exists.

Introduce rate limiting at the route level using AdonisJS middleware. This ensures that repeated requests from a single IP or token are throttled before they reach DynamoDB.

import { middleware } from '@adonisjs/core'

export const rateLimit = middleware(async (ctx, next) => {
  const ip = ctx.request.ip()
  // Implement a sliding window counter using Redis or an in-memory store
  const attempts = await getRateLimitCount(ip)
  if (attempts > 10) {
    ctx.response.status(429).send({ message: 'Too many requests' })
    return
  }
  await next()
})

Modify the authentication flow to use a constant-time comparison for credentials and avoid branching based on user existence. Structure the DynamoDB interaction to perform a conditional fetch without revealing presence details.

import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb'
import { unmarshall } from '@aws-sdk/util-dynamodb'

const client = new DynamoDBClient({ region: 'us-east-1' })

export async function getUserByEmail(email) {
  const params = {
    TableName: process.env.DYNAMODB_USERS_TABLE,
    Key: {
      email: { S: email }
    }
  }

  const command = new GetItemCommand(params)
  const result = await client.send(command)
  return result.Item ? unmarshall(result.Item) : null
}

In the controller, refactor the login logic to always execute the DynamoDB lookup with a placeholder password verification step, ensuring timing consistency:

export default class SessionsController {
  async store({ request, auth, response }) {
    const payload = await validate(request.all(), UserLoginValidator)
    const user = await getUserByEmail(payload.email)

    // Use a dummy hash to ensure constant time when user does not exist
    const dummyHash = '$2a$10$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
    const storedHash = user ? user.password : dummyHash

    const isValid = await verifyPassword(payload.password, storedHash)
    if (!isValid) {
      return response.unauthorized({ message: 'Invalid credentials' })
    }

    if (!user) {
      // This line should never be reached due to dummy hash, but kept for safety
      return response.unauthorized({ message: 'Invalid credentials' })
    }

    const token = auth.use('jwt').generate(user)
    return response.ok({ token })
  }
}

Enable monitoring and alerting on authentication endpoints through your observability stack. If using the Pro plan, leverage continuous monitoring to detect anomalous request patterns against your login surface. For CI/CD safety, the GitHub Action can enforce a maximum risk score threshold before deployment, while the MCP Server allows real-time scanning from your IDE to catch insecure patterns early.