Dns Rebinding in Adonisjs with Api Keys

DNS rebinding is an attack where a malicious webpage changes the IP address of a domain after the initial DNS resolution, allowing it to point to an internal host that the browser believes is under the attacker’s control. In AdonisJS applications that rely on API keys for authorization, this can bypass same-origin or IP-based assumptions if the API key is treated as the sole gatekeeper without additional network-level validation.

Consider an AdonisJS service that accepts requests with an API key in a header and forwards that key to an upstream API or uses it to authorize access to internal resources. If the upstream endpoint is resolved via DNS and the attacker can cause the client (or the AdonisJS backend) to connect to a different IP after rebinding, the API key may be presented to an internal service that was never intended to be exposed publicly. This can occur when the backend uses the API key for routing or introspection without validating that the target host is on an allowed network or IP range.

For example, an AdonisJS route might look up a service URL from environment variables and forward a request with the provided API key. If DNS rebinding affects the resolved IP of that service URL, the backend could inadvertently forward credentials to a rogue internal endpoint. In a black-box scan, middleBrick tests such scenarios by checking whether responses or behaviors differ when the same logical host resolves to multiple IPs, and whether API-key-protected routes expose internal interfaces.

Additionally, if the AdonisJS application exposes an endpoint that echoes back service metadata or internal status without validating the target’s network location, an attacker can use DNS rebinding to trick the application into accessing internal APIs that require only an API key for access. Because the API key is static, the rebinding effectively bypasses network segmentation by leveraging the application’s own trust in that key.

middleBrick’s LLM/AI Security checks include Active Prompt Injection Testing and System Prompt Leakage Detection, but for API-level concerns, the 12 security checks (including BOLA/IDOR, Input Validation, and Unsafe Consumption) evaluate whether API-key usage patterns inadvertently permit access to internal or rebindable endpoints. The scan highlights whether authorization checks are coupled with network validation and whether responses expose sensitive details that could be leveraged in chained attacks.

To mitigate DNS rebinding risks when using API keys in AdonisJS, enforce strict network boundaries and validate target hosts before making outbound calls or authorizing access. Do not rely on API keys alone to protect internal services; combine them with IP allowlists, strict host validation, and scoped permissions.

Example: Safe API key usage with host validation

When your AdonisJS app must call an external service using an API key, resolve and verify the host against a whitelist before making the request. Avoid dynamic resolution of user-supplied URLs or service endpoints that can be influenced by DNS rebinding.

import { Http } from '@adonisjs/core/build/standalone'

export class ApiClient {
  private allowedHosts = new Set([
    'api.trusted-provider.com',
    'backup.api.trusted-provider.com'
  ])

  async callProtectedApi(path: string, apiKey: string) {
    const url = new URL(path, 'https://api.trusted-provider.com')
    if (!this.allowedHosts.has(url.hostname)) {
      throw new Error('Hostname not allowed')
    }

    const response = await Http.request()
      .get(url.toString())
      .header('Authorization', `Bearer ${apiKey}`)
      .timeout({ response: 5000, deadline: 8000 })

    return response.json()
  }
}

This pattern ensures that even if DNS rebinding changes the IP for a hostname, the request is still made only to explicitly permitted hosts. It also avoids forwarding API keys to user-controlled endpoints that could be swapped mid-resolution.

Example: Reject requests with private targets when using API keys

If your API key is meant for external services, ensure that you do not inadvertently allow internal routing. Reject or sanitize inputs that could lead to connections to private IP ranges.

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

export default class ProxyController {
  public async proxy({ request, response }: HttpContextContract) {
    const target = request.input('target')
    const apiKey = request.header('x-api-key')

    try {
      const url = new URL(target)
      // Basic DNS rebinding mitigation: block private IPs and localhost
      const resolved = await fetchResolvedIps(url.hostname) // implement resolution safely
      if (resolved.some(isPrivateAddress)) {
        return response.badRequest({ error: 'Private target not allowed' })
      }

      const upstreamRes = await Http.get(url.toString(), {
        headers: { Authorization: `Bearer ${apiKey}` }
      })

      return response.ok(upstreamRes.body())
    } catch (error) {
      return response.badRequest({ error: 'Invalid target' })
    }
  }
}

In this second example, the server validates that the target hostname does not resolve to a private address before using the API key to access it. This prevents an attacker from using DNS rebinding to redirect the request to, for example, 127.0.0.1 or internal services that only check for a valid API key.

General recommendations

• Pin hostnames to known IPs at configuration time when possible, rather than relying on runtime DNS resolution.
• Use short-lived API keys for sensitive operations and rotate them regularly to reduce the impact of accidental exposure.
• Apply the principle of least privilege: API keys should have only the permissions required for their specific purpose.
• Combine API key checks with network controls and avoid exposing internal endpoints solely based on key presence.