Cors Wildcard in Echo Go with Cockroachdb

When building a Go API with the Echo framework that connects to CockroachDB, using a CORS wildcard (*) can unintentionally expose database-driven endpoints to any origin. In Echo, this is typically configured via middleware such as echo-contrib/cors. A common pattern looks like:

c := cors.New(cors.Config{
    AllowOrigins: []string{"*"},
    AllowMethods: []string{echo.GET, echo.POST},
})
echoApp.Use(c.Middleware)

The wildcard allows any web origin to make authenticated requests to your Echo routes. If those routes expose endpoints that query CockroachDB—such as /api/users/:id—the wildcard removes origin-based enforcement at the API layer. An attacker can craft a page on a malicious site that calls your Echo endpoints from a victim’s browser, leveraging stored credentials or session cookies to relay database queries through the victim’s authenticated context.

This becomes particularly risky when combined with CockroachDB-backed business logic that relies on user identity embedded in the request (e.g., extracting user_id from JWT and using it in SQL like SELECT * FROM users WHERE id = $1). Because the CORS policy permits any origin, there is no safeguard to ensure that requests originate from a trusted frontend. The database itself enforces row-level security only if explicitly programmed; without it, a wildcard CORS configuration effectively bypasses any same-origin-origin access control, enabling unauthorized data retrieval or manipulation across origins.

Furthermore, preflight requests (OPTIONS) allowed by the wildcard can reveal supported methods and headers, aiding an attacker in planning exploits against CockroachDB-backed endpoints. The Echo route handlers may inadvertently expose sensitive data or operations if they do not independently validate the request source, because the CORS layer’s permissiveness provides a false sense of boundary enforcement.

In practice, this misconfiguration pairs poorly with typical authentication mechanisms (e.g., JWT or session cookies) that rely on cookies being sent cross-origin. Browsers will include credentials when credentials: include is set, and with a wildcard origin, any site can trigger authenticated requests to your API, potentially leading to unauthorized CockroachDB queries being executed under the victim’s permissions.

To secure an Echo service backed by CockroachDB, replace the wildcard CORS policy with an allowlist of trusted origins and enforce strict origin checks in your route handlers. Below is a secure configuration using echo-contrib/cors:

c := cors.New(cors.Config{
    AllowOrigins: []string{"https://app.yourdomain.com", "https://admin.yourdomain.com"},
    AllowMethods: []string{echo.GET, echo.POST, echo.PUT, echo.DELETE},
    AllowHeaders: []string{echo.HeaderAuthorization, echo.HeaderContentType},
    ExposeHeaders: []string{"X-Total-Count"},
    MaxAge: 86400,
    AllowCredentials: true,
})
echoApp.Use(c.Middleware)

In your route handlers, always derive data from the authenticated session rather than client-supplied path parameters when possible. If you must use parameters, validate and sanitize them before using them in CockroachDB queries. Use prepared statements to avoid SQL injection and ensure that the database user has the least privilege necessary:

func getUserHandler(db *pgx.Conn) echo.HandlerFunc {
    return func(c echo.Context) error {
        userID := c.Param("id")
        // Validate format to prevent UUID or injection anomalies
        if !isValidUUID(userID) {
            return echo.NewHTTPError(http.StatusBadRequest, "invalid user identifier")
        }
        var user User
        err := db.QueryRow(c, "SELECT id, email, name FROM users WHERE id = $1 AND deleted_at IS NULL", userID).Scan(&user.ID, &user.Email, &user.Name)
        if err != nil {
            return echo.NewHTTPError(http.StatusInternalServerError, "failed to fetch user")
        }
        return c.JSON(http.StatusOK, user)
    }
}

For CockroachDB, prefer using pgx with prepared statements or an ORM that supports parameterized queries. Avoid string concatenation to build SQL, even for dynamic sorting or filtering. If you need row-level security, define it in the database using CockroachDB’s capabilities and ensure your application respects the policy regardless of CORS configuration:

err := db.Exec(c, "CREATE POLICY user_policy ON users FOR SELECT USING (id = $1)", userID)

Combine this with structured logging and monitoring of query outcomes to detect anomalies. When using the middleBrick CLI (middlebrick scan <url>) or GitHub Action, you can automatically detect permissive CORS configurations among other API security checks. In CI/CD, set a threshold in your GitHub Action to fail builds if high-severity findings appear, ensuring that wildcard CORS or similar issues are caught before deployment.