Credential Stuffing in Adonisjs with Api Keys

Credential stuffing is an automated attack where valid username and password pairs obtained from data breaches are used to gain unauthorized access to user accounts. In AdonisJS, developers sometimes use API keys as a lightweight authentication mechanism for routes intended for machine-to-machine communication or public clients. When API keys are used without additional protections—such as per-user binding, rate limiting, or strict scope control—they can become a vector for credential stuffing–style abuse.

Consider a scenario where an AdonisJS application exposes a user profile endpoint that accepts an API key via an HTTP header (e.g., X-API-Key). If the API key is treated as a global secret rather than being tied to a specific user or scope, an attacker can take a list of breached credentials (usernames and passwords) and attempt to derive or reuse API keys across accounts. Even if the API key is not directly derived from passwords, weak generation practices (e.g., low entropy, predictable patterns) can make keys guessable. The attacker can then automate requests using stolen or guessed keys to enumerate user data, escalate privileges, or perform actions on behalf of legitimate users.

Another risk pattern arises when API keys are issued during user registration or login without proper validation or revocation mechanisms. In AdonisJS, if key creation does not enforce uniqueness, associate keys with a single user identity, or rotate them after suspicious activity, credential stuffing can be compounded by key reuse across multiple compromised accounts. For example, an attacker might use a breached credential to authenticate interactively, extract an API key from the client-side code or logs, and then use that key to bypass rate limits or authentication checks designed for traditional password-based flows.

The 12 parallel security checks in middleBrick include BOLA/IDOR, Input Validation, and Rate Limiting, which are particularly relevant in this context. Without proper per-request authorization checks, an API key could allow horizontal or vertical privilege escalation. Input validation weaknesses may permit key injection or manipulation, while missing rate limiting can enable bulk enumeration using a single key. middleBrick’s scan can detect these risky configurations by correlating OpenAPI/Swagger specs with runtime behavior, highlighting where API key usage intersects with authentication and authorization gaps.

For LLM-specific concerns, if an AdonisJS API exposes an unauthenticated endpoint that returns sensitive system or user data, middleBrick’s LLM/AI Security checks can identify whether API keys are leaked in model outputs, prompt contexts, or error messages. System prompt leakage detection and active prompt injection testing further ensure that API key handling does not inadvertently expose control instructions or sensitive data to unauthorized LLM interactions.

Ultimately, using API keys in AdonisJS requires careful design to avoid turning them into a credential stuffing vector. Keys must be user-specific, short-lived, scoped, and protected by rate limiting and strict input validation. Security scans that combine spec analysis with runtime testing—like those provided by middleBrick—help surface misconfigurations before attackers can exploit them.

To mitigate credential stuffing risks when using API keys in AdonisJS, apply strict binding between keys and user identities, enforce scoped permissions, and validate every request. Below are concrete, syntactically correct code examples demonstrating secure API key handling in AdonisJS.

1. Generate and store API keys securely

Use a cryptographically secure random generator and store keys as hashes in the database. Never store raw keys in logs or responses.

import { DateTime } from 'luxon'
import { v4 as uuidv4 } from 'uuid'
import { Hash } from '@ioc:Adonis/Core/Hash'

export default class ApiKeysController {
  public async create({ auth, response }) {
    const user = auth.getUserOrFail()
    const rawKey = uuidv4() // high-entropy key
    const hashedKey = await Hash.make(rawKey)

    await user.related('apiKeys').create({
      key_hash: hashedKey,
      scope: 'read:profile write:profile',
      expires_at: DateTime.local().plus({ months: 3 }).toJSDate(),
      last_used_at: new Date(),
    })

    // Return the raw key only once
    response.send({ key: rawKey })
  }
}

2. Middleware to validate API key per request

Create an auth middleware that looks up the key hash and binds it to the request context, ensuring each request is tied to a specific user and scope.

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import ApiKey from 'App/Models/ApiKey'

export default class ApiKeyAuth {
  public async handle({ request, auth }, next) {
    const key = request.header('X-API-Key')
    if (!key) {
      throw response.unauthorized('Missing API key')
    }

    // Find the key by comparing hash
    const apiKey = await ApiKey.query()
      .where('expires_at', '>', new Date())
      .withScopes(['profile'])
      .whereHas('user', (query) => query.where('status', 'active'))
      .andWhereRaw('API_KEY_COMPARE(key_hash, ?)', [key])
      .preload('user')
      .first()

    if (!apiKey) {
      throw response.forbidden('Invalid or expired API key')
    }

    // Bind user and scope to the request
    request.authUser = apiKey.user
    request.apiScope = apiKey.scope.split(' ')

    await apiKey.merge({ last_used_at: new Date() }).save()
    await next()
  }
}

3. Scope and rate limiting

Enforce scope-based access and apply rate limits per API key to reduce the impact of potential abuse. Use AdonisJS built-in or third-party rate limiters with key-aware identifiers.

import { Exception } from '@poppinss/utils'
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export async function rateLimitByKey(ctx: HttpContextContract) {
  const key = ctx.request.header('X-API-Key')
  const identifier = `apikey:${key}`
  const limit = 100 // requests
  const window = 60 // seconds

  const current = await RateLimiter
    .create(identifier)
    .limit(limit)
    .perSeconds(window)
    .check()

  if (current.throttled) {
    throw new Exception('Rate limit exceeded', 429, 'RATE_LIMIT_EXCEEDED')
  }
}

4. Revocation and rotation

Provide mechanisms to revoke or rotate keys, especially after suspicious activity or password changes.

public async revoke({ params, response }) {
  const key = await ApiKey.findOrFail(params.id)
  await key.delete()
  response.noContent()
}

By combining secure generation, per-request validation, scope enforcement, rate limiting, and revocation, AdonisJS applications can safely use API keys without enabling credential stuffing attacks. middleBrick’s scans can validate these controls by checking spec definitions and runtime behavior to ensure no gaps remain.