Insufficient Logging in Gorilla Mux with Cockroachdb

Insufficient logging in a Gorilla Mux service backed by Cockroachdb can leave critical security events and application errors unrecorded, reducing the ability to detect, investigate, and respond to incidents. When routes defined in Gorilla Mux do not explicitly log request context and database outcomes, anomalies such as authentication failures, authorization mismatches, or SQL-level errors in Cockroachdb may go unnoticed.

Gorilla Mux is a request router and dispatcher; it does not provide built-in logging for handler execution or database interactions. If handlers perform SQL statements directly against Cockroachdb without structured logging, you lose visibility into which endpoint was invoked, who triggered it, and what the database returned. This gap is especially risky for operations that modify data or access sensitive tables, because you cannot reliably reconstruct an attack path or a failure chain after the fact.

From a database perspective, Cockroachdb exposes detailed error codes and SQL states, but these are only useful if your application captures and logs them. Without structured logs that include statement text, parameter values (masked), transaction IDs, and HTTP metadata, you cannot correlate application-layer routes with database-layer events. For example, a handler that executes an upsert against a tenant-specific table will not indicate which tenant caused a constraint violation unless the handler explicitly logs the tenant ID and the SQL error returned by Cockroachdb.

Attack surfaces expand when logs lack severity, source IP, user context, and outcome status. An attacker probing IDOR or BOLA endpoints may cause repeated 404 or 403 responses that are not recorded, while the service continues to process requests. Over time, this absence of telemetry prevents detection patterns such as rate anomalies or unusual query failures that Cockroachdb might surface through its own observability tools but your application never records.

To mitigate this specific combination, ensure every Gorilla Mux handler logs the HTTP method, route pattern, resolved URL parameters, authenticated subject (if any), and the result of Cockroachdb operations including error codes and affected rows. Use structured logging with key-value pairs to make logs queryable by security tools. This approach aligns with the broader security checks in middleBrick, including the Logging and Monitoring checks within its 12 parallel security scans, which highlight gaps in auditability for routes backed by Cockroachdb.

Remediation centers on adding explicit, structured logging inside Gorilla Mux handlers that interact with Cockroachdb. Below are concrete, working examples that demonstrate how to capture request context, database statements, and errors without introducing unsafe practices.

package main

import (
	"context"
	"database/sql"
	"encoding/json"
	"log/slog"
	"net/http"
	"os"

	"github.com/gorilla/mux"
	_ "github.com/cockroachdb/cockroach-go/v2/crdb"
)

type loggerKey string

const dbLoggerKey loggerKey = "db"

func main() {
	db, err := sql.Open("cockroachdb", os.Getenv("COCKROACH_URL") + "?sslmode=verify-full")
	if err != nil {
		slog.Error("failed to connect to cockroachdb", "error", err)
		os.Exit(1)
	}
	defer db.Close()

	r := mux.NewRouter()
	r.Use(loggingMiddleware)
	r.HandleFunc("/api/tenant/{id}/profile", updateTenantProfileHandler(db)).Methods("PUT")
	http.ListenAndServe(":8080", r)
}

func loggingMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		slog.Info("http request",
			"method", r.Method,
			"path", r.URL.Path,
			"route", mux.CurrentRoute(r).GetName(),
			"client", r.RemoteAddr,
		)
		next.ServeHTTP(w, r)
	})
}

func updateTenantProfileHandler(db *sql.DB) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		vars := mux.Vars(r)
		tenantID := vars["id"]

		var email string
		if err := json.NewDecoder(r.Body).Decode(&email); err != nil {
			slog.Warn("invalid request body", "tenant_id", tenantID, "error", err)
			http.Error(w, "invalid payload", http.StatusBadRequest)
			return
		}

		ctx := context.Background()
		err := crdb.ExecuteTx(ctx, db, nil, func(tx *sql.Tx) error {
			query := `UPDATE tenants SET email = $1 WHERE id = $2 RETURNING id, email`
			// Structured log before execution
			slog.Info("executing sql",
				"tenant_id", tenantID,
				"query", query,
			)
			var updatedEmail string
			err := tx.QueryRowContext(ctx, query, email, tenantID).Scan(&updatedEmail)
			if err != nil {
				// Log Cockroachdb-specific error fields
				if pgErr, ok := err.(*cockroachErr); ok {
					slog.Error("cockroachdb execution error",
						"tenant_id", tenantID,
						"code", pgErr.Code(),
						"severity", pgErr.Severity(),
						"message", err.Error(),
					)
				} else {
					slog.Error("database execution error",
						"tenant_id", tenantID,
						"error", err,
					)
				}
				return err
			}
			// Log successful outcome with affected data
			slog.Info("sql execution succeeded",
				"tenant_id", tenantID,
				"updated_email", updatedEmail,
			)
			return nil
		})

		if err != nil {
			http.Error(w, "unable to update profile", http.StatusInternalServerError)
			return
		}

		w.WriteHeader(http.StatusOK)
		json.NewEncoder(w).Encode(map[string]string{"status": "updated"})
	}
}

In this example, the middleware logs the incoming HTTP request with method and path, while the handler explicitly logs before and after Cockroachdb execution, including tenant context and any database error codes. This ensures that each route maps to observable database events, addressing insufficient logging by providing traceable, structured audit records.

For production use, configure slog with a JSON handler and redact sensitive fields to avoid leaking secrets. Combine these logs with Cockroachdb’s built-in statement diagnostics to correlate application routes with database behavior, improving detection of anomalies such as unexpected constraint violations or unauthorized data access attempts.