Information Disclosure in Gin with Cockroachdb

Information disclosure occurs when a Gin application using Cockroachdb inadvertently exposes sensitive data through error messages, misconfigured logging, or improper handling of database responses. Because Cockroachdb uses a PostgreSQL-wire protocol, common patterns for querying and scanning rows can produce detailed errors if requests are malformed or credentials are missing.

In Gin, developers often bind request parameters directly into SQL queries or ORM calls. If input validation is missing, an attacker can supply crafted parameters that trigger verbose Cockroachdb errors. These errors may reveal table names, column definitions, or internal schema details, especially when debug mode is enabled or stack traces are returned to the client.

For example, suppose a Gin handler retrieves a user record by ID without validating or sanitizing the userID parameter. If the ID does not exist or is of an unexpected type, Cockroachdb may return a detailed error such as a pq: syntax error or a violation detail. When Gin writes this error directly to the HTTP response body, the client receives internal database information that should never be exposed.

Middleware that logs requests can compound the risk. If Gin’s logger records the full request URL, query parameters, and the exact Cockroachdb error, sensitive patterns like table prefixes or query structures may be stored in logs or exposed through log aggregation interfaces. This is particularly relevant for endpoints that perform row-level lookups using IDs derived from URLs or tokens.

Additionally, if a Cockroachdb connection string is embedded in Gin configuration or environment variables without proper access controls, deployment artifacts or misconfigured containers might expose credentials. Combined with verbose error handling in Gin, this can lead to information leakage about database topology, database names, or user permissions.

To illustrate, consider an endpoint that scans a users table by username. A handler that does not properly validate input may pass a raw query string to Cockroachdb, and if the query fails, Gin may return the full error to the client. This can expose whether the table exists, what columns it contains, or how the database indexes data, aiding further reconnaissance.

Remediation focuses on strict input validation, safe error handling, and avoiding exposure of database details in responses and logs. Use parameterized queries to prevent injection and ensure that errors are sanitized before being returned to clients.

1. Use parameterized queries with database/sql

Always use placeholders instead of string concatenation. This prevents malicious input from altering query structure and avoids verbose errors that disclose schema details.

import (
    "context"
    "database/sql"
    "net/http"
    "github.com/gin-gonic/gin"
    _ "github.com/lib/pq"
)

func getUserByEmail(c *gin.Context) {
    db, _ := sql.Open("postgres", "postgresql://user:password@host:26257/dbname?sslmode=require")
    var email string
    if err := c.BindQuery(&struct{ Email string }{Email: email}); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})
        return
    }
    var user struct {
        ID   int
        Name string
    }
    err := db.QueryRow(context.Background(), "SELECT id, name FROM users WHERE email = $1", email).Scan(&user.ID, &user.Name)
    if err != nil {
        if err == sql.ErrNoRows {
            c.JSON(http.StatusNotFound, gin.H{"error": "user not found"})
        } else {
            c.JSON(http.StatusInternalServerError, gin.H{"error": "internal error"})
        }
        return
    }
    c.JSON(http.StatusOK, gin.H{"user": user})
}

2. Avoid logging sensitive query details

Configure Gin’s logger to exclude query parameters or database-specific error content. Use structured logging with redaction for sensitive fields.

import (
    "github.com/gin-gonic/gin"
    "log"
)

func safeLogger() gin.HandlerFunc {
    return func(c *gin.Context) {
        c.Next()
        status := c.Writer.Status()
        // Log only status and path, never full query or db error
        log.Printf("method=%s path=%s status=%d", c.Request.Method, c.Request.URL.Path, status)
    }
}

3. Return generic error messages

Ensure that Gin does not forward Cockroachdb-specific error messages to the client. Map database errors to generic HTTP responses.

func createUser(c *gin.Context) {
    var payload struct {
        Username string `json:"username" validate:"required"`
    }
    if err := c.ShouldBindJSON(&payload); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": "invalid payload"})
        return
    }
    _, err := db.Exec(context.Background(), "INSERT INTO users (username) VALUES ($1)", payload.Username)
    if err != nil {
        // Do not expose err.Error() which may contain schema info
        c.JSON(http.StatusInternalServerError, gin.H{"error": "unable to complete request"})
        return
    }
    c.JSON(http.StatusCreated, gin.H{"status": "created"})
}

4. Secure connection strings and environment usage

Load Cockroachdb connection strings from secure sources and avoid committing them to version control. Use Gin’s configuration mechanisms to restrict access.

import (
    "os"
    "github.com/joho/godotenv"
)

func init() {
    godotenv.Load()
}

func getDB() *sql.DB {
    connStr := os.Getenv("COCKROACH_DATABASE_URL")
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        panic("failed to connect")
    }
    return db
}