Type Confusion in Fiber with Cockroachdb

Type confusion in a Fiber application that uses CockroachDB typically arises when application code constructs database queries or objects from user-controlled input without strict type validation. If the input that determines which CockroachDB SQL statement or struct field to use comes directly from request parameters, headers, or JSON payloads, an attacker can supply values that cause the program to select the wrong type or misinterpret data. This can lead to unexpected query behavior, privilege escalation, or exposure of sensitive records.

Consider a handler that chooses a CockroachDB table or column based on a URL parameter without whitelisting:

// Unsafe: user input directly chooses a table name
func getUserTable(c *fiber.Ctx) error {
    table := c.Query()"table"
    var users []User
    db.Raw("SELECT * FROM ??", table).Scan(&users)
    return c.JSON(users)
}

Because the table name is not validated, an attacker can set table=users; DROP TABLE users or a crafted value that maps to a different table with a different schema. If the application later interprets rows using a mismatched struct, fields may be read into incorrect types, causing type confusion at the application level. For example, if a column expected to be an integer is read as a string, downstream logic that relies on numeric comparisons may behave unpredictably.

Another scenario involves polymorphic unmarshaling of JSON into interfaces when storing or retrieving values from CockroachDB. If your code does not validate concrete types after decoding, an attacker can supply a JSON payload that causes the application to treat a string as a struct or map, leading to logic bypasses or injection:

type Payload interface{}
func storePayload(c *fiber.Ctx) error {
    var p Payload
    if err := c.BodyParser(&p); err != nil {
        return err
    }
    data, _ := json.Marshal(p)
    _, err := db.Exec("INSERT INTO events (data) VALUES ($1)", string(data))
    return err
}

Without strict type checks on P, an attacker can embed nested objects or arrays that, when later deserialized by a component expecting a specific shape, trigger type confusion. Because CockroachDB preserves the JSON payload as-is, the confusion surfaces when the application, not the database, reads and interprets the stored JSON.

The 12 parallel security checks of middleBrick can surface these issues by analyzing the OpenAPI/Swagger spec (including $ref resolution across definitions) and correlating runtime behavior. For instance, input validation findings highlight missing type constraints on parameters that influence SQL identifiers or payloads, while property authorization checks may reveal that endpoints allow access to records across tenant boundaries when type-based scoping is weak.

Remediation focuses on strict validation, parameterized queries, and explicit types so that user input never directly dictates SQL structure or Go types.

1. Validate identifiers against a whitelist

Never interpolate table or column names. Use a whitelist and map user input to safe identifiers:

var allowedTables = map[string]string{
    "profile": "profiles",
    "account": "accounts",
}
func getSafeTable(c *fiber.Ctx) error {
    key := c.Query()"table"
    tableName, ok := allowedTables[key]
    if !ok {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid table"})
    }
    var users []User
    // Use a placeholder for identifiers via squirrel or manual quoting if driver support is limited
    query := fmt.Sprintf("SELECT * FROM %s", pq.Identifier(tableName).Sanitize())
    db.Raw(query).Scan(&users)
    return c.JSON(users)
}

This ensures only expected tables are selected, preventing type confusion arising from mismatched schemas.

2. Use strongly-typed structs and avoid interface{} for DB rows

Define concrete structs that match your CockroachDB schema and unmarshal into them instead of interface{}:

type UserRecord struct {
    ID        int64  `json:"id"`
    Username  string `json:"username"`
    TenantID  string `json:"tenant_id"`
}
func getUsers(c *fiber.Ctx) error {
    var rows []UserRecord
    if err := db.Where("tenant_id = ?", c.Locals("tenant")).Find(&rows).Error; err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    return c.JSON(rows)
}

By binding directly to UserRecord, you eliminate the risk of interpreting fields as incorrect types. If you must handle dynamic fields, validate and constrain them explicitly rather than relying on raw JSON.

3. Parameterized queries and ORM discipline

Ensure all queries use placeholders for values and that ORM usage does not inadvertently inject identifiers:

var user UserRecord
result := db.Where("id = ?", c.Params("id")).First(&user)
if result.Error != nil {
    return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "not found"})
}

Avoid constructing WHERE clauses by string concatenation. If your schema requires dynamic column selection, map column names through a controlled dictionary and use the database driver’s identifier quoting.

With these changes, the combination of Fiber and CockroachDB remains robust against type confusion, because inputs are validated, SQL is parameterized, and data structures are explicit. middleBrick’s scans can then verify that these mitigations are reflected in the runtime behavior and that findings related to authentication, BOLA/IDOR, and input validation are cleared.