Ssrf Server Side in Fiber with Mongodb

Server-side request forgery (SSRF) in a Fiber application that uses MongoDB can occur when user-controlled input is used to influence network calls or data retrieval patterns that reach backend services, including those that interact with MongoDB. A common pattern is an internal endpoint that accepts a resource identifier, performs an HTTP request to another service to fetch data, and then stores or displays results. If the target URL is derived from user input without strict validation, an attacker can direct the server to an internal MongoDB administrative endpoint, a metadata service (e.g., 169.254.169.254), or other sensitive interfaces.

With MongoDB, SSRF can become more impactful when the Fiber app uses a MongoDB driver to build dynamic queries based on data obtained from an external call. For example, if the app fetches a configuration or a list of allowed databases from an external URL and then uses that data to construct a MongoDB connection string or database/collection name, an attacker may be able to pivot to unauthorized MongoDB instances or trigger operations that expose sensitive data. Even when MongoDB is not directly exposed to the internet, SSRF can allow an attacker to reach internal services that the application server can access, bypassing firewall restrictions.

In a real-world scenario, consider a Fiber route that accepts a URL query parameter to load a remote JSON definition and then uses fields from that JSON to determine which MongoDB collection to query. If the remote URL is controllable and the application does not enforce strict allowlists, an attacker can supply a URL pointing to internal metadata or a malicious service that returns crafted JSON. The application may then use values such as collection names or aggregation stages derived from the attacker-controlled response, leading to unauthorized data access or manipulation. This risk is compounded if the MongoDB connection relies on implicit trust relationships within the host network.

middleBrick detects SSRF by tracing outbound requests initiated by the API and correlating them with observed behaviors, such as unexpected internal IPs or metadata service interactions. When scanning a Fiber API that uses MongoDB, the tool can surface findings that highlight risky input flows and the potential for SSRF-based pivoting toward backend data stores. Remediation focuses on input validation, network segmentation, and minimizing the trust placed in data obtained from external sources.

To mitigate SSRF risks in a Fiber application that interacts with MongoDB, enforce strict allowlists on any user-influenced URLs or hostnames used for external requests. Avoid constructing MongoDB connection strings, database names, or collection names from unvalidated input. Use explicit configuration for MongoDB connections and prefer environment-based configuration over dynamic discovery driven by external data.

Below are concrete code examples for a Fiber application using the official MongoDB Go driver. The safe approach uses a fixed MongoDB client and does not allow user input to alter the target of HTTP requests or the structure of database operations.

// Safe Fiber route: no user-controlled URL for MongoDB targeting
package main

import (
	"context"
	"log"
	"net/http"

	"github.com/gofiber/fiber/v2"
	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
)

func main() {
	// Initialize MongoDB client with a fixed connection string from environment
	client, err := mongo.Connect(context.TODO(), options.Client().ApplyURI("mongodb://fixed-host:27017"))
	if err != nil {
		log.Fatal(err)
	}
	defer client.Disconnect(context.TODO())

	app := fiber.New()

	// Example: a read-only endpoint that queries a known, safe collection
	app.Get("/users/:id", func(c *fiber.Ctx) error {
		id := c.Params("id")
		// Validate id format to prevent NoSQL injection
		if id == "" {
			return c.Status(http.StatusBadRequest).SendString("missing id")
		}
		coll := client.Database("appdb").Collection("users")
		var doc bson.M
		if err := coll.FindOne(c.Context(), bson.M{"_id"}).Decode(&doc); err != nil {
			return c.Status(http.StatusInternalServerError).SendString("error")
		}
		return c.JSON(doc)
	})

	log.Fatal(app.Listen(":3000"))
}

In this example, the MongoDB client is configured with a fixed URI, and no user input influences the target host or database/collection names. The route parameter is strictly validated and used only as a query filter within a predefined collection. This approach prevents SSRF pivots to internal services or metadata endpoints and ensures that even if an attacker can control the request path, they cannot redirect backend network traffic.

Avoid patterns where external URLs are fetched and then used to assemble MongoDB operations, such as using a remote JSON to decide which database to connect to or which host to query. If such functionality is required, implement strict allowlists, timeouts, and network-level controls to isolate backend data stores from user-influenced network paths.