Ssrf Server Side in Fiber with Api Keys

Server Side Request Forgery (SSRF) in a Fiber application becomes significantly riskier when API keys are used for outbound calls. Because Fiber is a fast HTTP framework for Go, developers often add an API key header to authorize requests to downstream services. If an attacker can influence the target URL of an outbound HTTP request and the application attaches the same API key header, the key can be relayed to an unintended internal or third-party endpoint. This can expose the key to internal metadata services or cause the application to perform unintended actions on behalf of the service that owns the key.

In a black-box scan, middleBrick tests SSRF by attempting to direct outbound requests to internal IPs, cloud metadata endpoints (e.g., 169.254.169.254), and other sensitive internal namespaces. When API keys are present in headers, the scan checks whether those keys are reflected or accepted by the probed endpoints. Even when the API key is not accepted as a credential, SSRF can lead to server-side interactions that violate network segmentation and allow an attacker to infer internal topology or trigger side effects via the trusted identity of the key.

Because Fiber gives developers fine-grained control over middleware and request handling, it is common to see patterns where a route accepts a URL parameter that is directly used in an HTTP client call with an API key. If input validation is weak, an attacker can supply a malicious URL, causing the server to make authenticated requests to internal services. middleBrick’s 12 checks run in parallel and include SSRF among its security scans, testing for these patterns without requiring authentication or source code access.

For example, a vulnerable Fiber handler might look like this, showing how an API key header is attached based on an unchecked user-supplied URL:

package main

import (
	"fmt"
	"net/http"
	"github.com/gofiber/fiber/v2"
	"net/http/httputil"
)

func vulnerableProxy(c *fiber.Ctx) error {
	url := c.Query("url")
	req, _ := http.NewRequest("GET", url, nil)
	req.Header.Set("Authorization", "Bearer YOUR_API_KEY")
	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		return c.SendStatus(http.StatusBadRequest)
	}
	defer resp.Body.Close()
	dump, _ := httputil.DumpResponse(resp, true)
	return c.Send(dump)
}

func main() {
	app := fiber.New()
	app.Get("/proxy", vulnerableProxy)
	app.Listen(":3000")
}

In this pattern, the API key is static, but the target URL is not validated. A scan from middleBrick would flag this as SSRF and note that the API key header is being sent to arbitrary destinations, which may expose the key or allow interaction with internal services. Remediation typically involves strict allowlisting of hostnames or using outbound proxy patterns with strict network controls.

middleBrick’s OpenAPI/Swagger analysis helps identify such risky integrations by correlating spec definitions that include security schemes like API keys with operations that invoke external calls. When combined with runtime findings, this correlation clarifies where authenticated outbound requests are made and highlights the need for tighter controls.

To reduce SSRF risk when using API keys in Fiber, ensure that any user-influenced URL is strictly validated before being used in an HTTP client call. Do not rely on the API key alone to protect internal endpoints; instead, prevent the request from reaching unintended hosts. Below are concrete, safe patterns that you can adopt in your Fiber application.

First, validate and restrict the destination host using an allowlist. This ensures that even if an attacker provides a malicious URL, the request can only go to approved domains or internal services that are explicitly permitted.

package main

import (
	"fmt"
	"net/http"
	"net/url"
	"strings"

	"github.com/gofiber/fiber/v2"
)

var allowedHosts = map[string]bool{
	"api.example.com": true,
	"internal.service": true,
}

func safeProxy(c *fiber.Ctx) error {
	rawURL := c.Query("url")
	parsed, err := url.Parse(rawURL)
	if err != nil || !allowedHosts[parsed.Host] {
		return c.Status(http.StatusBadRequest).SendString("invalid target")
	}
	req, _ := http.NewRequest("GET", parsed.String(), nil)
	req.Header.Set("Authorization", "Bearer YOUR_API_KEY")
	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		return c.SendStatus(http.StatusBadRequest)
	}
	defer resp.Body.Close()
	// handle response safely
	return c.SendStatus(http.StatusOK)
}

func main() {
	app := fiber.New()
	app.Get("/proxy", safeProxy)
	app.Listen(":3000")
}

Second, avoid placing API keys in query parameters or in locations that might be logged. Keep keys in environment variables and ensure that outbound requests do not inadvertently echo user input into logs or responses. The following example shows how to read the key from the environment and avoid including raw user input in sensitive headers.

package main

import (
	"os"

	"github.com/gofiber/fiber/v2"
)

func handlerWithEnvKey(c *fiber.Ctx) error {
	apiKey := os.Getenv("OUTBOUND_API_KEY")
	if apiKey == "" {
		return c.Status(http.StatusInternalServerError).SendString("server misconfiguration")
	}
	// Use a validated target as shown in the previous example
	// ... perform request with apiKey header
	return c.SendString("ok")
}

func main() {
	app := fiber.New()
	app.Get("/safe", handlerWithEnvKey)
	app.Listen(":3000")
}

For larger integrations, consider using a dedicated HTTP client with timeouts and transport-level controls. This approach complements API key protection by reducing the blast radius of any misrouted request. middleBrick’s GitHub Action can be added to CI/CD pipelines to automatically detect insecure patterns like unchecked URL parameters and missing host allowlists before deployment.