Mass Assignment in Cockroachdb

Mass assignment vulnerabilities in Cockroachdb applications occur when user-controlled data is automatically mapped to database columns without proper validation. This manifests most commonly in Go applications using Cockroachdb through GORM, pgx, or Cockroachdb's SQL API.

The core issue arises when application code blindly trusts client-provided data. Consider this typical pattern in a Go web service:

type User struct {
    ID       int64  `json:"id"`
    Email    string `json:"email"`
    Password string `json:"password"`
    Role     string `json:"role"`
    IsActive bool   `json:"is_active"`
}

func (h *Handler) CreateUser(w http.ResponseWriter, r *http.Request) {
    var user User
    if err := json.NewDecoder(r.Body).Decode(&user); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }
    
    // Vulnerable: blind insertion
    if err := h.db.Create(&user).Error; err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    
    w.WriteHeader(201)
}

An attacker can exploit this by sending:

{
    "email": "attacker@example.com",
    "password": "pwned",
    "role": "admin",
    "is_active": true,
    "id": 1
}

Cockroachdb's distributed architecture doesn't prevent this—the vulnerability exists at the application layer. The database faithfully executes whatever INSERT or UPDATE statements the application sends.

Cockroachdb-specific manifestations include:

• JSONB column exploitation: When using JSONB columns with GORM's embedded structs, attackers can manipulate nested JSON structures
• Computed column bypass: Cockroachdb's computed columns can be tricked if application logic assumes they're always calculated server-side
• Interleaved table manipulation: In multi-tenant schemas using interleaved tables, mass assignment can escalate privileges across tenant boundaries

The distributed nature of Cockroachdb means these vulnerabilities can affect multiple nodes simultaneously, but the root cause remains application logic flaws, not database-specific issues.

Detecting mass assignment in Cockroachdb applications requires examining both the application code and database schema. Here's how to identify these vulnerabilities:

Code Analysis Patterns

Look for these red flags in your Go codebase:

// Vulnerable pattern - no field filtering
func (h *Handler) UpdateUser(w http.ResponseWriter, r *http.Request) {
    var user User
    json.NewDecoder(r.Body).Decode(&user)
    
    id := chi.URLParam(r, "id")
    h.db.Model(&User{}).Where("id = ?", id).Updates(&user) // <-- Mass assignment
}

// Safer pattern - explicit field selection
func (h *Handler) UpdateUser(w http.ResponseWriter, r *http.Request) {
    var updateFields struct {
        Email    string `json:"email"`
        Password string `json:"password"`
    }
    
    if err := json.NewDecoder(r.Body).Decode(&updateFields); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }
    
    id := chi.URLParam(r, "id")
    h.db.Model(&User{}).Where("id = ?", id).Updates(updateFields) // Only allowed fields
}

Database Schema Analysis

Examine your Cockroachdb schema for sensitive columns that might be exposed:

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email STRING UNIQUE,
    password_hash STRING NOT NULL,
    role STRING DEFAULT 'user' CHECK (role IN ('user', 'admin', 'moderator')),
    is_active BOOL DEFAULT true,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now(),
    tenant_id UUID REFERENCES tenants(id)
);

-- Check for unexpected column exposure
SELECT column_name, is_nullable, column_default
FROM information_schema.columns
WHERE table_name = 'users';

Using middleBrick for Automated Detection

middleBrick's black-box scanning approach is particularly effective for detecting mass assignment vulnerabilities in Cockroachdb applications:

# Install middleBrick CLI
npm install -g middlebrick

# Scan your API endpoint
middlebrick scan https://api.yourservice.com/v1/users

# Review the report for mass assignment findings
middlebrick report last --format json

middleBrick tests for mass assignment by attempting to modify protected fields through API endpoints, checking if the application properly validates and filters user input before database operations.

Remediating mass assignment in Cockroachdb applications requires a defense-in-depth approach combining application-level controls and database constraints.

Application-Level Controls

The most effective approach uses Go structs with explicit field tagging and validation:

type UserCreateRequest struct {
    Email    string `json:"email" validate:"required,email"`
    Password string `json:"password" validate:"required,min=8"`
}

type UserUpdateRequest struct {
    Email    *string `json:"email" validate:"omitempty,email"`
    Password *string `json:"password" validate:"omitempty,min=8"`
}

type UserResponse struct {
    ID        int64  `json:"id"`
    Email     string `json:"email"`
    Role      string `json:"role"`
    IsActive  bool   `json:"is_active"`
    CreatedAt string `json:"created_at"`
}

func (h *Handler) CreateUser(w http.ResponseWriter, r *http.Request) {
    var req UserCreateRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }
    
    if err := validator.New().Struct(req); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }
    
    user := &User{
        Email:     req.Email,
        Password:  hashPassword(req.Password),
        Role:      "user",
        IsActive:  true,
    }
    
    if err := h.db.Create(user).Error; err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    
    // Return safe response
    resp := UserResponse{
        ID:        user.ID,
        Email:     user.Email,
        Role:      user.Role,
        IsActive:  user.IsActive,
        CreatedAt: user.CreatedAt.Format(time.RFC3339),
    }
    
    json.NewEncoder(w).Encode(resp)
}

Database-Level Constraints

Complement application controls with database constraints:

-- Use column-level permissions for multi-tenant isolation
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email STRING UNIQUE,
    password_hash STRING NOT NULL,
    role STRING DEFAULT 'user' CHECK (role IN ('user', 'admin', 'moderator')),
    is_active BOOL DEFAULT true,
    tenant_id UUID NOT NULL REFERENCES tenants(id),
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now(),
    
    -- Prevent unauthorized role escalation
    CONSTRAINT prevent_role_escalation CHECK (
        (current_user = 'app_user' AND role = 'user') OR
        (current_user = 'app_admin' AND role IN ('user', 'admin'))
    )
);

-- Use row-level security for tenant isolation
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON users
    FOR ALL TO app_user
    USING (tenant_id = current_setting('app.current_tenant_id')::UUID);

GORM-Specific Safeguards

When using GORM with Cockroachdb, implement field-level protection:

func (h *Handler) UpdateUser(w http.ResponseWriter, r *http.Request) {
    var updateFields struct {
        Email    string `json:"email"`
        Password string `json:"password"`
    }
    
    if err := json.NewDecoder(r.Body).Decode(&updateFields); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }
    
    id := chi.URLParam(r, "id")
    
    // Only update allowed fields
    result := h.db.Model(&User{}).Where("id = ?", id).Updates(map[string]interface{}{
        "email":     updateFields.Email,
        "password": hashPassword(updateFields.Password),
    })
    
    if result.RowsAffected == 0 {
        http.Error(w, "User not found", 404)
        return
    }
    
    w.WriteHeader(200)
}

This approach ensures that even if an attacker discovers API endpoints, they cannot escalate privileges or modify protected fields due to the layered security controls.