Information Disclosure in Fiber with Cockroachdb

Information Disclosure occurs when a web application unintentionally exposes sensitive data to an attacker. In a Fiber application using Cockroachdb as the backend, this risk often arises from improper error handling, verbose logging of query results, or returning full database records in HTTP responses. Because Fiber is a fast, unopinionated framework, developers must explicitly control what data is serialized and sent to the client.

When a Cockroachdb driver returns detailed error messages or rows containing sensitive columns (such as email, password_hash, or internal identifiers), a Fiber handler that forwards these directly to the client can leak information. For example, if a handler executes a query like SELECT * FROM users WHERE id = $1 and sends the entire row as JSON, an attacker who can manipulate the ID may learn whether specific users exist, enumerate internal IDs, or see private fields. This becomes more pronounced when error responses include stack traces or query details, which may reveal schema information useful for further attacks such as BOLA or IDOR.

Additionally, if the application reuses database connections or configurations across environments without proper isolation, debug endpoints or verbose logging may expose connection strings or internal hostnames. An OpenAPI spec that includes examples with real-looking sensitive data can also contribute to accidental disclosure if generated client libraries or documentation are publicly accessible. The scanner’s Data Exposure and Inventory Management checks are designed to detect such risky patterns by correlating runtime responses with OpenAPI/Swagger definitions, including full $ref resolution, to identify discrepancies and overly permissive schemas.

In a black-box scan, middleBrick tests unauthenticated endpoints to see whether responses contain indicators of internal infrastructure, such as Cockroachdb-specific error text, database version strings, or stack traces. Findings may highlight missing input validation, missing rate limiting, or unsafe consumption patterns that could lead to data exposure. These checks map to real attack patterns described in the OWASP API Top 10 and can reference compliance frameworks such as PCI-DSS and SOC2 when relevant.

Developers should treat every HTTP response as potentially public and ensure that only necessary data is returned. This includes carefully constructing JSON payloads, suppressing verbose errors in production, and validating that OpenAPI specs do not embed sensitive examples. Tools like the middleBrick Web Dashboard can help track these issues over time, while the CLI allows quick scans from the terminal to surface findings early in development.

To mitigate Information Disclosure when using Cockroachdb with Fiber, focus on strict error handling, minimal data exposure, and secure query patterns. Below are concrete, realistic code examples that demonstrate safe practices.

1. Use parameterized queries and select only required fields

Avoid SELECT * and always project only the fields you need. This reduces the chance of exposing sensitive columns.

// Good: select only necessary fields
const getUserQuery = `SELECT id, username, email_verified FROM users WHERE id = $1`
var result struct {
    ID                int    `json:"id"`
    Username          string `json:"username"`
    EmailVerified     bool   `json:"email_verified"`
}
err := db.QueryRow(context.Background(), getUserQuery, userID).Scan(&result.ID, &result.Username, &result.EmailVerified)
if err != nil {
    // Handle error without exposing details
    c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "unable to fetch user"})
    return
}
c.JSON(result)

2. Sanitize errors and avoid leaking database details

Do not return raw Cockroachdb errors to the client. Log them internally and return generic messages.

import (
    "log"
    "github.com/gofiber/fiber/v2"
    "github.com/lib/pq"
)

func safeHandler(c *fiber.Ctx) error {
    var row struct{ Email string }
    err := db.QueryRow(c.Context(), "SELECT email FROM users WHERE id = $1", c.Params("id")).Scan(&row.Email)
    if err != nil {
        if errors.Is(err, pq.ErrNoRows) {
            return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "not found"})
        }
        // Log the detailed error for debugging, but do not expose it
        log.Printf("db query error: %v", err)
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
    }
    return c.JSON(fiber.Map{"email": row.Email})
}

3. Validate and sanitize inputs to prevent IDOR and BOLA

Ensure that the requesting user is authorized to access the requested resource. Do not rely on obscurity of identifiers.

func getOwnProfile(c *fiber.Ctx) error {
    userID := c.Locals("userID").(int) // authenticated user ID from middleware
    requestedID := c.Params("id")
    if strconv.Itoa(userID) != requestedID {
        return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "access denied"})
    }
    var profile Profile
    err := db.QueryRow(c.Context(), "SELECT id, name, email FROM profiles WHERE user_id = $1", userID).Scan(&profile.ID, &profile.Name, &profile.Email)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "unable to fetch profile"})
    }
    return c.JSON(profile)
}

4. Secure OpenAPI/Swagger specs and avoid sensitive examples

When generating specs for endpoints that involve Cockroachdb, ensure examples do not contain real user data. Use synthetic values and mark sensitive fields as not required in examples.

// Example in Go using a comment-based generator or manual spec review:
// GET /users/{id}
// Responses:
//   200: { "id": 123, "username": "alice", "email_verified": true }
//   404: { "error": "not found" }

By combining these patterns, you reduce the risk of Information Disclosure and ensure that even if an endpoint is exercised by an unauthenticated scan, no sensitive Cockroachdb details are exposed. middleBrick findings related to Data Exposure and Inventory Management can guide further refinements, and the Pro plan’s continuous monitoring can help detect regressions across schema changes.