Data Exposure in Echo Go with Cockroachdb

When building a Go API with the Echo framework that connects to Cockroachdb, data exposure risks arise from how query results are handled, iterated, and serialized. Data exposure occurs when sensitive fields—such as internal IDs, emails, or password hashes—are returned in API responses without appropriate filtering or field-level controls. In Echo, this typically manifests in handler code that scans rows into broad structs or maps and then returns the full struct via JSON serialization.

Using the standard database/sql package with Cockroachdb, a developer might write a handler that queries all columns for a user:

rows, err := db.Query("SELECT id, email, password_hash, is_admin FROM users WHERE id = $1", userID)
if err != nil {
    echo.NewHTTPError(http.StatusInternalServerError).SetInternal(err)
}
defer rows.Close()
for rows.Next() {
    var u User
    if err := rows.Scan(&u.ID, &u.Email, &u.PasswordHash, &u.IsAdmin); err != nil {
        return err
    }
    return c.JSON(http.StatusOK, u)
}

This pattern exposes password_hash and is_admin directly to any client that calls the endpoint, violating the principle of least privilege and increasing the impact of an access-control flaw such as an IDOR. Even if the route is authenticated, over-fetching data means that a compromised token or a misconfigured role can lead to widespread data disclosure.

Another common exposure vector in Echo + Cockroachdb integrations is logging or error handling that includes query results. For example, returning raw SQL errors to the client can leak table structures or sensitive data snippets. Similarly, using reflection-based serializers without field tags can inadvertently include fields that should remain internal. In regulated environments, exposing personally identifiable information (PII) such as emails or phone numbers in API responses can trigger GDPR or PCI-DSS implications.

The dependency on unauthenticated scans by middleBrick amplifies the importance of addressing these exposures: an unauthenticated scan can identify endpoints that return sensitive fields and map them against frameworks like OWASP API Top 10 and GDPR. middleBrick’s checks include Data Exposure among its 12 parallel security checks, and its findings can highlight specific endpoints where fields like password_hash or internal IDs are returned without masking or filtering.

To align with secure design, treat every API response as a controlled output. Use explicit field selection in SQL, apply view models that contain only necessary data, and ensure that serialization respects sensitive-field exclusion. middleBrick’s reports can help prioritize which endpoints require these fixes by assigning a severity level and referencing compliance mappings.

Remediation focuses on minimizing the data footprint returned to the client and ensuring that sensitive fields are never serialized. Start by selecting only the fields required for the operation and mapping them to a dedicated response struct. This prevents accidental inclusion of sensitive columns even if the database schema changes.

Here is a secure version of the earlier handler using an explicit response struct:

type UserResponse struct {
    ID    int64  `json:"id"`
    Email string `json:"email"`
}

func getUser(c echo.Context) error {
    userID := c.Param("id")
    var resp UserResponse
    row := db.QueryRow("SELECT id, email FROM users WHERE id = $1", userID)
    if err := row.Scan(&resp.ID, &resp.Email); err != nil {
        return echo.NewHTTPError(http.StatusNotFound, "user not found")
    }
    return c.JSON(http.StatusOK, resp)
}

For operations that need conditional exposure—such as admin-only fields—introduce role-based view models or separate endpoints with distinct authorization checks. Avoid returning raw database/sql rows or maps that include all columns.

When using ORM-like patterns, configure struct tags to omit sensitive fields and prefer explicit field lists in queries:

// Avoid this:
// type User struct {
//     ID           int64  `json:"id" gorm:"column:id"`
//     Email        string `json:"email" gorm:"column:email"`
//     PasswordHash string `json:"-" gorm:"column:password_hash"`
//     IsAdmin      bool   `json:"-" gorm:"column:is_admin"`
// }

// Prefer explicit query-based DTOs as shown above, or use select fields:
func getPublicUser(c echo.Context) error {
    var dto struct {
        ID    int64  `json:"id"`
        Email string `json:"email"`
    }
    if err := db.Get(&dto, "SELECT id, email FROM users WHERE id = $1", c.Param("id")); err != nil {
        return echo.NewHTTPError(http.StatusNotFound)
    }
    return c.JSON(http.StatusOK, dto)
}

Also ensure that database drivers and connection strings do not log query parameters with sensitive values. In Cockroachdb, use placeholders consistently and avoid string concatenation to build queries, which also reduces the risk of SQL injection that could lead to more extensive data exposure.

Integrating middleBrick into your workflow—via the CLI (middlebrick scan <url>), GitHub Action for CI/CD gates, or MCP Server in your IDE—can help detect data exposure patterns early and provide prioritized remediation guidance tied to frameworks such as OWASP API Top 10 and compliance regimes.