Dangling Dns in Express (Javascript)

A dangling DNS vulnerability occurs when a subdomain (e.g., api.example.com) points via a CNAME record to an external service (like a cloud load balancer or SaaS platform) that has been deprovisioned, but the DNS record remains. An attacker can then claim the dangling subdomain and host malicious content under your domain, potentially leading to session hijacking, phishing, or credential theft.

In an Express.js application, this risk is amplified if your API relies on subdomain-based routing or trusts the Host header for security decisions. For example, if your Express app uses app.subdomain() middleware or dynamically constructs redirect URLs based on the request hostname, a dangling subdomain under an attacker’s control could be exploited.

Consider an Express route that redirects users after authentication:

app.get('/auth/callback', (req, res) => {
  const redirectTo = req.query.redirect || '/';
  // Vulnerable: uses request hostname without validation
  res.redirect(`https://${req.hostname}${redirectTo}`);
});

If api.example.com is dangling and an attacker controls it, they could lure a user to https://attacker-controlled-subdomain.example.com/auth/callback?redirect=/malicious. After authentication, the user is redirected to https://attacker-controlled-subdomain.example.com/malicious, which the attacker hosts, enabling session theft via stolen cookies or tokens.

middleBrick detects dangling DNS risks by scanning for subdomains pointing to deprovisioned cloud resources (e.g., AWS ELB, Azure Front Door, Vercel) as part of its unauthenticated attack surface analysis. While it does not fix DNS records, it identifies the exposure so teams can remediate at the DNS level.

To mitigate dangling DNS risks in Express applications, implement strict hostname validation and avoid trusting user-controlled input in redirects or subdomain logic. Use an allowlist of known, trusted hostnames for any hostname-dependent operations.

Replace vulnerable hostname usage with explicit validation:

const TRUSTED_HOSTS = ['api.example.com', 'app.example.com'];

app.get('/auth/callback', (req, res) => {
  const redirectTo = req.query.redirect || '/';
  const hostname = req.hostname;

  // Reject if hostname is not in trusted list
  if (!TRUSTED_HOSTS.includes(hostname)) {
    return res.status(400).send('Invalid hostname');
  }

  // Only allow relative paths or trusted external URLs
  const url = new URL(redirectTo, 'https://example.com');
  if (url.hostname !== 'example.com' && !url.hostname.endsWith('.example.com')) {
    return res.status(400).send('Invalid redirect URL');
  }

  res.redirect(`https://${hostname}${url.pathname}${url.search}`);
});

Additionally, use middleware to normalize and validate the Host header early:

function validateHost(hosts) {
  return (req, res, next) => {
    const hostname = req.hostname.split(':')[0]; // Remove port
    if (!hosts.includes(hostname)) {
      return res.status(400).send('Invalid Host header');
    }
    next();
  };
}

app.use(validateHost(['api.example.com', 'app.example.com']));

These practices ensure that even if a dangling subdomain is claimed by an attacker, your Express application will reject requests to it. middleBrick’s scan can validate whether such protections are in place by analyzing runtime responses to hostname variations, helping confirm that your remediation is effective.