Dns Rebinding in Express with Api Keys

DNS rebinding is a client-side network attack that manipulates DNS responses to make a victim’s browser connect to an internal or otherwise unintended IP address after the initial page load. When an Express API relies only on API keys for access control, this interaction can bypass authorization assumptions and expose internal services.

Consider an Express service that accepts an API key via a request header and returns sensitive internal information or accepts administrative actions:

// vulnerable-express-api.js
const express = require('express');
const app = express();
const PORT = 3000;

// Insecure: API key only in header, no origin validation
app.get('/admin/reset', (req, res) => {
  const apiKey = req.get('X-API-Key');
  if (apiKey !== process.env.SUPER_KEY) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  // Dangerous internal action with only API key guard
  resetInternalSystem();
  res.json({ ok: true });
});

app.listen(PORT, () => console.log(`Listening on ${PORT}`));

An attacker can host a malicious page that causes the victim’s browser to make a request to http://localhost:3000/admin/reset with a valid API key supplied via JavaScript. Because the endpoint trusts the header alone, the request succeeds from the internal network perspective. DNS rebinding makes it possible to reach internal IPs that are not normally exposed to external clients, bypassing network segregation. The API key provides authorization, but the server incorrectly equates it with privilege and network safety, while the browser’s same-origin policy does not protect internal targets once the attacker can resolve a hostname to 127.0.0.1 or another internal address.

In a scan, such patterns can be detected through checks that analyze input validation, authorization scope, and SSRF-related behaviors. middleBrick’s scan tests unauthenticated attack surfaces and flags findings related to authorization bypass when controls depend solely on static secrets like API keys without additional context (e.g., origin, referer, or binding to a session).

To reduce risk, treat API keys as one factor in a broader authorization strategy and add network-aware controls in Express. Do not rely on a key header alone to protect operations that can affect internal resources.

1) Validate origin and referer where applicable. Compare incoming request origin or referer against an allow-list and reject mismatches. Note that these headers can be omitted by some clients, so use this as a defense-in-depth measure, not a sole gate.

// secure-express-api.js
const express = require('express');
const app = express();
const PORT = 3000;

const ALLOWED_ORIGINS = ['https://myapp.example.com', 'https://staging.example.com'];
const REQUIRED_API_KEY = process.env.SUPER_KEY;

function validateOrigin(req, res, next) {
  const origin = req.get('Origin');
  const referer = req.get('Referer');
  if (!origin && !referer) {
    return res.status(403).json({ error: 'Forbidden: missing origin and referer' });
  }
  const allowed = (origin && ALLOWED_ORIGINS.includes(origin)) ||
                  (referer && ALLOWED_ORIGINS.some(o => referer.startsWith(o)));
  if (!allowed) {
    return res.status(403).json({ error: 'Forbidden: origin not allowed' });
  }
  return next();
}

app.use(validateOrigin);

2) Bind API keys to IP or subnet when feasible. If your deployment architecture permits, maintain a mapping of allowed API keys to source IP ranges and enforce this in Express before performing sensitive actions.

// ip-bound-middleware.js
const ipMap = {
  '1.2.3.4': 'key-a',
  '10.0.0.55': 'key-b' // internal service key
};

function ipKeyAuth(req, res, next) {
  const apiKey = req.get('X-API-Key');
  const sourceIp = req.ip;
  const allowedKey = ipMap[sourceIp];
  if (!apiKey || apiKey !== allowedKey) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  return next();
}

module.exports = ipKeyAuth;

Apply this middleware selectively to admin or sensitive routes:

const ipKeyAuth = require('./ip-bound-middleware');
app.post('/admin/reset', ipKeyAuth, (req, res) => {
  resetInternalSystem();
  res.json({ ok: true });
});

3) Require additional context for dangerous operations. Use multi-step confirmation or session-bound tokens for critical endpoints rather than a single static header value.

app.post('/admin/confirm-reset', (req, res) => {
  const apiKey = req.get('X-API-Key');
  const confirmationToken = req.body.token;
  if (apiKey !== process.env.SUPER_KEY) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  if (!confirmationToken || !isValidConfirmation(confirmationToken)) {
    return res.status(403).json({ error: 'Missing or invalid confirmation token' });
  }
  resetInternalSystem();
  res.json({ ok: true });
});

middleBrick’s scans include checks for authentication, authorization, and input validation, and they highlight findings tied to improper authorization scope. By combining API keys with origin checks, IP binding, and step-up confirmation, you align with secure patterns and reduce the impact of DNS rebinding and similar client-side attacks.