Cors Wildcard in Fiber with Cockroachdb

A CORS wildcard in a Fiber application that uses CockroachDB can expose your backend to data leakage and unauthorized cross-origin requests. When you configure CORS to allow all origins with *, the browser enforces no restrictions on which frontend can interact with your API endpoints, including those that query or mutate CockroachDB-backed resources.

Consider a typical Fiber handler that executes CockroachDB SQL queries based on URL parameters or JWT claims:

// Example: vulnerable handler without origin validation
app.Get("/api/users/:id", func(c *fiber.Ctx) error {
    userID := c.Params("id")
    var user User
    if err := db.QueryRow(context.Background(), "SELECT id, name, email FROM users WHERE id = $1", userID).Scan(&user.ID, &user.Name, &user.Email); err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    return c.JSON(user)
})

If this handler is served with Access-Control-Allow-Origin: *, any website can send authenticated requests on behalf of users (via cookies or tokens) and read personal data from CockroachDB. This becomes critical when combined with authentication mechanisms (e.g., JWTs stored in cookies) because the wildcard allows attacker-controlled origins to leverage existing authenticated sessions.

The risk is compounded when endpoints expose sensitive CockroachDB rows without strict authorization checks. A BOLA/IDOR flaw—where an endpoint uses user-supplied IDs without verifying ownership—combined with a CORS wildcard means any malicious site can enumerate and read other users' data from CockroachDB simply by making requests from the browser.

Additionally, the wildcard can amplify Server-Side Request Forgery (SSRF) risks when your Fiber app passes user-controlled URLs to backend services that may query CockroachDB. The browser’s relaxed CORS policy can inadvertently expose internal endpoints to external pages, increasing the attack surface.

In a security scan, this would be flagged as a high-severity CORS misconfiguration finding, mapped to the OWASP API Top 10 and relevant compliance frameworks. The scanner tests whether origins are overly permissive and whether sensitive responses are accessible cross-origin without proper authorization.

To secure your Fiber application with CockroachDB, you must replace the wildcard with explicit origins and enforce strict access controls per request. Below are concrete, working examples.

1. Configure CORS with specific origins

Instead of allowing all origins, define a controlled allow-origin list and validate incoming headers:

// Secure CORS configuration for Fiber with CockroachDB
allowedOrigins := []string{"https://yourapp.com", "https://admin.yourapp.com"}
corsMiddleware := middleware.CorsConfig{
    AllowOrigins: allowedOrigins,
    AllowMethods: strings.Join([]string{fiber.MethodGet, fiber.MethodPost, fiber.MethodPut, fiber.MethodDelete}, ","),
    AllowHeaders: "Content-Type, Authorization",
    ExposeHeaders: "Content-Length",
    AllowCredentials: true,
}
app.Use(corsMiddleware)

2. Validate origin per request for sensitive endpoints

For highly sensitive handlers, perform runtime origin validation in addition to CORS middleware:

app.Get("/api/users/:id", func(c *fiber.Ctx) error {
    origin := c.Get(fiber.HeaderOrigin)
    allowed := map[string]bool{"https://yourapp.com": true, "https://admin.yourapp.com": true}
    if !allowed[origin] {
        return c.SendStatus(fiber.StatusForbidden)
    }

    userID := c.Params("id")
    // Ensure the requesting user can only access their own data
    claims := c.Locals("claims").(jwt.CustomClaims)
    if claims.UserID != userID {
        return c.SendStatus(fiber.StatusForbidden)
    }

    var user User
    if err := db.QueryRow(context.Background(),
        "SELECT id, name, email, tenant_id FROM users WHERE id = $1 AND tenant_id = $2",
        userID, claims.TenantID).Scan(&user.ID, &user.Name, &user.Email, &user.TenantID); err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    return c.JSON(user)
})

3. Use CockroachDB role-based access controls

Leverage CockroachDB’s native roles and row-level security where possible. Create a database role per application tier and restrict permissions:

-- CockroachDB SQL example
CREATE ROLE web_app WITH LOGIN PASSWORD 'secure_password';
GRANT SELECT ON TABLE users TO web_app;
-- Deny direct access to sensitive columns unless explicitly needed
REVOKE UPDATE(phone, ssn) ON TABLE users FROM web_app;

4. Enforce parameterized queries to prevent injection

Always use placeholders with CockroachDB drivers to avoid SQL injection, which could allow attackers to bypass CORS and authentication entirely:

// Correct: parameterized query with context
err := db.QueryRow(context.Background(),
    "SELECT id, name FROM tenants WHERE slug = $1",
    tenantSlug).Scan(&id, &name)
if err != nil {
    return c.SendStatus(fiber.StatusNotFound)
}

By combining strict CORS policies, per-request origin checks, CockroachDB role separation, and parameterized queries, you eliminate the risk of cross-origin abuse while maintaining secure data access.