Open Redirect in Loopback with Bearer Tokens

An open redirect in a Loopback API becomes more risky when Bearer Tokens are involved because tokens are often passed in query parameters or fragments during OAuth flows or callback handling. If an endpoint accepts a redirect URL (e.g., next, redirect_to, or return) and does not strictly validate the destination, an authenticated user can supply a malicious URL that includes their token. This can lead to token leakage via browser history, logs, or Referer headers, effectively exposing credentials to attackers.

Consider a typical OAuth callback handler in Loopback:

app.get('/oauth/callback', (req, res) => {
  const { token, next } = req.query;
  if (next) {
    return res.redirect(next);
  }
  res.redirect('/dashboard');
});

If next is not validated against a whitelist or anchored to the same host, an attacker can craft a link such as https://api.example.com/oauth/callback?next=https://evil.com?token=abc123. When a victim clicks the link, the token is sent to the attacker, and the victim is redirected to a malicious site. This pattern is especially dangerous when tokens are used in URLs because they may be logged by servers, proxies, or browser history.

Loopback’s routing and middleware behavior can inadvertently support open redirects when developers use dynamic paths without strict allow-listing. Even if the API relies on Bearer Tokens in the Authorization header, the presence of redirect parameters in query strings creates a second vector. Attackers may combine social engineering with these crafted URLs to hijack sessions or gain unauthorized access to third‑party services that trust the token.

Another scenario involves unauthenticated LLM endpoints or public-facing APIs where an open redirect is discovered through scanning. While this does not directly expose Bearer Tokens, it can be chained with other weaknesses to manipulate user flows. middleBrick detects such redirect risks as part of its authentication and input validation checks, helping teams identify dangerous routes before they are exploited.

Because open redirects do not typically cause direct data loss, they are often underestimated. However, in combination with Bearer Tokens, they become a critical vector for credential theft and phishing. Teams should treat any user-controlled redirection as high risk and apply strict validation, regardless of authentication method.

Secure remediation focuses on two controls: never placing Bearer Tokens in URLs and strictly validating any redirect targets. Tokens should remain in headers, and redirect parameters should be limited to relative paths or a strict host allowlist.

1. Avoid tokens in redirects

Ensure that token values are never appended to redirect URLs. Instead, store minimal state on the server or use opaque identifiers that can be mapped back to session data without exposing secrets.

2. Validate redirect targets

Implement a strict allowlist of hostnames or use path-only redirects. Below is a secure Loopback example that rejects external hosts:

const ALLOWED_HOSTS = ['app.example.com', 'dashboard.example.com'];

app.get('/oauth/callback', (req, res) => {
  const { next } = req.query;
  let target = '/dashboard';

  if (next) {
    try {
      const url = new URL(next, 'https://self.example.com');
      if (ALLOWED_HOSTS.includes(url.hostname)) {
        target = url.pathname + url.search;
      }
    } catch (err) {
      // Invalid URL, fall back to default
    }
  }
  res.redirect(target);
});

This code parses the next parameter as a full URL, checks the hostname against an allowlist, and discards any protocol-relative or malicious inputs. It ensures that only known, safe paths are used for redirection.

3. Use relative paths when possible

If external host validation is not required, prefer relative paths and avoid accepting full URLs:

app.get('/oauth/callback', (req, res) => {
  const next = req.query.next;
  // Only allow paths that start with / and contain no colon
  if (next && next.startsWith('/') && !next.includes('://')) {
    return res.redirect(next);
  }
  res.redirect('/dashboard');
});

This pattern blocks URLs containing ://, which prevents javascript: or other dangerous schemes. It also avoids DNS rebinding or host confusion attacks.

4. Keep Bearer Tokens in headers

Ensure that clients always send tokens in the Authorization header rather than query strings. Example client usage:

fetch('/api/profile', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'
  }
}).then(response => response.json());

On the server, verify tokens via middleware and reject any that appear in URLs or form data. middleBrick’s authentication checks can help identify endpoints that accept tokens in non‑standard locations, supporting compliance mapping to frameworks such as OWASP API Top 10 and SOC2.

5. Monitor and test

Use tools like the middleBrick CLI to scan endpoints for open redirects and improper token handling:

middlebrick scan https://api.example.com

For teams with tighter controls, the Pro plan enables continuous monitoring and CI/CD integration, so risky routes can be flagged before deployment. While middleBrick detects and reports, remediation requires code changes and policy enforcement by the development team.