Open Redirect in Fiber with Mongodb

An Open Redirect in a Fiber application that uses MongoDB can occur when user-controlled data from a database is used to construct a redirect response without validation. For example, a route like /login/success might read a user document from MongoDB containing a redirectUrl field and then call res.Redirect(redirectUrl). If the stored URL is attacker-controlled (e.g., compromised or maliciously set in the database), the application can redirect users to arbitrary external sites. This becomes a phishing vector because the redirect appears to originate from a trusted domain.

Consider a user profile endpoint that fetches a document from MongoDB and uses a stored URL for post-login navigation:

// Example: vulnerable use of MongoDB data in a redirect
app.Get("/login/success", func(c *fiber.Ctx) error {
    var user struct {
        RedirectURL string `json:"redirectUrl"`
    }
    collection.FindOne(c.Context(), bson.M{"email": "test@example.com"}).Decode(&user)
    return c.Redirect(user.RedirectURL)
})

If the redirectUrl field in MongoDB contains https://evil.com, the user is redirected there. Because the redirect is triggered from a legitimate Fiber route, users may trust the destination. This pattern is especially risky when combined with authentication flows or referral parameters, and it maps to the OWASP API Top 10 A05:2023-Security Misconfiguration and A01:2023-Broken Access Control when access controls are missing or inconsistent.

middleBrick scans such endpoints and can flag the missing validation on the redirect destination, especially when the destination is derived from database-stored values. The scanner checks whether the response status indicates a redirect and whether the target is user-influenced, highlighting the absence of allowlists or strict validation. This helps surface risks where MongoDB documents supply values used in sensitive operations like redirects.

Additionally, if an application dynamically builds redirect URLs using query parameters that are later stored in MongoDB and reused, the risk compounds. For instance, a parameter ?next=/dashboard might be saved to the database and later used in an unchecked redirect. middleBrick’s checks for Unsafe Consumption and Property Authorization help detect these multi-stage exposures across runtime and specification analysis.

To remediate Open Redirect in Fiber with MongoDB, validate and restrict redirect destinations before using them in c.Redirect. Prefer allowlists of trusted hosts or paths, avoid using raw database fields directly, and normalize inputs to prevent open redirects via encoded or relative paths.

1. Use an allowlist approach with hostname validation. Instead of redirecting to any URL stored in MongoDB, check the host against a known set of domains:

import "net/url"

var allowedHosts = map[string]bool{
    "app.example.com": true,
    "dashboard.example.com": true,
}

app.Get("/login/success", func(c *fiber.Ctx) error {
    var user struct {
        RedirectURL string `json:"redirectUrl"`
    }
    collection.FindOne(c.Context(), bson.M{"email": "test@example.com"}).Decode(&user)

    parsed, err := url.Parse(user.RedirectURL)
    if err != nil || !allowedHosts[parsed.Host] {
        // Fallback to a safe default
        return c.Redirect("/dashboard")
    }
    return c.Redirect(user.RedirectURL)
})

2. Normalize and compare paths when using path-based redirects. If you must redirect within your app, resolve relative paths and ensure the target starts with a safe prefix:

import "path"

app.Get("/files/:id", func(c *fiber.Ctx) error {
    id := c.Params("id")
    var doc struct {
        Path string `json:"path"`
    }
    collection.FindOne(c.Context(), bson.M{"_id": id}).Decode(&doc)

    // Ensure the path is within allowed directory
    clean := path.Clean("/" + doc.Path)
    if clean != doc.Path || clean[:1] != "/" {
        return c.Status(fiber.StatusBadRequest).SendString("invalid path")
    }
    if path.HasPrefix(clean, "/public/") {
        return c.Redirect(clean)
    }
    return c.Redirect("/public/index.html")
})

3. Avoid storing redirect URLs in MongoDB when possible. If you need to store navigation targets, use enum-like values or route names instead of raw URLs, and map them server-side:

app.Get("/login/success", func(c *fiber.Ctx) error {
    var user struct {
        RedirectKey string `json:"redirectKey"`
    }
    collection.FindOne(c.Context(), bson.M{"email": "test@example.com"}).Decode(&user)

    routeMap := map[string]string{
        "dashboard": "/dashboard",
        "profile":   "/user/profile",
    }
    target, ok := routeMap[user.RedirectKey]
    if !ok {
        target = "/dashboard"
    }
    return c.Redirect(target)
})

These patterns ensure that even if MongoDB contains untrusted data, the application does not perform unsafe redirects. middleBrick can verify these fixes by rescanning the endpoints and confirming that redirect destinations are restricted or validated, reducing the risk score and findings related to Open Redirect and Improper Control of Interaction Frequency.