Open Redirect in Adonisjs with Firestore

An open redirect in an AdonisJS application that uses Google Firestore can occur when an endpoint accepts a user-controlled URL or path parameter and uses it directly in a redirect without validation. Firestore is often used to store configuration such as allowed redirect URIs, tenant settings, or campaign landing pages. If an application retrieves a Firestore document containing a redirect target and then performs an HTTP redirect using that value, an attacker can supply a malicious external URL or a scheme such as javascript: to bypass allowlists that are not enforced at the point of use.

For example, an AdonisJS route might read a document from Firestore to determine where to send a user after login. If the document’s redirectUrl field is used without validation, an attacker who can influence which document is retrieved (e.g., via an ID in the request) can cause the application to redirect to any site. This becomes a phishing vector because users may trust the original domain and not inspect the final destination before the redirect occurs.

AdonisJS does not inherently treat Firestore values as safe; any value sourced from Firestore must be treated as untrusted input. Common pitfalls include concatenating user input into Firestore queries that influence redirect targets, or using Firestore-stored URLs in server-side redirects without strict allowlisting against a known set of origins. Even if the Firestore document is edited only by trusted staff, supply-chain or misconfiguration risks can introduce malicious entries, making validation essential.

The combination of AdonisJS routing and Firestore data flow increases risk when developers assume server-side code cannot be manipulated by an attacker. In reality, if an attacker can control which Firestore document is accessed (through IDOR or Insecure Direct Object References) or can inject a malicious URL into a document, the open redirect becomes effective. This aligns with OWASP API Top 10 A05:2023 (Broken Function Level Authorization) and A01:2021 (Broken Access Control), because the API exposes behavior that should be constrained by authorization and strict validation.

Remediation focuses on strict validation of any redirect target, regardless of its source. When using Firestore in AdonisJS, treat stored URLs as configuration data and validate them at read time and at redirect time. Use an allowlist of permitted hosts and enforce absolute URI parsing to prevent scheme abuse.

Below are concrete, realistic code examples for AdonisJS that demonstrate safe handling of Firestore-stored redirect URLs.

import { schema } from '@ioc:Adonis/Core/Validator'
import { DateTime } from 'luxon'
import { Firestore, doc, getDoc } from '@google-cloud/firestore'

const firestore = new Firestore()

// Define a strict schema for Firestore documents that contain redirect targets
const redirectConfigSchema = schema.create({})

export default class RedirectController {
  async executeRedirect({ request, response }) {
    const campaignId = request.param('campaignId')
    const userLocale = request.qs().locale || 'en'

    // Fetch the Firestore document by ID; ensure the ID is validated (e.g., UUID or integer pattern)
    const docRef = doc(firestore, 'redirectConfigs', campaignId)
    const snapshot = await getDoc(docRef)

    if (!snapshot.exists()) {
      return response.badRequest({ error: 'Configuration not found' })
    }

    const data = snapshot.data()

    // Validate the structure; do not trust Firestore field names or presence
    if (typeof data?.targetUrl !== 'string' || !data.enabled) {
      return response.badRequest({ error: 'Invalid configuration' })
    }

    // Parse and strictly validate the URL
    let targetUrl: URL
    try {
      targetUrl = new URL(data.targetUrl)
    } catch (err) {
      return response.badRequest({ error: 'Invalid redirect URL' })
    }

    // Allowlist check: only permit specific hosts and require HTTPS
    const allowedHosts = new Set(['app.example.com', 'marketing.example.com'])
    if (!allowedHosts.has(targetUrl.hostname) || targetUrl.protocol !== 'https:') {
      return response.badRequest({ error: 'Redirect target not permitted' })
    }

    // Optionally enforce a path prefix to avoid open redirects to attacker-controlled paths
    if (!targetUrl.pathname.startsWith('/landing/')) {
      return response.badRequest({ error: 'Redirect path not permitted' })
    }

    // Safe redirect with explicit status and validated URL
    return response.redirect(targetUrl.toString(), 302)
  }
}

In this example, the Firestore document is retrieved using a user-supplied campaignId, but the ID is used only as a document key; the actual redirect target is extracted from the document and validated. The validation steps include type checks, URL parsing, host allowlisting, protocol enforcement, and path prefix checks. This approach ensures that even if a Firestore document contains a malicious URL, the application will reject it before issuing a redirect.

Additionally, consider storing only relative paths or safe identifiers in Firestore and mapping them to full URLs server-side. This reduces the attack surface by removing raw URLs from the data store entirely. Combine this with runtime monitoring of redirect patterns to detect anomalies that may indicate abuse or misconfiguration.