Excessive Data Exposure in Chi with Cockroachdb

Excessive Data Exposure occurs when an API returns more data than the client needs, often including sensitive fields that should remain restricted. In Chi, a common pattern is to define a high-level struct that maps closely to your Cockroachdb rows and then serialize it directly in HTTP responses. Because Cockroachdb is often used as a durable store for relational data, developers sometimes expose entire database rows—including internal IDs, timestamps, foreign keys, or computed fields—without considering which fields are safe for the client. This risk increases when route parameters such as IDs are reflected in queries without strict field selection, leading to endpoints that return complete domain objects rather than tailored representations.

For example, consider a Chi route that fetches a user by ID from a Cockroachdb table and returns the full row:

// Chi handler that returns full Cockroachdb row (potential exposure)
func getUserHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        id := chi.URLParam(r, "id")
        row := db.QueryRow("SELECT id, email, password_hash, role, created_at, metadata FROM users WHERE id = $1", id)
        var u User
        if err := row.Scan(&u.ID, &u.Email, &u.PasswordHash, &u.Role, &u.CreatedAt, &u.Metadata); err != nil {
            http.Error(w, "not found", http.StatusNotFound)
            return
        }
        JSON(w, u, http.StatusOK)
    }
}

In this snippet, fields such as password_hash, role, and metadata may be sensitive and unnecessary for the client. Because the handler directly maps database columns to the response struct, any field present in the row can unintentionally leak. With Cockroachdb, schemas often include system columns or secondary indexes that are not explicitly selected but can be exposed if the query is broadened later (e.g., via dynamic SQL or ORM auto-fetching). The exposure is not limited to authentication secrets; it can also include internal business identifiers or timestamps that aid reconnaissance. The risk is compounded when APIs are explored automatically by tools that inspect OpenAPI specs and runtime behavior, as they may reveal which fields exist and how they are used. Additionally, if the API supports filtering or expanding fields via query parameters, missing validation can allow attackers to request more data than intended, effectively turning the endpoint into an inadvertent data dump.

To understand the impact within the context of an automated scan, middleBrick runs checks that compare declared response schemas (often inferred from route handlers or spec definitions) with the actual data observed during black-box testing. When responses include fields that are not documented or are considered sensitive per category definitions, a finding is generated with severity and remediation guidance. This is especially relevant for endpoints backed by Cockroachdb where row structures can be complex and nested. The scanner does not modify code or block requests; it surfaces the discrepancy so developers can adjust serialization to return only necessary data, such as creating dedicated view models or using selective projection queries.

Addressing Excessive Data Exposure requires deliberate schema and handler design. Instead of returning full domain objects, define response structs that contain only public, non-sensitive fields. Use explicit SQL column lists that omit secrets, and avoid ORM behaviors that eagerly load sensitive relations. When integrating with the middleBrick CLI, you can scan a Chi endpoint to see whether reported findings align with your intended data exposure surface. The dashboard and GitHub Action integrations can then track changes over time and fail builds if new sensitive fields appear in responses, helping maintain a controlled API surface without relying on runtime blocking or firewall rules.

Remediation focuses on strict field selection and separation of concerns between persistence and presentation. In Chi, this means crafting handlers that query only the columns required for the operation and map them to dedicated response structs. Cockroachdb supports standard SQL projection, so you can explicitly list the columns you need and avoid returning internal metadata or authentication-sensitive data by default.

Here is a secure version of the previous handler that selects only safe fields:

// Secure Chi handler with limited column selection
func getUserHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        id := chi.URLParam(r, "id")
        // Select only necessary, non-sensitive columns
        row := db.QueryRow("SELECT id, email, display_name FROM users WHERE id = $1", id)
        var u PublicUser
        if err := row.Scan(&u.ID, &u.Email, &u.DisplayName); err != nil {
            http.Error(w, "not found", http.StatusNotFound)
            return
        }
        JSON(w, u, http.StatusOK)
    }
}

type PublicUser struct {
    ID          string `json:"id"`
    Email       string `json:"email"`
    DisplayName string `json:"display_name"`
}

This approach ensures that even if the underlying Cockroachdb table contains additional columns, they are not serialized into the HTTP response. You can further reduce risk by using view models that flatten or transform data specifically for the API contract, rather than reusing database structs. For nested relations, prefer explicit joins with selected columns instead of automatic preloading, which might expose hidden fields.

When using an ORM or query builder, configure it to exclude sensitive columns by default and only include them in administrative contexts. With the middleBrick CLI, you can verify that responses do not contain fields like password_hash or internal flags. The GitHub Action integration allows you to enforce that new endpoints adhere to these patterns, failing builds when responses deviate from expected schemas. On the MCP Server, you can scan APIs directly from your AI coding assistant to catch excessive exposure as you develop, keeping remediation close to the source of the data access logic.

Finally, coordinate schema changes with your database team to ensure column-level permissions in Cockroachdb restrict unnecessary access. While middleBrick does not fix or block, it provides clear remediation guidance and maps findings to frameworks such as OWASP API Top 10 to help prioritize changes effectively.