Dangling Dns in Adonisjs with Jwt Tokens

A dangling DNS configuration in an AdonisJS application using JWT tokens can expose authentication tokens to unauthorized resolution paths. When JWT tokens contain references—such as issuer (iss), audience (aud), or redirect URLs—that point to hostnames which later resolve to unintended or unmanaged endpoints, the token validation surface can be abused.

In AdonisJS, JWT handling typically relies on jwt utilities from @adonisjs/auth. If a token’s payload includes a hostname that is resolved at validation time via DNS (for example, dynamic issuer verification or hostname-based audience checks), and that hostname later points to an attacker-controlled IP due to DNS rebinding or dangling records, the token may be accepted in an unintended security context.

Consider an AdonisJS app that validates the iss claim by performing a DNS lookup to ensure the issuer hostname resolves to a known service. An attacker who can control a dangling DNS record for that hostname might redirect resolution to a malicious host. If the application does not pin or strictly validate the issuer beyond DNS resolution, a token issued for a legitimate service could be accepted as valid when presented to the malicious host, enabling token misuse across services.

This becomes particularly relevant in microservice environments where tokens are issued by an auth service and consumed by multiple services. If one service’s hostname becomes dangling or points to an insecure endpoint during reconfiguration, JWT tokens containing that hostname as iss or aud can be used in an unexpected trust boundary. AdonisJS applications that perform relaxed hostname validation—such as only checking domain suffixes or using permissive CORS/redirect rules—may inadvertently accept tokens that should be rejected.

Additionally, if the application embeds hostnames in JWT claims for post-login redirect or callback URLs (e.g., redirect_uri), and those hostnames later resolve to unintended locations, tokens may be used in phishing or open redirect flows. An attacker can exploit a dangling DNS record to intercept authorization callbacks, leading to token leakage or session fixation.

To detect this class of issue, middleBrick runs checks aligned with OWASP API Top 10 (2023) API4:2023 — Injection and API Security Misconfiguration, and maps findings to related standards such as PCI-DSS and SOC2. The scanner does not modify or block traffic; it identifies conditions where token validation logic may be overly dependent on DNS-resolvable hostnames.

Remediation focuses on strict validation of JWT claims and avoiding reliance on DNS-resolvable hostnames for security decisions. In AdonisJS, you should enforce exact issuer and audience values and avoid dynamic hostname comparisons.

1. Pin issuer and audience without DNS-dependent checks

Instead of resolving hostnames at runtime, hardcode expected values and compare them directly.

import { BaseValidator } from '@ioc:Adonis/Core/Validator'
import { createMiddleware } from '@adonisjs/core/http'
import { Jwt } from '@adonisjs/auth/jwt'

const expectedIssuer = 'https://auth.example.com'
const expectedAudience = 'https://api.example.com'

export const validateJwt = createMiddleware(async (ctx, next) => {
  const token = ctx.request.header('authorization')?.replace('Bearer ', '')
  if (!token) {
    ctx.response.unauthorized('Missing token')
    return
  }

  try {
    const payload = Jwt.verify(token, process.env.JWT_SECRET!, {
      issuer: expectedIssuer,
      audience: expectedAudience,
    })
    ctx.auth.user = payload
    await next()
  } catch (error) {
    ctx.response.unauthorized('Invalid token')
  }
})

2. Avoid embedding hostnames in JWT claims used for redirects

If you must include a hostname, validate it against an allowlist rather than relying on DNS resolution.

const allowedRedirectHosts = new Set(['app.example.com', 'cdn.example.com'])

function validateRedirectUrl(url: string): boolean {
  const hostname = new URL(url).hostname
  return allowedRedirectHosts.has(hostname)
}

export const handleCallback = async ({ request, response }) => {
  const redirectUrl = request.input('redirect_url')
  if (!validateRedirectUrl(redirectUrl)) {
    return response.badRequest('Invalid redirect URL')
  }
  // safe to proceed
}

3. Enforce strict token validation options

Always set iss, aud, and maxAge during verification and avoid skipping validation for convenience.

import { Jwt } from '@adonisjs/auth/jwt'

const publicKey = process.env.JWT_PUBLIC_KEY
const payload = Jwt.verify(token, publicKey, {
  issuer: 'https://auth.example.com',
  audience: 'https://api.example.com',
  maxAge: '2h',
})

4. Use environment-based configuration for issuer/audience

Keep sensitive expectations in environment variables and validate format, not resolution.

// .env
JWT_ISSUER=https://auth.example.com
JWT_AUDIENCE=https://api.example.com

// config/jwt.ts
export default {
  issuer: Env.get('JWT_ISSUER'),
  audience: Env.get('JWT_AUDIENCE'),
}

5. Rotate secrets and monitor anomalies

Even without DNS dependencies, rotate signing keys and monitor token usage patterns. middleBrick can help identify unusual token validation outcomes that may indicate misuse stemming from misconfiguration.

These steps reduce the risk that dangling or manipulated DNS records affect JWT validation. By removing hostname resolution from the trust decision, you limit the attack surface introduced by token claims that depend on network-level identifiers.