Api Key Exposure in Adonisjs with Api Keys

When API keys are used in an AdonisJS application without strict controls, they can be exposed through routes, logs, or error messages, effectively leaking long-lived credentials. AdonisJS applications that embed keys directly in environment files or source code risk exposing those keys if the repository is public or improperly secured. For example, a route that forwards requests with an Authorization: ApiKey <key> header may inadvertently log the full header, including the key, especially if debug logging is enabled in production.

Consider an AdonisJS route that proxies requests to a third‑party service using an API key stored in .env and accessed via Env.get('EXTERNAL_API_KEY'). If the route does not sanitize logs and an error occurs, the key may appear in stack traces or application logs. A related risk arises when OpenAPI specs generated from AdonisJS code include the key as a literal example value; these specs may be published to developer portals or committed to version control, creating a second vector for exposure.

During a black‑box scan, middleBrick tests for this exposure by probing endpoints that accept and reflect API key values, inspecting responses for key leakage, and analyzing spec artifacts for embedded keys. It checks whether the unauthenticated attack surface reveals keys through verbose error messages, missing input validation on key‑like parameters, or overly permissive CORS rules that allow external domains to trigger key‑bearing requests. The LLM/AI Security checks specifically look for system prompt leakage patterns that could expose key handling logic, and active prompt injection probes attempt to coerce the API into returning key values or configuration details.

Compliance mappings are relevant here: findings may align with OWASP API Top 10 A07:2021 (Identification and Authentication Failures) and A05:2021 (Security Misconfiguration), as well as controls in frameworks such as PCI‑DSS and SOC2 that require protection of credential material. middleBrick provides per‑category breakdowns so you can see whether a specific finding relates to authentication, data exposure, or unsafe consumption, along with prioritized remediation guidance.

Using middleBrick’s CLI, you can scan an AdonisJS endpoint with middlebrick scan https://api.example.com to detect potential key exposure without installing agents or providing credentials. If you require continuous monitoring, the Pro plan supports scheduled scans and alerts, while the GitHub Action can fail builds when a scan detects high‑severity issues, helping prevent key leaks from reaching production.

Remediation focuses on preventing keys from appearing in logs, error messages, specs, and client‑facing responses. Store keys in .env and access them via Env.get, never hard‑coding them. Ensure logs redact sensitive headers and that debug output is disabled in production.

Example of a vulnerable route that echoes the API key in logs:

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

export default class ProxyController {
  public async proxy({ request, response }: HttpContextContract) {
    const key = Env.get('EXTERNAL_API_KEY')
    // Vulnerable: logging the key
    logger.info('Outgoing request', { apiKey: key, url: request.input('url') })
    const res = await fetch(request.input('url'), {
      headers: { Authorization: `ApiKey ${key}` }
    })
    return response.send(await res.text())
  }
}

Fixed version with redaction and no key in logs:

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

export default class ProxyController {
  public async proxy({ request, response }: HttpContextContract) {
    const key = Env.get('EXTERNAL_API_KEY')
    // Safe: do not log the key
    logger.info('Outgoing request', { url: request.input('url') })
    const res = await fetch(request.input('url'), {
      headers: { Authorization: `ApiKey ${key}` }
    })
    return response.send(await res.text())
  }
}

Also sanitize any OpenAPI generation to avoid embedding keys in examples. Use placeholder values instead:

// Avoid this in generated specs:
// securitySchemes:
//   ApiKeyAuth:
//     type: apiKey
//     in: header
//     x-example: <actual-key>

// Use this instead:
// securitySchemes:
//   ApiKeyAuth:
//     type: apiKey
//     in: header
//     description: Provide a valid API key

For CI/CD integration, the middleBrick GitHub Action can validate that no high‑severity findings appear before deployment, and the MCP Server allows you to scan endpoints directly from your IDE, supporting rapid feedback during development.