Man In The Middle in Adonisjs with Api Keys

A Man In The Middle (MitM) attack against an AdonisJS API that relies solely on API keys occurs when an attacker intercepts traffic between the client and server. Because API keys are often static bearer tokens passed in headers, intercepted keys can be reused to impersonate clients or escalate access. This risk is amplified when transport security is inconsistent (for example, HTTP is allowed or TLS is misconfigured), when keys are stored or logged insecurely, and when the API lacks additional context checks such as mTLS or rotating tokens.

In AdonisJS, API keys are typically validated via middleware that reads a key from headers (e.g., Authorization or a custom header) and checks it against a database or configuration. If an attacker positions themselves on the network path—such as through a compromised Wi‑Fi access point, a proxy misconfiguration, or an insecure load balancer—they can observe or modify requests. Even if the API key itself is not leaked, an attacker who can terminate or alter TLS (for example, by presenting a malformed certificate when the server does not enforce strict certificate validation) may downgrade or manipulate the request. AdonisJS applications that do not enforce HTTPS strictly and that do not validate the integrity of each request beyond the key become susceptible to session hijacking and unauthorized operations.

The combination of AdonisJS routing and API key handling can inadvertently expose sensitive data or operations when MitM is possible. For example, if an API endpoint reflects user input without enforcing integrity checks or replay protections, an intercepted request can be replayed with the same API key to perform actions the original client intended but over a malicious connection. Logging mechanisms that capture full request headers may also inadvertently store API keys in plaintext, increasing the exposure surface if logs are compromised during transit or at rest. MiddleBrick scans detect such exposure by analyzing unauthenticated attack surfaces and flagging missing transport protections, excessive data exposure in responses, and weak encryption configurations.

Real-world attack patterns relevant to this scenario include credential replay, where an intercepted API key is reused; SSRF-induced MitM when the API fetches external resources without strict network segmentation; and insecure default configurations that allow cleartext HTTP. MiddleBrick’s checks for Encryption, Data Exposure, and SSRF help highlight these risks by correlating runtime findings with OpenAPI specifications, including $ref resolution across spec versions. This ensures that even indirect paths—such as nested references or parameter-driven endpoints—are evaluated for how API keys flow through the application.

Compliance mapping further clarifies the impact: OWASP API Top 10 A02:2023 (Cryptographic Failures) and A05:2023 (Broken Function Level Authorization) map closely to MitM with API keys, as do PCI-DSS requirements around transmission security and SOC2 controls around logical access. Without enforced TLS and robust key lifecycle practices, an AdonisJS API may pass basic authentication checks but still be vulnerable to interception and abuse. MiddleBrick’s unauthenticated scanning approach can surface these weaknesses without requiring credentials, providing a baseline before deeper testing or pentest engagements.

Remediation focuses on ensuring API keys are transmitted and handled securely within AdonisJS, reducing the window for MitM exploitation. Always enforce HTTPS across all routes and API entry points, and avoid any fallback to HTTP. Use strong key generation practices, avoid logging keys, and apply strict validation and scope checks within your middleware.

Below are concrete AdonisJS code examples that demonstrate secure API key handling and MitM countermeasures.

// config/env.ts — enforce HTTPS in production
import { Env } from '@ioc:Adonis/Core/Env'

export const environment = Env.get('NODE_ENV', 'development')
export const isProduction = environment === 'production'
export const enforceHttps = isProduction

// middleware/ensureHttps.ts
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export default async function ensureHttps({ request, response, session }: HttpContextContract) {
  const enforceHttps = await import('../../../config/env').then(mod => mod.enforceHttps)
  if (enforceHttps && !request.secure) {
    response.status(403).json({ error: 'HTTPS required' })
    return false
  }
  return true
}

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

export default async function validateApiKey({ request, response }: HttpContextContract) {
  const key = request.headers().authorization?.replace('ApiKey ', '')
  if (!key) {
    response.status(401).json({ error: 'ApiKey missing' })
    return false
  }

  const apiKey = await ApiKey.query()
    .where('key', key)
    .where('revoked', false)
    .preload('scope') // assuming a related Scope model
    .first()

  if (!apiKey || !apiKey.scope) {
    response.status(403).json({ error: 'Invalid or insufficient scope' })
    return false
  }

  // Ensure key is bound to request context where possible
  request.apiKey = apiKey
  return true
}

// middleware/rateLimitByKey.ts — reduces replay and brute-force impact
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { RateLimiterMemory } from 'rate-limiter-flexible'

const limiter = new RateLimiterMemory({
  points: 60, // requests
  duration: 60, // per minute
  keyPrefix: 'apikey_limiter'
})

export default async function rateLimitByKey({ request, response }: HttpContextContract) {
  const key = request.headers().authorization?.replace('ApiKey ', '')
  if (!key) return true

  try {
    await limiter.consume(key)
    return true
  } catch (_) {
    response.status(429).json({ error: 'Too many requests' })
    return false
  }
}

// routes/api.ts — apply security middleware in order
import Route from '@ioc:Adonis/Core/Route'
import EnsureHttps from 'App/Middleware/ensureHttps'
import ValidateApiKey from 'App/Middleware/validateApiKey'
import RateLimitByKey from 'App/Middleware/rateLimitByKey'

Route.group(() => {
  Route.get('/resource', async ({ json }) => {
    return { data: 'secure resource' }
  })
}).middleware([EnsureHttps, ValidateApiKey, RateLimitByKey])

These examples emphasize transport enforcement, strict key validation with revocation checks, scope scoping, and rate limiting to mitigate replay and brute-force risks associated with intercepted API keys. They also reduce opportunities for exposure in logs by avoiding key echoing and encouraging selective preloading of relationships rather than broad data fetching.

In production, combine these patterns with environment-managed secrets, regular key rotation, and integration with a secrets manager where supported. MiddleBrick’s Pro plan can be used for continuous monitoring of these configurations, with GitHub Action integration to fail builds if insecure routes or missing HTTPS enforcement are detected during CI/CD, helping maintain posture as APIs evolve.