Open Redirect in Fiber with Firestore

An open redirect in a Fiber application that uses Firestore typically occurs when an endpoint accepts a user-controlled URL or path parameter and then redirects the client to that value without strict validation. If the application retrieves additional data from Firestore based on an identifier provided in the same request, an attacker can supply a malicious external URL while the server still queries Firestore, creating a scenario where data access and redirection are unintentionally coupled.

Consider a profile endpoint that reads a user document from Firestore using an ID provided in the query string and then redirects to a stored URI field. If the redirect target is not validated independently of the Firestore lookup, an attacker can manipulate the target parameter to point to a phishing site while the server still performs the authorized Firestore read. This pattern is risky because it can expose internal logic and make the redirect appear legitimate due to the prior data access step.

In a black-box scan, middleBrick tests unauthenticated endpoints that accept URL or query parameters and perform redirects. It checks whether the redirect location can be influenced by user input and whether input is validated against a strict allowlist. For endpoints that combine Firestore reads with redirects, middleBrick flags cases where the redirect target is derived from user input without canonicalization or strict allowlisting, even when the Firestore lookup itself is benign.

Because Firestore returns structured data, developers sometimes use a document field as the redirect destination. If that field is user-writable or not validated, the stored value can become an open redirect vector. MiddleBrick’s checks include verifying that redirects do not depend on external inputs without strict validation, and that Firestore-based data retrieval does not implicitly endorse unsafe redirection behavior.

To remediate open redirect issues in a Fiber application that interacts with Firestore, ensure that redirect targets are never directly taken from Firestore fields or user input without strict validation. Use an allowlist of trusted paths or domains, and resolve dynamic destinations on the server side rather than storing raw redirect URLs in Firestore.

The following example shows a vulnerable endpoint and a corrected implementation in Go using the Fiber framework and the Firestore Go SDK.

// Vulnerable example: redirect target taken directly from Firestore
app.Get("/profile-vulnerable", func(c *fiber.Ctx) error {
    userID := c.Query("user_id")
    client := firestore.NewClient(context.Background(), "my-project")
    defer client.Close()

    doc, err := client.Collection("users").Doc(userID).Get(context.Background())
    if err != nil {
        return c.Status(fiber.StatusBadRequest).SendString("invalid user")
    }
    data := doc.Data()
    redirectURL, ok := data["redirect_url"].(string)
    if !ok || redirectURL == "" {
        return c.Status(fiber.StatusBadRequest).SendString("missing url")
    }
    return c.Redirect(redirectURL)
})

// Secure example: resolve redirect server-side using an allowlist
app.Get("/profile-safe", func(c *fiber.Ctx) error {
    userID := c.Query("user_id")
    client := firestore.NewClient(context.Background(), "my-project")
    defer client.Close()

    doc, err := client.Collection("users").Doc(userID).Get(context.Background())
    if err != nil {
        return c.Status(fiber.StatusBadRequest).SendString("invalid user")
    }
    data := doc.Data()
    profileType, ok := data["profile_type"].(string)
    if !ok {
        return c.Status(fiber.StatusBadRequest).SendString("missing type")
    }

    // Server-side mapping instead of trusting Firestore-stored URLs
    var target string
    switch profileType {
    case "personal":
        target = "/user/personal"
    case "business":
        target = "/user/business"
    default:
        return c.Status(fiber.StatusBadRequest).SendString("unknown profile")
    }
    return c.Redirect(target)
})

In the secure version, the Firestore document contains a controlled profile_type field, and the redirect target is determined by the server using a strict switch statement. This prevents user-influenced URLs from reaching the redirect logic. If you must store destination paths, validate them against a strict regex allowlist and canonicalize before use, but prefer mapping values to internal routes.

middleBrick can detect open redirect patterns by analyzing endpoint behavior and input flows. When integrating the CLI (middlebrick scan <url>) or the GitHub Action to fail builds on risky scores, you can catch such issues before deployment. The MCP Server allows AI coding assistants to trigger scans directly from your IDE, supporting rapid feedback during development.