Dangling Dns in Hapi with Jwt Tokens

A dangling DNS configuration in a Hapi server can intersect dangerously with JWT token handling when the application uses hostnames from external or internal DNS to validate or construct redirect URLs during authentication flows. If the DNS record for a hostname used in JWT audience (aud), issuer (iss), or redirect parameters resolves to an attacker-controlled endpoint, an attacker can redirect token validation or authorization callbacks to a malicious host. Hapi applications that rely on dynamic DNS resolution at runtime—such as looking up an authorization server hostname from environment variables or service discovery—may inadvertently accept tokens intended for a different target if the DNS entry points elsewhere.

In this context, JWT tokens carry identity and authorization claims, and their integrity depends on strict validation of the issuer and audience. When DNS resolution for these identifiers is mutable or points to a resource that can be registered by an adversary, the trust boundary blurs. For example, a Hapi route that uses a hostname from DNS to verify JWT issuers could accept a token issued by a rogue server if the attacker registers the same hostname via DNS hijacking or temporary registration. The vulnerability is not in JWT parsing itself but in the coupling of JWT validation logic with mutable DNS records, enabling token validation to be redirected without invalidating the token cryptographically.

The risk is particularly acute in microservice environments where services resolve hostnames via DNS and use JWTs for inter-service authentication. An attacker who can influence DNS—such as through a compromised container image, a misconfigured service registry, or a vulnerable internal DNS server—can cause a Hapi service to trust tokens that appear valid but originate from an unauthorized source. This scenario maps to common OAuth and OpenID Connect misconfigurations where the relying party does not enforce strict hostname checks on iss and aud. The combined pattern of dangling DNS and JWT tokens therefore exposes an authorization bypass or token substitution path, where the intended recipient of a token is not the actual verifier.

middleBrick detects this class of issue by correlating OpenAPI/Swagger specifications with runtime behavior, identifying points where JWT validation parameters depend on external hostnames that may be unresolved or mutable. The scanner flags scenarios where JWT issuer or audience validation does not enforce strict hostname constraints, highlighting the potential for token redirection via DNS manipulation as a high-severity finding under Authentication and BOLA/IDOR checks.

To remediate dangling DNS risks with JWT tokens in Hapi, enforce static, validated hostnames for issuer and audience checks and avoid runtime DNS lookups for security-critical identifiers. Use a pinned issuer value and explicitly set the audience to a known, static identifier rather than deriving it from external sources. The following example demonstrates secure JWT validation in a Hapi route using the hapi-jwt2 strategy with fixed issuer and audience.

const Hapi = require('@hapi/hapi');
const Jwt = require('@hapi/jwt');

const server = Hapi.server({ port: 4000, host: 'localhost' });

await server.register(Jwt);

server.auth.strategy('jwt', 'jwt', {
  keys: 'your-256-bit-secret',
  verify: {
    aud: 'https://api.yourcompany.com',
    iss: 'https://auth.yourcompany.com',
    checkExp: true
  },
  validate: (artifacts, request, h) => {
    // additional custom validation if needed
    return { isValid: true };
  }
});

server.route({
  method: 'GET',
  path: '/secure',
  options: {
    auth: 'jwt',
    handler: (request, h) => {
      return { message: 'Authenticated access' };
    }
  }
});

server.start();

If dynamic issuer or audience values are required—such as when integrating with multiple tenant domains—validate hostnames against an allowlist and do not rely on DNS at validation time. The following pattern shows how to enforce hostname checks programmatically before using a value in JWT verification.

const validIssuers = ['https://auth.yourcompany.com', 'https://auth.partner.com'];

function validateIssuer(iss) {
  try {
    const url = new URL(iss);
    if (!validIssuers.includes(url.origin)) {
      throw new Error('Invalid issuer origin');
    }
    return { isValid: true, credentials: { /* map claims */ } };
  } catch (err) {
    return { isValid: false };
  }
}

server.auth.strategy('jwt-whitelist', 'jwt', {
  keys: 'your-256-bit-secret',
  verify: {
    aud: 'https://api.yourcompany.com',
    iss: (iss, request, h) => validateIssuer(iss),
    checkExp: true
  }
});

Additionally, ensure that any hostname used in redirect URIs or callback URLs is compared using a strict equality check against a preconfigured value, not resolved via DNS at the time of validation. This prevents an attacker from swapping the target host after token issuance. middleBrick’s scans highlight where issuer or audience values are derived from mutable sources, guiding developers toward hardened validation patterns.

For broader protection, apply the principle of least privilege to JWTs by scoping audiences to specific resource servers and using short lifetimes combined with refresh token rotation. In CI/CD, the middlebrick CLI can be used to enforce that no JWT validation configuration relies on unresolved hostnames, integrating checks into build gates via the GitHub Action to block insecure deployments automatically.