Open Redirect in Loopback with Mutual Tls

An open redirect occurs when an application accepts a user-controlled URL or path and uses it in a redirect without proper validation. In Loopback, this typically manifests through endpoint parameters such as next, redirect, or return that are not strictly validated. When mutual Transport Layer Security (mTLS) is enforced, the server requests and validates a client certificate, which can create a false sense of security. Operators may assume that mTLS alone prevents unauthorized redirects, but mTLS only authenticates the client to the server; it does not restrict how the server uses untrusted input.

Consider a Loopback endpoint that accepts a redirect target after successful authentication:

const redirectTo = req.query.next || '/dashboard';
res.redirect(redirectTo);

If the endpoint is protected by mTLS, an authenticated client with a valid certificate might still supply a malicious next value such as https://evil.com. Because the developer trusted the authenticated session, the redirect is performed without validating that the target belongs to the expected domain. This is an authentication bypass in business logic rather than a failure of the TLS handshake. An attacker could craft a link like https://api.example.com/account/transfer?next=https://evil.com and, if the victim is already authenticated via mTLS, be redirected to the attacker-controlled site.

In a black-box scan by middleBrick, this would appear under BFLA/Privilege Escalation and Property Authorization checks. The scanner does not need credentials when mTLS is enforced; it tests whether a valid client certificate still permits an untrusted redirect. The server’s response would indicate a 3xx status code pointing to an external host, which is flagged as a high-severity finding. Even with mTLS, you must treat URL inputs as untrusted and validate them against an allowlist of known, safe paths.

Remediation focuses on strict input validation and avoiding any direct use of client-supplied URLs for redirection. Never trust parameters such as next or return when mTLS is in use. Instead, map allowed destinations to a whitelist or use server-side identifiers.

Example of a vulnerable pattern that should be avoided:

// Vulnerable: uses raw query parameter for redirect
app.get('/transfer', (req, res) => {
  const target = req.query.to;
  res.redirect(target);
});

Secure alternative using a whitelist of allowed paths:

// Secure: validate against a known set of destinations
const ALLOWED_REDIRECTS = new Set(['/dashboard', '/profile', '/settings']);

app.get('/profile', (req, res) => {
  const next = req.query.next;
  if (!next || !ALLOWED_REDIRECTS.has(next)) {
    return res.status(400).send('Invalid redirect target');
  }
  res.redirect(next);
});

If you need to support external but pre-approved destinations, use an allowlist of domains and ensure the final URL uses HTTPS:

const ALLOWED_HOSTS = new Set(['app.example.com', 'partner.example.com']);

function isSafeUrl(url) {
  try {
    const parsed = new URL(url, 'https://example.com');
    return ALLOWED_HOSTS.has(parsed.hostname) && parsed.protocol === 'https:';
  } catch {
    return false;
  }
}

app.get('/external', (req, res) => {
  const url = req.query.url;
  if (!isSafeUrl(url)) {
    return res.status(400).send('Unsafe redirect');
  }
  res.redirect(url);
});

When using the middleBrick CLI to verify your fix, you can run:

middlebrick scan https://api.example.com/account/transfer

For teams using automation, the GitHub Action can be added to CI/CD to fail builds if a redirect is detected without proper validation, even when mTLS is enforced. The MCP Server enables scanning directly from your IDE while you develop these endpoints, ensuring that open redirect risks are caught early.