Header Injection in Chi with Cockroachdb

Header Injection in a Chi-based Go service that uses Cockroachdb can occur when user-controlled input is reflected into HTTP response headers or is used to construct SQL statements without proper handling. Although SQL injection typically targets query correctness and data integrity, header-specific injection arises when an attacker influences header values such as Location, X-Request-ID, or custom headers via request parameters, cookies, or other inputs before those values are passed to middleware that writes headers.

Chi is a lightweight router and middleware framework; it does not sanitize or validate header values automatically. If a handler reads a header or query parameter and writes it directly into the response using w.Header().Set(), an attacker can inject additional header lines or control header-based behavior. This becomes concerning when combined with Cockroachdb because an application may dynamically build SQL queries or connection parameters using the same untrusted input that also influenced headers, increasing the risk of misuse or information leakage.

Cockroachdb is a distributed SQL database and does not introduce header injection by itself; the risk comes from how application code uses database query results or configuration to influence headers. For example, if a handler reads a user-supplied X-Tenant-ID header to select a schema or database, and then uses that value to construct dynamic SQL, an attacker may attempt to manipulate the header to affect both the query and the response metadata. While Cockroachdb enforces SQL safety through prepared statements and parameterized queries, unsafe header usage in Chi can still lead to header smuggling or cache poisoning in fronting proxies that rely on header values.

Because middleBrick scans the unauthenticated attack surface and includes HTTP header checks among its 12 parallel security checks, it can identify indications of header manipulation patterns without requiring credentials. The scanner does not fix the issue; it highlights findings with severity and remediation guidance. Developers should treat header values as untrusted, validate and sanitize all inputs used for header assignment, and avoid using raw user input in SQL construction, regardless of the database backend.

Remediation focuses on strict input validation, avoiding header reflection of untrusted data, and using Cockroachdb safely through parameterized queries. Below are concrete practices and code examples for a Chi service interacting with Cockroachdb.

1. Validate and sanitize header inputs

Never directly set response headers from user-controlled sources. If you must propagate a value, map it through a strict allowlist. For example, if a tenant identifier is required, validate it against a known set or a regex pattern before use.

// Chi middleware that safely handles a tenant header
type tenantContextKey string

func TenantMiddleware(allowedTenants map[string]bool) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            tenant := r.Header.Get("X-Tenant-ID")
            if tenant == "" || !allowedTenants[tenant] {
                http.Error(w, "tenant not allowed", http.StatusBadRequest)
                return
            }
            ctx := context.WithValue(r.Context(), tenantContextKey("tenant"), tenant)
            next.ServeHTTP(w, r.WithContext(ctx))
        })
    }
}

2. Use parameterized queries with Cockroachdb

Always use prepared statements or query builders to prevent SQL injection. Do not concatenate headers or user input into SQL strings.

// Example using database/sql with Cockroachdb
import (
    "context"
    "database/sql"
    _ "github.com/cockroachdb/cockroach-go/v2/crdb"
)

func getCustomer(db *sql.DB, customerID string) (string, error) {
    ctx := context.Background()
    var name string
    // Safe: parameterized query
    err := db.QueryRowContext(ctx, "SELECT name FROM customers WHERE id = $1", customerID).Scan(&name)
    if err != nil {
        return "", err
    }
    return name, nil
}

3. Avoid dynamic SQL construction using header-derived values

Even with Cockroachdb, constructing SQL from headers is risky. If schema or database names must vary, use a strict allowlist and constant mapping rather than string interpolation.

// Safe schema selection using a map lookup
var schemaForTenant = map[string]string{
    "acme":  "acme_schema",
    "globex": "globex_schema",
}

func getSchema(tenant string) (string, bool) {
    schema, ok := schemaForTenant[tenant]
    return schema, ok
}

// Usage in a transaction with Cockroachdb
func handleTenantQuery(db *sql.DB, tenant string, customerID string) error {
    schema, ok := getSchema(tenant)
    if !ok {
        return errors.New("unknown tenant")
    }
    query := fmt.Sprintf("SELECT email FROM %s.profiles WHERE id = $1", pq.QuoteIdentifier(schema))
    return db.QueryRow(context.Background(), query, customerID).Scan(&email)
}

4. Secure header writing in Chi routes

When setting headers in Chi, use fixed values or computed safe values rather than reflecting request headers directly.

// Chi route example
r.Get("/profile/{id}", func(w http.ResponseWriter, r *http.Request) {
    id := chi.URLParam(r, "id")
    // Validate id format before use
    if !isValidID(id) {
        http.Error(w, "invalid id", http.StatusBadRequest)
        return
    }
    w.Header().Set("X-Content-Type-Options", "nosniff")
    w.Header().Set("Cache-Control", "no-store")
    // Safe response writing…
})

5. Leverage middleBrick for continuous detection

Use the middleBrick CLI to scan your Chi endpoints regularly. The CLI can be integrated into scripts or your CI pipeline to detect header handling patterns that may indicate injection risks. For broader coverage, the Pro plan adds continuous monitoring and can be configured with custom thresholds.

# Example CLI usage
middlebrick scan https://api.example.com