Cors Wildcard in Gin with Cockroachdb

A CORS wildcard in a Gin application that uses CockroachDB can unintentionally expose database-driven endpoints to any origin. When app.Use(cors.New(cors.Config{AllowOrigins: []string{"*"}}) is set on a Gin router handling authenticated CockroachDB queries, browsers send requests with credentials only on exact origins, but scripts or attackers can still invoke these endpoints via XMLHttpRequest or fetch from non-whitelisted origins if credentials or tokens are leaked via Referrer or other side channels.

In this combination, the Gin server often exposes endpoints like /api/users/:id that internally query CockroachDB using row-level data tied to the authenticated subject. A wildcard allows any website to trigger these queries, and if the Gin app relies on cookie-based session tokens (or improperly handled authorization headers), the request may be executed in the context of the victim’s permissions. CockroachDB’s role here is as the backend data store; if the Gin service does not enforce origin checks and relies only on CORS for access control, the wildcard removes a layer of enforcement, making authentication and authorization boundaries dependent solely on application code rather than infrastructure-enforced policies.

Moreover, preflight requests with wildcard origins can lead to inconsistent handling when the Gin app uses per-origin configurations dynamically. An attacker can probe endpoints via simple JavaScript, and if the Gin service returns sensitive data or sets unsafe headers (e.g., exposing database metadata or error details that reveal CockroachDB schema or version), the exposure is compounded. The vulnerability is not in CockroachDB itself but in how Gin routes and middleware are configured when paired with a database that returns detailed error messages or verbose rows that can aid further exploitation like injection or information leakage.

Real-world patterns include endpoints that accept an identifier and directly construct SQL or use an ORM without verifying that the caller is allowed to access that specific resource. With a wildcard, any origin can trigger these lookups, and if rate limiting or authentication is missing or misapplied at the middleware layer, the attack surface grows. The 12 security checks in middleBrick would flag this as a BOLA/IDOR and CORS misconfiguration risk, highlighting that the wildcard permits unauthorized origins to initiate requests that reach the CockroachDB layer, potentially leading to data exposure if sensitive rows are returned without proper row-level authorization checks.

Remediation focuses on tightening CORS policy and enforcing authorization at the handler and database query levels. Instead of a wildcard, specify exact origins and apply middleware that validates origin, method, and headers. Combine this with per-request authorization that confirms the requesting subject can access the targeted CockroachDB row.

Example secure Gin setup with CockroachDB:

// main.go
package main

import (
	"context"
	"log"
	"net/http"

	"github.com/gin-gonic/gin"
	"github.com/jackc/pgx/v5/pgxpool"
	"github.com/gorilla/handlers"
)

func main() {
	// CockroachDB connection pool
	pool, err := pgxpool.New(context.Background(), "postgresql://user:password@host:26257/dbname?sslmode=require")
	if err != nil {
		log.Fatalf("Unable to connect to CockroachDB: %v\n", err)
	}
	defer pool.Close()

	// Tight CORS policy
	corsMiddleware := handlers.CORS(
		handlers.AllowedOrigins([]string{"https://app.example.com", "https://api.example.com"}),
		handlers.AllowedMethods([]string{"GET", "POST", "PUT", "DELETE"}),
		handlers.AllowedHeaders([]string{"Authorization", "Content-Type"}),
		handlers.ExposedHeaders([]string{"X-Total-Count"}),
		handlers.AllowCredentials(),
	)

	app := gin.Default()
	app.Use(corsMiddleware)

	// Example protected endpoint with row-level authorization
	app.GET("/api/users/:id", func(c *gin.Context) {
		userID := c.Param("id")
		requester := c.MustGet("user_id").(string) // from auth middleware

		var username string
		row := pool.QueryRow(c.Request.Context(),
			"SELECT username FROM users WHERE id = $1 AND id = $2", userID, requester)
		err := row.Scan(&username)
		if err != nil {
			c.AbortWithStatusJSON(http.StatusForbidden, gin.H{"error": "access denied or not found"})
			return
		}
		c.JSON(http.StatusOK, gin.H{"username": username})
	})

	// Apply rate limiting and other middleware as needed
	log.Println("Server listening on :8080")
	log.Fatal(app.Run())
}

Key points:

Specify exact origins in CORS configuration instead of ["*"].
Enforce per-request authorization in SQL by including the subject identifier in the query predicate (e.g., id = $2 AND id = $1) to ensure row-level security even if application logic fails.
Use prepared statements via pgx to avoid injection and ensure type-safe queries against CockroachDB.
Return minimal headers and avoid exposing database details in error responses; map database errors to generic messages to prevent information leakage that could aid an attacker probing the API.

middleBrick’s scans can validate that the CORS configuration is not overly permissive and that endpoints enforce authorization, reducing the risk of BOLA/IDOR when CockroachDB is the backend. The Pro plan’s continuous monitoring can alert you if a wildcard reappears in CORS settings after deployments.