Data Exposure in Buffalo with Cockroachdb

The Data Exposure check in middleBrick examines whether an API unintentionally returns sensitive information such as personally identifiable information (PII), authentication tokens, or internal identifiers. When an API is built with the Buffalo framework and uses Cockroachdb as the backend, specific patterns can increase the likelihood of data exposure.

Buffalo encourages rapid development with conventions like automatic JSON serialization for models. If a developer does not explicitly control which fields are included in serialization, models may expose sensitive columns from Cockroachdb tables. For example, a User table might contain columns like password_digest, reset_token, or internal_role. If the model is serialized without filtering, these fields can appear in HTTP responses, especially for endpoints that return lists or single items.

Cockroachdb, being a distributed SQL database, does not prevent applications from returning more data than intended. The database will faithfully return whatever columns the query selects. A common pitfall in Buffalo apps is using automatic helpers that generate queries selecting all columns (e.g., models.Find(models.DB, &users)) without scoping the select statement. This becomes a data exposure risk when sensitive columns exist in the schema but are not meant for client consumption.

Additionally, Buffalo applications may include view templates that render HTML pages with sensitive data. If a developer accidentally passes a model containing PII or secrets to a template and the template iterates over fields, sensitive information can be rendered in HTML responses. middleBrick’s Data Exposure check looks for such patterns by correlating database schema information (when available) with API responses, flagging endpoints that return fields typically considered sensitive.

Real-world attack patterns include attackers enumerating user data through IDOR-related endpoints or extracting tokens that facilitate session hijacking. In a Buffalo + Cockroachdb stack, these issues manifest when endpoints lack proper field selection and authorization checks.

middleBrick’s scan tests unauthenticated endpoints and inspects responses for indicators such as email addresses, internal IDs, or structured keys that resemble credentials. For Cockroachdb-backed Buffalo apps, the scanner cross-references known column names (e.g., password_digest, auth_token) with actual responses to surface potential data exposure.

To mitigate Data Exposure when using Buffalo with Cockroachdb, focus on explicit field selection in queries and strict serialization controls. Below are concrete code examples that demonstrate secure patterns.

1. Explicit Column Selection in Queries

Avoid automatic selection of all columns. Instead, explicitly select only the fields needed for the response. In Cockroachdb, this is done at the SQL level, and Buffalo models should reflect this discipline.

-- Cockroachdb query: select only required columns
SELECT id, name, email FROM users WHERE status = 'active';

In your Buffalo code, use a custom query or a select clause to limit fields:

// Safe: explicit fields only
type UserPublic struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
    Email string `json:"email"`
}

var users []UserPublic
if err := models.DB.Select(&users, "SELECT id, name, email FROM users"); err != nil {
    // handle error
}

2. Controlled JSON Serialization

Ensure your models do not serialize sensitive fields. Use view models or custom JSON tags to exclude internal columns.

// User model for public responses
type UserResponse struct {
    ID        int    `json:"id"`
    Username  string `json:"username"`
    Email     string `json:"email"`
    CreatedAt string `json:"created_at"`
    // Intentionally omit: PasswordDigest, ResetToken, Role
}

func (r UserResponse) FromUser(u models.User) UserResponse {
    return UserResponse{
        ID:        u.ID,
        Username:  u.Username,
        Email:     u.Email,
        CreatedAt: u.CreatedAt.String(),
    }
}

When rendering JSON in Buffalo actions, use the response model:

func UsersList(c buffalo.Context) error {
    var users []models.User
    if err := models.DB.All(&users); err != nil {
        return c.Error(500, err)
    }
    publicUsers := make([]UserResponse, len(users))
    for i, u := range users {
        publicUsers[i] = UserResponse::FromUser(u)
    }
    return c.Render(200, r.JSON(publicUsers))
}

3. Secure Template Rendering

If using HTML templates, avoid passing raw models that contain sensitive fields. Pass a structured view model instead.

func ProfilePage(c buffalo.Context) error {
    userID, _ := uuid.FromV4(c.Param("user_id"))
    var user struct {
        ID       int
        Username string
        Email    string
    }
    err := models.DB.Get(&user, "SELECT id, username, email FROM users WHERE id = $1", userID)
    if err != nil {
        return c.Error(404, errors.New("not found"))
    }
    return c.Render(200, r.HTML("profile.html", user))
}

4. Database Schema Considerations

Design your Cockroachdb schema to separate sensitive data. For example, store password hashes in a column that is rarely selected by application queries, and ensure that application-level queries explicitly omit such columns.

-- Schema example
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    username STRING UNIQUE NOT NULL,
    email STRING UNIQUE NOT NULL,
    password_digest STRING NOT NULL,
    reset_token STRING,
    internal_role STRING DEFAULT 'user',
    created_at TIMESTAMP DEFAULT now()
);

By combining explicit queries, disciplined serialization, and schema design, Buffalo applications on Cockroachdb can significantly reduce the risk of Data Exposure as evaluated by middleBrick’s checks.