Open Redirect in Feathersjs with Api Keys

An Open Redirect in a Feathersjs application using API keys typically arises when a redirect target is derived from user-controlled data such as query parameters, headers, or claims within an authenticated request. API keys are often used to authenticate service-to-service or client requests; once authentication succeeds, the application may proceed to process redirect logic without validating the destination. If the redirect URL is taken directly from a parameter like next, returnUrl, or a custom header, an attacker who knows the API key can supply a malicious location.

Consider a Feathersjs service that authenticates via an API key header and then redirects based on a query parameter:

// Feathersjs service route with authentication hook and redirect
app.service('auth').hooks({
  before: {
    create: [authenticateApiKey, redirectIfValid] // order matters
  }
});

function authenticateApiKey(hook) {
  const apiKey = hook.headers['x-api-key'];
  if (!apiKey || apiKey !== process.env.SERVICE_API_KEY) {
    throw new Error('Not authenticated');
  }
  return hook;
}

function redirectIfValid(hook) {
  const { redirectUrl } = hook.data;
  if (redirectUrl) {
    hook.app.set('redirectUrl', redirectUrl); // store or use directly
  }
  return hook;
}

If redirectUrl is not validated against an allowlist or parsed to ensure it belongs to the same host, the API key authentication does not mitigate the Open Redirect. The key confirms identity but does not enforce safe navigation. An attacker with a valid API key could supply https://evil.com/steal?token=session and trick clients into following the redirect, potentially leaking session cookies or tokens if the client is user-browsable. This becomes especially relevant when the API key is embedded in client-side code or mobile apps; although the key is not a secret on the client, the combination of authenticated routing and unchecked redirects creates an exploitable path.

Another scenario involves OAuth-like flows where the API key is used to obtain a token, and the subsequent redirect includes a state or next parameter supplied by the client. If the server trusts the parameter without verifying that it points to a same-origin or registered callback, the API key–protected endpoint can be weaponized for phishing or session fixation. The vulnerability is not in the API key mechanism itself, but in the unchecked use of external input for redirection after successful authentication.

Remediation focuses on strict validation of redirect destinations and ensuring that API key authentication is coupled with safe navigation policies. Do not rely on API keys alone to prevent insecure redirects; explicitly validate the target.

1) Use a strict allowlist or origin check for any user-supplied redirect parameters. Reject or default to a safe location if the URL does not match expected hosts.

const isValidRedirect = (url) => {
  try {
    const parsed = new URL(url, 'https://your-app.com');
    return parsed.origin === 'https://your-app.com';
  } catch {
    return false;
  }
};

app.service('auth').hooks({
  before: {
    create: [authenticateApiKey, (hook) => {
      const { redirectUrl } = hook.data;
      if (redirectUrl && !isValidRedirect(redirectUrl)) {
        throw new Error('Invalid redirect URL');
      }
      return hook;
    }]
  }
});

2) Avoid using raw user input for redirects in server-to-server flows where API keys are used. Instead, map known return paths by an identifier and resolve them server-side:

const redirectMap = {
  'settings': '/settings',
  'dashboard': '/dashboard',
  'profile': '/profile'
};

app.service('auth').hooks({
  before: {
    create: [authenticateApiKey, (hook) => {
      const { returnKey } = hook.data; // e.g., 'dashboard'
      const path = redirectMap[returnKey];
      if (!path) {
        throw new Error('Invalid return key');
      }
      hook.app.set('redirectPath', path);
      return hook;
    }]
  }
});

3) If you must accept full URLs (e.g., for third-party integrations), require a server-side allowlist of domains and use a library to ensure the URL complies with the policy. Do not rely on simple string prefixes like https://trusted.com.

const allowedDomains = new Set(['app.example.com', 'portal.example.com']);
const isValidStrict = (url) => {
  try {
    const parsed = new URL(url);
    return allowedDomains.has(parsed.hostname);
  } catch {
    return false;
  }
};

These fixes ensure that API key authentication and redirect logic are independently secured: the key proves identity, while validation enforces safe navigation. This approach aligns with secure coding practices for OAuth and browser-based redirects, mitigating the risk of open redirects even when API keys are in play.

You can use the middleBrick Web Dashboard or the CLI tool (middlebrick scan <url>) to scan API endpoints that use API keys and redirects. The scanner checks for Open Redirect among the 12 security checks and provides prioritized findings with severity and remediation guidance. The Pro plan enables continuous monitoring and CI/CD integration, so future changes to redirect logic or authentication are automatically tested. You can also run scans directly from your AI coding assistant via the MCP Server.