Open Redirect in Restify with Bearer Tokens

An open redirect in Restify occurs when an endpoint uses user-controlled input to determine the redirect target without strict validation. This becomes more risky when Bearer Tokens are involved because developers may inadvertently include token material in query parameters or headers that are reflected in redirect responses.

Consider a typical OAuth flow where a client passes both a redirect_uri and an access token in the Authorization header. If Restify uses the redirect_uri without validating it against an allowlist, an attacker can supply a malicious external URL. An example vulnerable route might look like this:

const server = restify.createServer();
server.get('/oauth/callback', (req, res, next) => {
  const { redirect_uri } = req.query;
  // Vulnerable: no validation of redirect_uri
  res.redirect(302, redirect_uri);
  return next();
});
server.listen(8080);

If the request includes a Bearer token in the Authorization header, the redirect still proceeds, and the browser follows the Location header. While the token itself is not leaked in the redirect response, the combination exposes a critical confusion: the client may mistakenly treat the redirected response as authenticated, or the token may be inadvertently logged or cached by intermediaries that follow the redirect.

An attacker can craft a URL such as https://api.example.com/oauth/callback?redirect_uri=https://evil.com and share it with a victim. If the victim is authenticated and the token is present in the Authorization header, the victim’s browser is redirected to the attacker’s site. Although the Bearer token is not directly reflected, the application’s behavior can be weaponized for phishing or to bypass same-origin assumptions, especially if the client-side logic relies on the redirect destination to infer authentication state.

Moreover, if the API returns sensitive information in headers or body and the client follows the redirect automatically, the malicious site can indirectly infer the presence or absence of certain conditions by observing timing or error differences. This is particularly relevant in flows where the token is used to access protected resources before the redirect, and misconfigured CORS or referrer headers may aid an attacker.

In the context of the LLM/AI Security checks provided by middleBrick, this pattern is flagged because it touches on unsafe consumption and input validation. The scanner tests whether untrusted redirect targets are properly validated and whether authentication context is mishandled during navigation.

To remediate open redirect vulnerabilities when using Bearer Tokens in Restify, you must validate and sanitize the redirect_uri parameter strictly. Do not rely on client-supplied values alone. Use an allowlist of trusted origins and ensure the token is handled separately from the redirect logic.

Here is a secure Restify route that validates the redirect URI against a predefined list:

const server = restify.createServer();
const ALLOWED_REDIRECT_URIS = [
  'https://app.example.com/callback',
  'https://app.example.com/complete'
];
server.get('/oauth/callback', (req, res, next) => {
  const { redirect_uri } = req.query;
  if (!redirect_uri || !ALLOWED_REDIRECT_URIS.includes(redirect_uri)) {
    return res.send(400, { error: 'invalid_redirect' });
  }
  // At this point, redirect_uri is safe to use
  res.redirect(302, redirect_uri);
  return next();
});
server.listen(8080);

Additionally, avoid including Bearer tokens in URLs or query parameters. Keep tokens strictly in the Authorization header and never reflect them in Location headers or response bodies. If you must pass state, use opaque identifiers and map them server-side without exposing tokens.

For applications using the CLI, you can run a targeted scan with the middlebrick command to detect such issues:

middlebrick scan https://api.example.com/oauth/callback

For automated checks in production-like environments, integrate the GitHub Action to fail builds when insecure redirect patterns are detected:

- name: Run middleBrick API Security Checks
  uses: middleBrick/github-action@v1
  with:
    url: https://api.example.com/oauth/callback
    threshold: B

When using the MCP Server, you can scan APIs directly from your AI coding assistant to validate redirect handling as you develop:

# In your IDE with MCP configured
# Trigger a scan on the current API endpoint definition

Finally, if you need centralized visibility, the Dashboard allows you to track your API security scores over time and correlate findings with specific endpoints that involve Bearer token flows.