Null Pointer Dereference in Echo Go with Cockroachdb

A null pointer dereference in an Echo Go service that uses CockroachDB typically arises when application code assumes a database query result is non-nil without explicit validation. Because CockroachDB is a distributed SQL database, the driver returns rows that must be explicitly checked before accessing column values. If a developer calls methods such as Scan or accesses struct fields without confirming a row exists, the runtime can encounter a nil pointer, leading to a 500 error and potential information leakage.

In the context of an unauthenticated scan by a tool like middleBrick, endpoints that query CockroachDB become interesting attack surfaces. For example, an endpoint like /users/{id} that performs a SQL lookup by ID may not handle the case where the ID does not exist. Without proper null checks, the service may panic, and the stack trace could be exposed in the HTTP response. This not only degrades availability but can also reveal internal paths or database schema details useful in chained attacks.

The interaction between Echo Go routing and CockroachDB driver behavior is key: Echo passes request context to handlers, and if a handler launches a query with db.QueryRowContext and then directly calls Scan on a nil row, the program crashes. middleBrick tests such scenarios by sending omitted or malformed identifiers to observe whether responses contain stack traces or server errors, which would map to improper error handling in the OWASP API Security Top 10 category of Server-Side Request Handling.

Concrete patterns that lead to this issue include binding URL parameters to structs without verifying database presence, using pointer receivers on value types that may be nil, and failing to check sql.ErrNoRows before accessing fields. These patterns are common when developers copy ORM-style convenience code that suppresses explicit row checks, inadvertently creating a path for null pointer dereference in production when validations are bypassed.

Remediation focuses on defensive checks before any pointer indirection. Always verify the presence of a row after query execution and provide safe defaults or structured error responses. In Echo Go, this means ensuring handlers inspect results and avoid assuming non-nil structs when working with CockroachDB, particularly for unauthenticated endpoints where input validation is critical for stability and security.

To prevent null pointer dereference in Echo Go with CockroachDB, adopt explicit row existence checks and structured error handling. Below are concrete, working examples that demonstrate safe query patterns and proper context usage.

// Safe query with explicit row check
func getUserHandler(db *sql.DB) echo.HandlerFunc {
    return func(c echo.Context) error {
        id := c.Param("id")
        ctx := c.Request().Context()
        var user User
        row := db.QueryRowContext(ctx, "SELECT id, name, email FROM users WHERE id = $1", id)
        err := row.Scan(&user.ID, &user.Name, &user.Email)
        if err != nil {
            if errors.Is(err, sql.ErrNoRows) {
                return c.JSON(http.StatusNotFound, map[string]string{"error": "user not found"})
            }
            return c.JSON(http.StatusInternalServerError, map[string]string{"error": "database error"})
        }
        return c.JSON(http.StatusOK, user)
    }
}

This pattern ensures that Scan is only called when a row is guaranteed to exist. By checking sql.ErrNoRows, the handler returns a clean 404 instead of risking a nil pointer dereference. The use of QueryRowContext with request context ties database lifetime to the HTTP request, supporting cancellation and timeouts that are essential in distributed CockroachDB deployments.

// Batch insert with proper error handling
func createUsersHandler(db *sql.DB) echo.HandlerFunc {
    return func(c echo.Context) error {
        var payload []User
        if err := c.Bind(&payload); err != nil {
            return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid payload"})
        }
        ctx := c.Request().Context()
        tx, err := db.BeginTx(ctx, nil)
        if err != nil {
            return c.JSON(http.StatusInternalServerError, map[string]string{"error": "cannot start transaction"})
        }
        stmt, err := tx.PrepareContext(ctx, "INSERT INTO users (id, name, email) VALUES ($1, $2, $3)")
        if err != nil {
            tx.Rollback()
            return c.JSON(http.StatusInternalServerError, map[string]string{"error": "cannot prepare statement"})
        }
        defer stmt.Close()
        for _, u := range payload {
            _, err = stmt.ExecContext(ctx, u.ID, u.Name, u.Email)
            if err != nil {
                tx.Rollback()
                return c.JSON(http.StatusInternalServerError, map[string]string{"error": "insert failed"})
            }
        }
        if err := tx.Commit(); err != nil {
            return c.JSON(http.StatusInternalServerError, map[string]string{"error": "commit failed"})
        }
        return c.NoContent(http.StatusCreated)
    }
}

The second example shows transactional safety with CockroachDB, which strongly prefers explicit transactions for writes. By preparing statements within the transaction and checking each ExecContext error, you avoid nil pointer scenarios that can occur when assuming successful preparation. The pattern also demonstrates how to bind incoming JSON safely, reducing the chance of malformed inputs triggering unexpected pointer indirection.

For read-heavy services, consider using db.Select with slice allocation and post-query validation. Always initialize slices before scanning rows into them, and treat any nil slice as an empty result set rather than a pointer to be dereferenced. These practices align with robust API design in Echo Go and ensure compatibility with CockroachDB’s SQL semantics.

middleBrick can validate these patterns indirectly by scanning endpoints for error handling consistency and observing whether responses expose internal state. Using the CLI, developers can run middlebrick scan <url> to verify that their endpoints return appropriate status codes and avoid leaking stack traces, while the GitHub Action can enforce security thresholds in CI/CD pipelines.