Open Redirect in Feathersjs with Firestore

An Open Redirect in a Feathersjs application that uses Firestore typically arises when a route accepts a user-controlled URL or host value and then issues a redirect without strict validation. Because Feathersjs is a framework-agnostic layer, developers often add redirect logic in service hooks or custom methods. If those methods read a redirect target from a query parameter or request body and pass it directly to something like res.redirect(target), an attacker can supply a malicious external URL.

Firestore itself does not perform HTTP redirects, but the data stored in Firestore can influence redirect behavior. For example, a client might store a user preference or configuration record in Firestore that includes a redirect URL. If the Feathersjs service retrieves that record and uses the stored URL in a redirect without validating its origin, the stored value becomes a vector. A compromised record or a malicious entry can cause the server to redirect authenticated users to phishing sites, especially if the value is not restricted to same-origin paths or tightly controlled domains.

Additionally, because Feathersjs often serves as an API layer for SPAs or mobile clients, developers may expose a redirect endpoint to handle post-login flows. If the endpoint trusts the client-supplied host or uses string concatenation to build a Location header, an open redirect may be introduced. Attackers can combine this with social engineering by sending links such as https://api.example.com/auth/redirect?url=https://evil.com. The Firestore dependency means that even if the redirect URL is not hardcoded, it can be dynamically loaded from a document, increasing the risk of supply-chain style issues if the data is not rigorously validated.

Common OWASP API Top 10 risks related to this pattern include Broken Object Level Authorization (BOLA) when redirect targets are derived from user-controlled document identifiers, and Improper Neutralization of Components in the Redirect Chain. Because the scan checks Authentication, BOLA/IDOR, and Input Validation in parallel, it can flag cases where a redirect target is both user-influenced and insufficiently constrained.

Remediation focuses on ensuring that any redirect target derived from Firestore data or client input is restricted to a safe set of values. Never directly use a document field as the redirect URL. Instead, map values to known routes or use strict allowlists.

Example of vulnerable code that should be avoided:

// Avoid: directly using a Firestore document field in a redirect
app.service('auth').hooks({
  after: {
    async redirectUser(context) {
      const { userId } = context.params.query;
      const doc = await context.app.service('userSettings').get(userId);
      // Risk: doc.redirectUrl may be malicious or stale
      return { redirectTo: doc.redirectUrl };
    }
  }
});

Secure alternative with explicit allowlist and validation:

const allowedHosts = new Set(['https://app.example.com', 'https://app.example.com/auth']);

app.service('auth').hooks({
  after: {
    async redirectUser(context) {
      const { userId, target } = context.params.query;
      // Validate target against allowed hosts or paths
      let redirectUrl = null;
      if (allowedHosts.has(target)) {
        redirectUrl = target;
      } else {
        // Fallback to a safe default derived from Firestore data, not raw URL
        const doc = await context.app.service('userSettings').get(userId);
        const safePath = doc.preferredPath || '/dashboard';
        redirectUrl = new URL(safePath, 'https://app.example.com').toString();
      }
      // Feathersjs context manipulation or framework-specific response handling
      context.result = { redirectTo: redirectUrl };
      return context.result;
    }
  }
});

When reading from Firestore, treat document fields as data, not as executable control flow for navigation. If a redirect is required, prefer server-side mappings (e.g., mapping document status codes to internal routes) and enforce same-origin policies. For SPAs, use relative paths or route names resolved on the client, keeping the server’s role limited to authorization checks rather than URL composition.

These changes align with the scan’s checks for Input Validation and BOLA/IDOR, ensuring that Firestore-derived values cannot be used to bypass origin restrictions. The scanner will report findings related to unvalidated redirects and will map them to frameworks such as OWASP API Top 10 and relevant compliance standards.