Data Exposure in Fiber with Api Keys

The Data Exposure check in middleBrick assesses whether sensitive information such as API keys, secrets, or personal data can be unintentionally returned to clients. When combined with a Fiber-based API that mishandles API keys, this creates a risk where privileged credentials or internal data are exposed through HTTP responses.

Fiber is a fast, extensible web framework for Go. In practice, developers sometimes attach API key values to request contexts, headers, or route parameters for authorization, and then inadvertently serialize or log those values in responses. For example, returning a structure that contains an API key field—either directly or through a nested struct—can leak the key if the response is not carefully filtered.

Consider a handler that echoes metadata for debugging or health-check endpoints:

package main

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

type StatusResponse struct {
	Message string `json:"message"`
	APIKey  string `json:"api_key"`
}

func main() {
	app := fiber.New()

	app.Get("/health", func(c *fiber.Ctx) error {
		// Dangerous: API key exposed in response
		apiKey := c.Get("X-API-Key")
		resp := StatusResponse{
			Message: "OK",
			APIKey:  apiKey,
		}
		return c.JSON(resp)
	})

	app.Listen(":3000")
}

In this pattern, if a client sends X-API-Key as a request header, the handler copies it into the JSON response. A scan that traces response payloads can detect that an API key is being returned, which qualifies as a data exposure finding. The same risk applies when API keys are stored in structs that are serialized automatically, or when they are included in log entries that are surfaced through error handlers or debug routes.

middleBrick detects such exposures by analyzing endpoint outputs and comparing them against known sensitive patterns, including API key formats and secrets. In a scan of a Fiber service with this behavior, the Data Exposure check would surface a high-severity finding, noting that an API key is reflected in the response body without necessity. This aligns with the broader Data Exposure category in the OWASP API Top 10, emphasizing the need to minimize the data returned by an endpoint and to avoid reflecting sensitive values.

Additionally, middleware that logs request details can inadvertently record API keys if developers include the full context or headers in log statements. These logs, if accessible through error reporting or monitoring interfaces, contribute to the data exposure surface. middleBrick’s cross-referencing of spec definitions with runtime outputs helps highlight these gaps by identifying mismatches between declared behavior and actual responses.

To remediate data exposure involving API keys in Fiber, ensure that API keys are used strictly for authentication and are never reflected in responses or logs. Refactor handlers to avoid copying sensitive header values into serializable structures, and sanitize any data that may be returned to the client.

The following example demonstrates a safe approach. Instead of echoing the API key, use it only to validate access and return a sanitized response:

package main

import (
	"errors"
	"github.com/gofiber/fiber/v2"
)

type StatusResponse struct {
	Message string `json:"message"`
}

var validKey = "super-secret-key-123"

func authenticate(c *fiber.Ctx) error {
	apiKey := c.Get("X-API-Key")
	if apiKey != validKey {
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{
			"error": "unauthorized",
		})
	}
	return c.Next()
}

func main() {
	app := fiber.New()

	app.Use("/secure", authenticate)

	app.Get("/secure/data", func(c *fiber.Ctx) error {
		// Safe: API key is not included in the response
		return c.JSON(StatusResponse{
			Message: "Authenticated data",
		})
	})

	app.Get("/health", func(c *fiber.Ctx) error {
		// Safe: No sensitive values in response
		return c.JSON(StatusResponse{
			Message: "OK",
		})
	})

	app.Listen(":3000")
}

For logging, avoid printing the full header map or the API key value. If you must record request identifiers, generate a non-sensitive correlation ID instead:

package main

import (
	"log"
	"github.com/gofiber/fiber/v2"
	"github.com/google/uuid"
)

func loggingMiddleware(c *fiber.Ctx) error {
	correlationID := uuid.New().String()
	c.Locals("correlationID", correlationID)
	log.Printf("[%s] Incoming request: %s %s", correlationID, c.Method(), c.Path())
	return c.Next()
}

By applying these patterns, the Data Exposure check in middleBrick should no longer flag API keys in responses. The CLI tool can be used to verify changes locally:

$ middlebrick scan https://your-api.example.com

For teams integrating security into delivery pipelines, the GitHub Action can enforce a maximum score threshold, ensuring that builds fail if a high-severity Data Exposure finding is detected. This supports continuous monitoring without requiring manual review on every commit.