Insecure Design in Adonisjs with Api Keys

In AdonisJS applications, insecure design around API keys often arises when keys are treated as a primary authorization boundary without additional checks. A common pattern is reading the key from request headers and using it directly to decide access, for example:

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

export default class ApiKeyController {
  public async store({ request, auth }: HttpContextContract) {
    const providedKey = request.header('X-API-Key')
    if (providedKey !== 'my-secret-key') {
      return response.unauthorized('Invalid API key')
    }
    // Proceed with business logic — insecure if this is the only gate
    return response.ok({ data: 'sensitive operation' })
  }
}

This design is vulnerable because it relies on a single static secret and does not enforce scope-based or per-entity authorization. If the key is leaked, an attacker can perform actions on behalf of any user. Moreover, AdonisJS applications that use API keys without integrating them with AdonisJS roles and scopes (e.g., using Lucid models and policies) may inadvertently allow horizontal privilege escalation: one compromised key can access data belonging to other users who share the same key category (tenant or plan level).

Another insecure design pattern is logging or exposing API keys in server-side logs, error traces, or client-side code. For instance:

logger.info(`Incoming request with API key: ${request.header('X-API-Key')}`)
// Risk: keys may appear in log aggregation systems or error reports

Additionally, failing to rotate keys or bind them to a specific identity (e.g., user ID or client ID) means that revocation or rotation is disruptive. Without per-request nonce or replay protection, captured keys can be reused. The design also becomes problematic when API keys are passed in URLs or query parameters, as they can leak via browser history, referrer headers, or proxy logs. Insecure design in AdonisJS therefore means missing defense-in-depth: no rate limiting tied to the key, no audit trails linking key usage to operations, and no differentiation between read-only and write keys at the authorization layer.

These issues map to common weaknesses such as broken access control and insufficient logging/monitoring, which are cited in the OWASP API Security Top 10. Because API keys are static credentials, they must be handled with care: scoped to least privilege, stored server-side, and never used as the sole mechanism for sensitive operations without additional context checks.

Remediation focuses on binding API keys to identities, scoping permissions, and avoiding key exposure. First, store keys securely (e.g., environment variables or a secrets manager) and reference them via config, never hardcode them:

// config/api_keys.ts
export default {
  tenantA: process.env.TENANT_A_KEY,
  tenantB: process.env.TENANT_B_KEY,
}

Next, validate the key and map it to a tenant or role before allowing access, using AdonisJS policies to enforce data-level permissions:

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

export default class ApiKeyPolicy {
  public async verifyKey({ request, auth }: HttpContextContract) {
    const providedKey = request.header('X-API-Key')
    if (!providedKey) {
      return false
    }
    // Lookup key in DB and attach tenant/scope to the request context
    const keyRecord = await ApiKey.query().where('key', providedKey).preload('tenant').first()
    if (!keyRecord || !keyRecord.isActive) {
      return false
    }
    // Attach to context for downstream use
    request.ctx.tenant = keyRecord.tenant
    request.ctx.keyScope = keyRecord.scope
    return true
  }
}

Then, enforce scope checks in routes or controllers:

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

export default class DataController {
  public async index({ request, response }: HttpContextContract) {
    const tenant = request.ctx.tenant
    if (!tenant) {
      return response.unauthorized('Tenant not resolved')
    }
    // Scope data access to the tenant resolved from the key
    const records = await SomeModel.query().where('tenant_id', tenant.id).exec()
    return response.ok(records)
  }
}

For sensitive operations, require an additional dynamic credential (e.g., a short-lived session token or OAuth token) rather than relying solely on the static API key. Rotate keys periodically and maintain an audit log that records key usage without exposing the key value:

// Avoid logging the key itself
logger.info(`API key used for tenant ${tenantId}`, { keyId: keyRecord.id })

Use middleware to apply rate limits per key and integrate with the AdonisJS ACL/ability layer to differentiate read vs write permissions. If you use the middleBrick CLI (middlebrick scan <url>) or GitHub Action, you can detect missing scoping and logging risks in your CI/CD pipeline before deployment.