HIGH missing tlsgincockroachdb

Missing Tls in Gin with Cockroachdb

Missing Tls in Gin with Cockroachdb — how this specific combination creates or exposes the vulnerability

When a Gin application connects to CockroachDB without TLS, credentials and query metadata can traverse the network in cleartext. This specific combination becomes high-risk in environments where the database is reachable from untrusted networks or when the application is deployed in distributed setups across nodes and regions. Without encryption in transit, an attacker who can observe or intercept traffic may capture connection parameters, including usernames and passwords, and potentially modify queries in-flight.

Gin does not enforce transport-layer protections itself; it relies on the underlying database driver configuration. CockroachDB supports TLS-encrypted connections and requires explicit configuration to use certificates and secure endpoints. If the application uses a non-TLS address (e.g., host:26257) or omits certificate parameters, the Go SQL driver opens a plaintext session. In a microservice architecture where service discovery or API gateways expose database connection details to logs or environment variables, missing TLS increases the attack surface for credential harvesting and session hijacking.

Moreover, API security scans performed by middleBrick test unauthenticated endpoints and configurations. If your API or backend service exposes database-related endpoints or debug routes that leak connection strings or error messages containing host details, middleBrick can detect Missing TLS as an exposed attack surface. The scanner checks encryption controls across the stack, including transport security between application components and third-party databases. Findings include the absence of TLS enforcement and missing certificate validation, which map to OWASP API Security Top 10 and relevant compliance frameworks.

Cockroachdb-Specific Remediation in Gin — concrete code fixes

To secure Gin applications connecting to CockroachDB, enforce TLS by configuring the connection string with secure parameters and providing certificates. The following example demonstrates a correct setup using the pgx driver with TLS mode require and custom root certificates.

// tlsConfig.go
package main

import (
    "crypto/tls"
    "crypto/x509"
    "io/ioutil"
    "os"

    "github.com/jackc/pgx/v5/pgxpool"
)

func newSecurePool() (*pgxpool.Pool, error) {
    // Load server CA certificate
    caCert, err := ioutil.ReadFile("./certs/ca.crt")
    if err != nil {
        return nil, err
    }
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)

    tlsConfig := &tls.Config{
        RootCAs:    caCertPool,
        ServerName: "cockroachdb.public.cloud.example.com",
    }

    connString := "postgresql://myuser:mypassword@cockroachdb-host:26257/mydb?sslmode=require"
    // For full verification use sslmode=verify-full and provide cert/key if needed
    config, err := pgxpool.ParseConfig(connString)
    if err != nil {
        return nil, err
    }
    config.ConnConfig.TLSConfig = tlsConfig

    pool, err := pgxpool.NewWithConfig(context.Background(), config)
    if err != nil {
        return nil, err
    }
    return pool, nil
}

func main() {
    pool, err := newSecurePool()
    if err != nil {
        os.Exit(1)
    }
    defer pool.Close()

    // Use pool for queries
    var greeting string
    err = pool.QueryRow(context.Background(), "SELECT 'Hello, secure CockroachDB!'").Scan(&greeting)
    if err != nil {
        os.Exit(1)
    }
    println(greeting)
}

Ensure that CockroachDB certificates are properly provisioned and that the server hostname matches the certificate's Common Name or Subject Alternative Name. When deploying via Kubernetes or container orchestration, mount the CA certificate as a secret and reference it in the application configuration rather than embedding paths or credentials in environment variables.

Using middleBrick's GitHub Action can help enforce that TLS-enabled endpoints are validated during CI/CD. You can add API security checks to your CI/CD pipeline and fail builds if risk scores fall below your defined thresholds, which includes encryption gaps involving backend dependencies. For teams managing multiple services, the Pro plan's continuous monitoring tracks changes in encryption settings and alerts on regressions.

Related CWEs: encryption

CWE IDNameSeverity
CWE-319Cleartext Transmission of Sensitive Information HIGH
CWE-295Improper Certificate Validation HIGH
CWE-326Inadequate Encryption Strength HIGH
CWE-327Use of a Broken or Risky Cryptographic Algorithm HIGH
CWE-328Use of Weak Hash HIGH
CWE-330Use of Insufficiently Random Values HIGH
CWE-338Use of Cryptographically Weak PRNG MEDIUM
CWE-693Protection Mechanism Failure MEDIUM
CWE-757Selection of Less-Secure Algorithm During Negotiation HIGH
CWE-261Weak Encoding for Password HIGH

Frequently Asked Questions

Can middleBrick detect Missing TLS in a Gin + Cockroachdb deployment?
Yes. middleBrick scans the unauthenticated attack surface and checks encryption controls, including transport security between application components and databases. Missing TLS configuration is flagged as a finding with severity and remediation guidance.
Does middleBrick fix Missing TLS automatically?
No. middleBrick detects and reports findings with remediation guidance. It does not fix, patch, block, or remediate issues. You must apply configuration changes such as enforcing TLS in your database connection strings.