Excessive Data Exposure in Echo Go with Cockroachdb

Excessive Data Exposure occurs when an API returns more data than necessary for a given operation, and the Echo Go framework combined with Cockroachdb can unintentionally amplify this risk. When building HTTP APIs with Echo Go, developers often map database rows directly into JSON responses. If query construction does not explicitly limit returned columns or rows, the API can expose sensitive fields such as internal IDs, hashed credentials, audit timestamps, or PII stored in the Cockroachdb schema.

With Cockroachdb, a distributed SQL database, this risk is tied to how queries are formed and how results are serialized. For example, a route like /users/{id} might run a SELECT * against a Cockroachdb table that contains columns such as password_hash, email, created_at, and internal_role. Returning all columns without filtering results in over-exposure. In distributed setups, Cockroachdb may also return additional metadata in certain driver modes, and if the Go SQL layer does not explicitly select only needed columns, that extra data can be reflected in API responses.

The Echo Go route handlers often bind path or query parameters directly into SQL queries without strict column whitelisting. If input validation is missing, an attacker can manipulate parameters to trigger broader scans or force joins that pull in unrelated sensitive rows. Because Echo Go does not enforce schema-level output controls, the developer must explicitly design handlers to limit both row selection and column projection. Without these controls, the API surface includes unnecessary data that should never leave the database boundary.

Another contributing factor is the use of generic structs or maps to unmarshal Cockroachdb rows. If a struct contains exported fields for all possible columns, and the handler writes the full struct to JSON, sensitive fields are included by default. Even when using SELECT with specific columns, mismatches between struct fields and selected columns can cause leakage through reflection or through logging if the driver or Echo Go middleware dumps responses for debugging.

MiddleBrick detects this pattern by correlating OpenAPI/Swagger definitions with runtime responses. If the spec documents a subset of fields but the actual response contains additional sensitive fields from Cockroachdb, the scan flags Excessive Data Exposure. This check is part of the 12 parallel security checks, emphasizing that API contracts must match implemented data exposure, especially when the backend uses strongly typed databases like Cockroachdb.

Remediation focuses on explicit column selection, strict struct scoping, and disciplined handler design. Avoid SELECT * and instead list only required columns. Define structs that match only the intended subset of data, and ensure JSON tags align with the fields you intend to expose.

Example of a vulnerable pattern:

// Vulnerable: SELECT * exposes all columns including sensitive ones
type User struct {
    ID           int    `json:"id"`
    Email        string `json:"email"`
    PasswordHash string `json:"-"`
    Role         string `json:"role"`
}

func getUser(c echo.Context) error {
    id := c.Param("id")
    var user User
    // Direct mapping without column filtering
    err := db.Get(&user, "SELECT * FROM users WHERE id = $1", id)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError)
    }
    return c.JSON(http.StatusOK, user)
}

Secure alternative with explicit column selection and a scoped struct:

// Secure: explicit columns and a struct that matches intended output
type PublicUser struct {
    ID    int    `json:"id"`
    Email string `json:"email"`
}

func getPublicUser(c echo.Context) error {
    id := c.Param("id")
    var pubUser PublicUser
    // Select only necessary columns
    err := db.Get(&pubUser, "SELECT id, email FROM users WHERE id = $1", id)
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound, "user not found")
    }
    return c.JSON(http.StatusOK, pubUser)
}

When working with joins or more complex queries, define a dedicated view struct and use column aliases to ensure field names are predictable and sensitive columns are omitted:

// Secure: complex query with controlled output
type UserProfile struct {
    UserID   int    `json:"user_id"`
    Username string `json:"username"`
    OrgName  string `json:"org_name"`
}

func getUserProfile(c echo.Context) error {
    id := c.Param("id")
    var profile UserProfile
    // Explicit join and column selection
    query := `
        SELECT u.id AS user_id, u.username, o.name AS org_name
        FROM users u
        JOIN organizations o ON u.org_id = o.id
        WHERE u.id = $1`
    err := db.Get(&profile, query, id)
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound)
    }
    return c.JSON(http.StatusOK, profile)
}

Additionally, configure the Cockroachdb driver and Echo Go middleware to suppress verbose error details that might leak schema information. Use structured logging that excludes raw query results, and validate all path and query parameters against expected formats before constructing SQL statements. These practices reduce the chance of accidental data exposure and align API responses with the principle of least privilege in data disclosure.