Open Redirect in Loopback with Firestore

An open redirect in a Loopback application that uses Firestore can emerge when an endpoint accepts a user-controlled destination (e.g., a next or return URL) and uses Firestore data to influence the redirect path. If the application constructs a redirect URL by concatenating a Firestore document field (such as a stored URI or a user-supplied alias) without strict validation, an attacker can supply a malicious URL that bypasses intended routing logic.

Consider a profile page that reads a custom redirect_uri from a Firestore document and redirects the client. If the server trusts the stored field and does not enforce an allowlist of safe hosts, an attacker who can write or influence a Firestore document (via compromised credentials or a misconfigured rule) can plant a malicious URI. When an authenticated user visits the profile endpoint, the application follows the attacker-supplied location, effectively turning the trusted Firestore read into an open redirect vector.

In a black-box scan, middleBrick tests this by probing endpoints that accept a location parameter, then checking whether the response performs a 3xx redirect to a user-controlled host. With OpenAPI/Swagger spec analysis, middleBrick correlates the spec definition of parameters (e.g., next_url) against runtime behavior. If the spec lacks strict validation and the implementation directly uses Firestore document fields to build the Location header, middleBrick flags this as a high-severity finding under BFLA/Privilege Escalation and Property Authorization checks, noting the absence of host allowlisting and input validation.

Even when Firestore is used only to look up identifiers (e.g., username to profile path), an open redirect can occur if the resolved path is concatenated with a user-provided base. For example, an attacker might register a username that contains a malicious prefix and rely on downstream concatenation to produce a redirect to an external site. middleBrick’s checks for Input Validation and Property Authorization highlight missing constraints on string inputs that ultimately form redirect targets.

Because this pattern combines Loopback routing behavior, Firestore document reads, and dynamic URL construction, the resulting exposure can be non-obvious in code review. A scan with middleBrick’s 12 parallel checks, including its LLM/AI Security probes, helps surface subtle misconfigurations that standard testing might miss, providing prioritized findings and remediation guidance mapped to frameworks such as OWASP API Top 10.

Remediation focuses on strict validation and separation of data from routing decisions. Never use raw Firestore document fields to construct redirect URLs. Instead, map Firestore identifiers to predefined, server-side routes and enforce an allowlist of permitted redirect targets.

Example: a user profile endpoint that previously read a redirect_uri field from Firestore and redirected directly:

const {inject} = require('loopback-context');
const {getFirestore} = require('@google-cloud/firestore');
const db = getFirestore();

module.exports = function(UserProfile) {
  UserProfile.redirectToExternal = async function(userId, incoming) {
    const doc = await db.collection('profiles').doc(userId).get();
    if (!doc.exists) throw new Error('not_found');
    const data = doc.data();
    // Unsafe: using Firestore-supplied URI
    const target = data.redirect_uri || '/default';
    return {redirect: target};
  };
};

Fixed version with allowlist and normalization:

const {inject} = require('loopback-context');
const {getFirestore} = require('@google-cloud/firestore');
const db = getFirestore();

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

module.exports = function(UserProfile) {
  UserProfile.redirectToExternal = async function(userId, incoming) {
    const doc = await db.collection('profiles').doc(userId).get();
    if (!doc.exists) throw new Error('not_found');
    const data = doc.data();
    // Safe: resolve a local route key, then map to an absolute URL
    const routeKey = data.redirect_key || 'home';
    const path = resolveRoute(routeKey); // application-specific mapping
    const target = new URL(path, 'https://app.example.com');
    // Enforce host allowlist
    if (!ALLOWED_HOSTS.has(target.hostname)) {
      throw new Error('disallowed_redirect');
    }
    return {redirect: target.toString()};
  };

  function resolveRoute(key) {
    const map = {
      home: '/dashboard',
      settings: '/settings',
      reports: '/reports/list',
    };
    return map[key] || '/dashboard';
  }
};

Key practices:

• Do not concatenate user input or Firestore fields directly into redirect URLs.
• Use an allowlist for hostnames or exact paths; normalize and parse URLs before comparison.
• Treat Firestore fields as data, not as authority for navigation decisions.
• Apply strict input validation on any parameter that influences routing, and prefer server-side route mappings.

middleBrick’s scans can verify that endpoints no longer reflect untrusted hosts in Location headers and that validation logic is present, supporting compliance mappings to OWASP API Top 10 and related standards.