Missing Tls in Fiber with Cockroachdb
Missing Tls in Fiber with Cockroachdb — how this specific combination creates or exposes the vulnerability
When a Fiber application connects to a CockroachDB cluster without TLS, credentials and query results traverse the network in plaintext. This exposes authentication material and potentially sensitive business data to interception on the network path. middleBrick scans this attack surface during its unauthenticated checks, including checks for Encryption and Data Exposure, and can flag the missing TLS as a high-severity finding. An attacker who can observe or manipulate traffic between the application and the database can harvest usernames, passwords, and connection strings, and may be able to modify queries in-transit.
In a typical setup, developers configure a sql.DB connection string without specifying secure connection parameters. For example, a connection string like postgresql://root@localhost:26257/defaultdb?sslmode=disable explicitly disables encryption, which is dangerous in production. CockroachDB defaults to non-encrypted listener ports (e.g., 26257 for SQL), and if TLS is not configured on those listeners or not enforced by the client, data in motion is unprotected. middleBrick’s OpenAPI/Swagger analysis does not inspect database drivers directly, but when runtime checks detect unencrypted external connections or missing encryption controls, the Encryption and Data Exposure checks highlight the issue. This becomes critical when the application is deployed in environments where network segmentation is weak or where shared infrastructure increases exposure.
Compliance frameworks such as OWASP API Top 10 and PCI-DSS require protection of data in transit. Without TLS, the API and database connections fail these requirements, increasing regulatory risk. middleBrick maps findings to these frameworks and provides remediation guidance rather than attempting to fix the configuration itself. The scanner’s Encryption check looks for indicators like disabled sslmode or missing certificate validation, while the Data Exposure check observes whether sensitive information could be exposed during normal operation.
Cockroachdb-Specific Remediation in Fiber — concrete code fixes
To secure a Fiber application communicating with CockroachDB, enforce TLS on both the client and server sides. On the server, ensure CockroachDB is started with TLS certificates and that secure ports are used. On the client, configure the database driver to require and validate TLS. Below are concrete, working examples using the pq driver with Go and GORM, and the pgx-based approach with sqlx.
Example 1: Fiber with GORM and PostgreSQL driver (sslmode=verify-full)
package main
import (
"gorm.io/driver/postgres"
"gorm.io/gorm"
"log"
)
func main() {
// Use a connection string that enforces TLS verification.
// Provide paths to your CA, client certificate, and client key if using mutual TLS.
dsn := "host=cockroachdb.example.com port=26257 user=root dbname=defaultdb sslmode=verify-full sslrootcert=/path/to/ca.crt sslcert=/path/to/client.crt sslkey=/path/to/client.key"
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
if err != nil {
log.Fatalf("failed to connect: %v", err)
}
var result struct {
ID int64
Name string
}
if err := db.Table("users").Where("id = ?", 1).First(&result).Error; err != nil {
log.Fatalf("query failed: %v", err)
}
log.Printf("User: %+v", result)
}
Example 2: Fiber with database/sql and pgx (native driver)
package main
import (
"context"
"database/sql"
"log"
"net/http"
"github.com/jackc/pgx/v5/stdlib"
"github.com/gofiber/fiber/v2"
)
func main() {
// Configure pgx to require TLS and use system certificates or a custom root.
connConfig, err := pgx.ParseConfig("postgresql://root@cockroachdb.example.com:26257/defaultdb?sslmode=require")
if err != nil {
log.Fatalf("failed to parse config: %v", err)
}
connConfig.TLSConfig = &tls.Config{
RootCAs: loadSystemCertPool(), // load your custom CA bundle if needed
}
db := sql.OpenDB(connConfig)
defer db.Close()
app := fiber.New()
app.Get("/user/:id", func(c *fiber.Ctx) error {
var name string
err := db.QueryRowContext(c.Context(), "SELECT name FROM users WHERE id = $1", c.Params("id")).Scan(&name)
if err != nil {
return c.Status(http.StatusInternalServerError).SendString("database error")
}
return c.JSON(fiber.Map{"name": name})
})
log.Fatal(app.Listen(":3000"))
}
func loadSystemCertPool() *tls.CertPool {
pool, _ := tls.SystemCertPool()
if pool == nil {
pool = tls.NewCertPool()
}
// Optionally append custom CA certs here.
return pool
}
Server-side considerations
On the CockroachDB server, enable TLS by providing certificates and configuring secure ports in the cluster startup flags or configuration. Ensure that your application’s certificate validation is strict (e.g., verify the server hostname) to prevent man-in-the-middle attacks. middleBrick’s findings related to Encryption and Data Exposure guide you toward these configurations by highlighting missing protections in observed endpoints and connections.
Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |