Header Injection in Adonisjs with Api Keys

Header Injection in an AdonisJS application that uses API keys occurs when untrusted input is reflected into HTTP response headers without validation or sanitization. If an API key is accepted from a request header (e.g., x-api-key) and that value is later concatenated into another header, injected newline characters (CRLF, %0D%0A or \r\n) can enable injection of arbitrary headers such as Set-Cookie, Location, or X-Content-Type-Options. This can lead to session fixation, cross-site scripting (XSS) in browsers that interpret injected headers, or bypass of security controls that rely on header values.

AdonisJS does not inherently treat API key values as safe; developers often copy the key from headers into custom headers or logs. For example, reflecting the API key into a x-client-key header without sanitization allows an attacker to inject additional headers:

GET /api/resource?api_key=YOUR_KEY HTTP/1.1
Host: example.com
x-api-key: YOUR_KEY%0D%0ASet-Cookie:%20session=attacker

If the server does not sanitize the x-api-key and directly assigns it to response.header('x-client-key', apiKey), the injected CRLF can cause the Set-Cookie header to be appended and processed. This exposes the unauthenticated attack surface that middleBrick tests, including Header Injection under the broader Input Validation and Property Authorization checks, and can be observed in the per-category breakdown provided in the scan report.

Additionally, logging API keys unsafely may aid attackers in correlating requests or probing key formats. Even when API keys are used only for authentication, improper handling that allows newline characters in headers can bypass intended access controls. The risk is compounded if responses include sensitive data that could be exfiltrated via injected headers like Location in a 3xx redirect. These patterns are relevant to the LLM/AI Security checks when endpoints exposed to AI tooling lack strict input validation, enabling prompt injection or data exfiltration attempts that rely on header manipulation.

middleBrick scans such endpoints in 5–15 seconds, testing unauthenticated attack surface and identifying Header Injection risks alongside other checks like BOLA/IDOR and Input Validation. The scan produces a security risk score and prioritized findings with remediation guidance, helping teams understand how API key usage in headers can lead to exploitable conditions without requiring agents or credentials.

Remediation focuses on strict validation, avoiding reflection of raw API key values into headers, and safe usage patterns. Do not directly assign user-controlled API key values into response headers. Instead, treat API keys as opaque credentials for authentication only, and never echo them back in headers or logs.

Use environment variables or a secure vault to store expected API keys, and compare them using a constant-time comparison to avoid timing attacks. If you must associate a key with a request context, map it to an internal identifier and use that for processing, never reflecting the raw key.

Example of unsafe code to avoid:

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

export default class ApiController {
  public handle({ request, response }: HttpContextContract) {
    const apiKey = request.header('x-api-key')
    // UNSAFE: directly reflecting user input into a header
    response.header('x-client-key', apiKey)
    // ... rest of logic
  }
}

Safe remediation example with validation and no reflection:

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

// Assume keys are stored securely and compared safely
const VALID_API_KEYS = [process.env.API_KEY_1, process.env.API_KEY_2]

export default class ApiController {
  public handle({ request, response }: HttpContextContract) {
    const apiKey = request.header('x-api-key')
    if (!apiKey || !VALID_API_KEYS.includes(apiKey)) {
      return response.unauthorized('Invalid API key')
    }
    // Use an internal identifier instead of echoing the key
    const internalId = 'assoc-id-for-key'
    response.header('x-request-id', internalId)
    // Proceed with authenticated logic
  }
}

When integrating with middleBrick, use the CLI tool to validate remediation: middlebrick scan <url>. For CI/CD, the GitHub Action can enforce a score threshold to prevent deployments with Header Injection findings. The Dashboard helps track improvements over time. These products support safe API key handling without exposing raw keys in headers.

Additional measures include sanitizing any user-influenced data before it reaches headers, using frameworks that provide built-in header safety where possible, and testing with active probes that check for injected headers. The LLM/AI Security checks are particularly useful when endpoints interact with AI tooling, ensuring that header manipulation cannot be used to influence model behavior or exfiltrate data via crafted outputs.