Api Key Exposure in Fiber with Postgresql

When building APIs with Fiber and storing application secrets in Postgresql, developers can inadvertently expose API keys through insecure handling of database credentials and connection strings. Because Fiber is a fast Express-compatible web framework for Go, it often uses environment variables for configuration, which may be read at runtime and passed to Postgresql connections via connection strings constructed in code or configuration files.

If the connection string or derived credentials are logged, exposed in error messages, or stored in source control, an API key used to authenticate to Postgresql can be revealed. This exposure becomes critical when the same key is used across services or when the Postgresql instance is reachable from untrusted networks. middleBrick detects scenarios where unauthenticated or improperly authenticated endpoints return database connection details or where configuration endpoints leak credentials through verbose error responses.

For example, concatenating user input directly into a Postgresql DSN in a Fiber handler can lead to injection and information disclosure. Consider a route that builds a connection string from request parameters without validation:

// Unsafe: concatenating user input into a Postgresql DSN in Fiber
app.Get("/db", func(c *fiber.Ctx) error {
    dbname := c.Query("db")
    dsn := fmt.Sprintf("host=localhost user=apikey password=%s dbname=%s sslmode=disable", os.Getenv("DB_PASSWORD"), dbname)
    db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).SendString(err.Error())
    }
    return c.SendString("connected")
})

In this pattern, if an attacker can control the db query parameter and the application returns detailed errors, they may learn the password or infer the API key used by the service to authenticate to Postgresql. middleBrick’s checks for Data Exposure and Unsafe Consumption identify such patterns, flagging insecure credential handling and over-broad error messages that disclose sensitive information.

Additionally, if the API key is embedded in the application binary or configuration files that are served by the Fiber application (for example, through a debug or health endpoint), middleBrick’s Property Authorization and Data Exposure checks can detect publicly accessible endpoints that should not return secrets. The scanner also examines the OpenAPI spec for paths that expose configuration or introspection data, cross-referencing runtime findings to highlight mismatches between declared and actual behavior.

Because scanning is black-box and unauthenticated, middleBrick can surface these risks without access to source code, focusing on what an external attacker can observe: error messages, endpoint responses, and inferred connection behavior. This is especially important when Postgresql is used as a backend for authentication or session storage, and the API key must remain confidential to preserve trust in the API.

To prevent API key exposure when using Fiber with Postgresql, apply strict separation between configuration and request handling, and avoid constructing connection strings from untrusted input. Use environment variables for secrets, validate all inputs, and ensure error messages do not leak credentials or internal details.

First, load the database password from environment variables and construct the DSN outside of request handling. Keep sensitive values out of logs and error responses:

// Secure: load secrets once and avoid logging them
import (
    "fmt"
    "github.com/gofiber/fiber/v2"
    "github.com/jackc/pgx/v5/pgxpool"
    "os"
)

func main() {
    app := fiber.New()
    dbPassword := os.Getenv("DB_PASSWORD")
    if dbPassword == "" {
        panic("DB_PASSWORD environment variable not set")
    }
    baseDSN := fmt.Sprintf("host=localhost user=apikey password=%s dbname=appdb sslmode=require", dbPassword)
    pool, err := pgxpool.New(app.Context(), baseDSN)
    if err != nil {
        app.Logger().Error("failed to connect to postgres")
        app.StatusCode(fiber.StatusInternalServerError).SendString("service unavailable")
        return
    }
    defer pool.Close()

    app.Get("/data", func(c *fiber.Ctx) error {
        // Use parameterized queries and avoid exposing connection details
        var result string
        row := pool.QueryRow(c.Context(), "SELECT value FROM config WHERE key = $1", c.Query("key"))
        if err := row.Scan(&result); err != nil {
            c.Logger().Error(err)
            return c.Status(fiber.StatusInternalServerError).SendString("internal error")
        }
        return c.JSON(fiber.Map{"value": result})
    })

    app.Listen(":3000")
}

Second, enforce input validation and use strict query parameter rules. Do not allow dynamic database or schema names derived from user input. If you must support multi-tenancy, map tenant identifiers to predefined, validated values rather than concatenating them into connection strings.

Third, configure Postgresql to require TLS and use role-based access control so that even if an API key is exposed, the blast radius is limited. Define roles with least privilege and avoid using a superuser role for the application:

-- Postgresql role setup example
CREATE ROLE app_user WITH LOGIN PASSWORD 'strong_password' NOINHERIT;
GRANT CONNECT ON DATABASE appdb TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT ON TABLE config TO app_user;
REVOKE ALL ON DATABASE postgres FROM app_user;

Finally, audit your OpenAPI spec and route definitions to ensure no endpoint exposes configuration, health checks that return sensitive context, or debug pages that could reveal the API key. middleBrick’s OpenAPI/Swagger analysis helps identify such risky endpoints, and its findings align with OWASP API Top 10 and relevant compliance mappings to guide remediation.