Broken Authentication in Chi with Cockroachdb

In web applications built with Chi and Cockroachdb, broken authentication typically arises when session handling, token validation, or credential verification do not properly enforce cryptographic checks or scope boundaries. Chi is a lightweight router that does not impose a particular authentication model, so developers must explicitly secure each route. When integrating Cockroachdb as the identity store, misconfigured SQL queries, missing prepared statements, or improper handling of user identifiers can expose authentication logic to bypass or enumeration.

Consider a login endpoint that constructs SQL dynamically without placeholders:

-- Risk: concatenated identifiers enable SQL injection leading to auth bypass
SELECT id, password_hash FROM users WHERE email = '${email}';

If the email is not validated and directly interpolated, an attacker can manipulate the query to authenticate as any user without knowing the password. Cockroachdb, while compatible with PostgreSQL wire protocol, still enforces strict SQL semantics; improperly parameterized inputs are treated as valid query fragments, enabling authentication bypass via crafted payloads such as ' OR '1'='1 in the email field.

Another common pattern is storing sensitive tokens or API keys in user rows without encryption at rest. Cockroachdb supports encryption in transit via TLS, but if the application layer does not hash passwords or secrets before persistence, credential leaks can occur during backups or node compromises. Chi middleware that sets session cookies must ensure the Secure, HttpOnly, and SameSite attributes are applied consistently; missing attributes enable session fixation or cross-site leakage.

Rate limiting and account lockout are also critical. Without explicit controls on authentication routes, attackers can perform credential stuffing or brute-force attacks against user accounts. Cockroachdb’s distributed nature means retries may route across nodes; if rate limiting is implemented only in Chi middleware without coordination, an attacker can bypass limits by shifting requests across node boundaries. Additionally, inconsistent error messages—such as distinguishing between 'user not found' versus 'invalid password'—can leak account existence and assist enumeration.

Finally, token-based authentication using JWTs must validate issuer, audience, and expiration rigorously. Chi routes that decode tokens without verifying signatures allow attackers to forge tokens and escalate privileges. When combined with Cockroachdb, ensure that token metadata (e.g., user ID, scopes) is verified against the authoritative user record on each request, preventing token reuse or privilege escalation across services.

Secure authentication in Chi with Cockroachdb requires parameterized queries, strict input validation, and consistent session protections. Below are concrete examples that align with the authentication checks performed by middleBrick’s Authentication and BOLA/IDOR scans.

1. Parameterized Login Query

Always use placeholders to prevent SQL injection. The following snippet demonstrates a safe login handler that retrieves a user by email and verifies the password hash using bcrypt. The query uses $1 and $2 placeholders, which Cockroachdb understands natively.

import (
	"context"
	"github.com/go-chi/chi/v5"
	"github.com/jackc/pgx/v5/pgxpool"
	"golang.org/x/crypto/bcrypt"
)

func loginHandler(pool *pgxpool.Pool) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		var email, password string
		if err := json.NewDecoder(r.Body).Decode(&struct {
			Email    string `json:"email"`
			Password string `json:"password"`
		}{&email, &password}); err != nil {
			http.Error(w, `{"error":"invalid_request"}`, 400)
			return
		}

		var storedHash string
		// Use placeholders to avoid injection
		err := pool.QueryRow(r.Context(), "SELECT password_hash FROM users WHERE email = $1", email).Scan(&storedHash)
		if err != nil {
			// Use generic error to avoid enumeration
			http.Error(w, `{"error":"invalid_credentials"}`, 401)
			return
		}

		if err := bcrypt.CompareHashAndPassword([]byte(storedHash), []byte(password)); err != nil {
			http.Error(w, `{"error":"invalid_credentials"}`, 401)
			return
		}

		// Issue secure session cookie or JWT here
		w.Header().Set("Set-Cookie", "session=abc; HttpOnly; Secure; SameSite=Strict")
		w.WriteHeader(200)
	}
}

2. Scoped Token Validation with Role Check

When using JWTs, validate claims and ensure the requesting user matches the resource owner to prevent BOLA/IDOR. The example below decodes a token, fetches the user from Cockroachdb, and confirms ownership before proceeding.

func profileHandler(pool *pgxpool.Pool) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		userID := chi.URLParam(r, "userID")
		token := r.Header.Get("Authorization")
		// Validate token signature and extract subject
		sub, err := validateJWT(token)
		if err != nil || sub != userID {
			http.Error(w, `{"error":"forbidden"}`, 403)
			return
		}

		var profile struct {
			Name  string
			Email string
		}
		// Fetch profile scoped to the authenticated user
		err = pool.QueryRow(r.Context(), "SELECT name, email FROM profiles WHERE user_id = $1", userID).Scan(&profile.Name, &profile.Email)
		if err != nil {
			http.Error(w, `{"error":"not_found"}`, 404)
			return
		}
		json.NewEncoder(w).Encode(profile)
	}
}

3. Secure Cookie and Session Settings

Ensure Chi sets cookies with security attributes. Middleware should apply Secure, HttpOnly, and SameSite=Strict to mitigate session hijacking. Avoid storing sensitive data in URLs or logs.

// Chi middleware example
func secureCookieMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// Example of setting a secure cookie
		http.SetCookie(w, &http.Cookie{
			Name:     "session",
			Value:    generateSecureToken(),
			HttpOnly: true,
			Secure:   true,
			SameSite: http.SameSiteStrictMode,
			Path:     "/",
		})
		next.ServeHTTP(w, r)
	})
}

4. Rate Limiting and Account Lockout

Use a distributed rate limiter to protect authentication endpoints. Coordinated limits prevent bypass across Cockroachdb nodes. Track attempts per email and enforce escalating delays or temporary locks.

// Simplified rate limit check using Redis or in-memory store
if isRateLimited(email) {
	http.Error(w, `{"error":"too_many_requests"}`, 429)
	return
}

5. Error Message Consistency

Return uniform error messages for authentication failures to avoid leaking whether an email exists. This aligns with middleBrick’s findings on authentication enumeration risks.