Open Redirect in Restify with Mutual Tls

An Open Redirect occurs when an application redirects an HTTP request to an arbitrary URL supplied by the user without proper validation. In Restify, this typically arises when a handler reads a URL or host parameter from the request (e.g., query string or header) and uses it directly in a redirect response. Adding Mutual TLS (mTLS) changes the trust boundary but does not inherently fix validation logic; in some configurations it may inadvertently expose redirect risks by shifting developer assumptions.

With mTLS, the server requests and validates a client certificate, establishing identity assurance for the caller. While this strengthens authentication, it can create a false sense of security. If the server assumes that only authenticated, authorized clients are making requests, it might relax redirect validation (e.g., allowing any host header or relative path). An attacker who compromises a legitimate mTLS client, or exploits an insecure redirect endpoint, can leverage mTLS-authenticated sessions to perform phishing or token-hijacking redirects to malicious domains.

Consider a Restify endpoint that uses a query parameter to determine where to send the client after login. Without strict allowlisting, an attacker can supply a malicious URL. Even with mTLS ensuring the request comes from a trusted client, the server must still validate the target URL. The combination of mTLS and missing input validation means the server trusts the client identity but not the client’s intentions, and an authorized client can still craft dangerous redirect payloads if the application does not enforce strict rules.

In practice, this manifests when Restify routes use parameters like next or redirectUrl and pass them to response methods such as res.redirect without validating the host against an allowlist. mTLS protects channel authenticity but does not restrict which external domains the server may redirect to. This misalignment between transport-layer trust and application-layer policy can lead to open redirects that abuse authenticated sessions.

Developers might mistakenly believe mTLS prevents open redirects because the client is authenticated, but authentication and authorization are separate concerns. The server must independently validate redirect targets, ensuring they are either relative paths or belong to a pre-approved set of domains. Failing to do so turns mTLS-enabled endpoints into vectors for phishing, where a trusted session is abused to steer users to malicious sites.

To remediate open redirects in Restify while using mTLS, focus on strict input validation and secure coding practices independent of the TLS layer. Never trust headers or query parameters for redirect targets. Use allowlists for domains, prefer relative paths, and explicitly reject unexpected hosts.

Below are concrete Restify code examples that demonstrate secure handling with mTLS context. These examples assume you have configured mTLS at the server level (requesting and verifying client certificates) and show how to safely implement redirects.

const restify = require('restify');

const server = restify.createServer({
  certificate: '/path/to/server-cert.pem',
  key: '/path/to/server-key.pem',
  ca: '/path/to/ca-cert.pem',
  requestCert: true,
  rejectUnauthorized: true
});

// Allowlist of trusted redirect domains
const TRUSTED_REDIRECT_DOMAINS = new Set(['app.example.com', 'dashboard.example.com']);

function isValidRedirect(url) {
  try {
    const parsed = new URL(url, 'https://example.com');
    return TRUSTED_REDIRECT_DOMAINS.has(parsed.hostname);
  } catch (err) {
    return false;
  }
}

server.get('/secure-redirect', (req, res, next) => {
  const target = req.query.next;
  if (!target) {
    return res.send(400, { error: 'missing_redirect_target' });
  }
  if (!isValidRedirect(target)) {
    return res.send(400, { error: 'invalid_redirect_target' });
  }
  res.redirect(302, target);
  return next();
});

// Example using a relative path to avoid host-based open redirect
server.get('/login', (req, res, next) => {
  const path = '/app/dashboard'; // relative path, no host parsing needed
  res.redirect(302, path);
  return next();
});

server.listen(8080, () => {
  console.log('Secure server listening on port 8080');
});

In this example, the server enforces an allowlist (TRUSTED_REDIRECT_DOMAINS) and validates any external redirect target before issuing a 302 response. The isValidRedirect function parses the URL and checks the hostname, preventing open redirects to arbitrary domains. Using relative paths where possible further reduces risk by eliminating host-based decisions.

For dynamic scenarios where you must allow certain external services (e.g., OAuth providers), maintain a strict allowlist and avoid reflecting user input directly. Combine this with mTLS to ensure only authorized clients can reach the endpoint, but always validate the redirect target independently.