Timing Attack in Fiber with Cockroachdb

A timing attack in the context of a Fiber application using CockroachDB can arise when authentication or data-access logic performs variable-time operations based on attacker-controlled input. For example, comparing a user-supplied token or password with a stored value using a naive string comparison can leak information through response time differences. If the comparison short-circuits on the first mismatched byte, an attacker can measure response times to infer how many initial characters match, eventually recovering the secret.

When this pattern is used to authorize access to CockroachDB — for instance, selecting a user row by an API key or username and then conditionally returning data — the timing difference can correlate with database-side behavior. Even if CockroachDB queries themselves are constant-time, the application-layer logic that builds queries and processes results may not be. An attacker might send many requests with slightly altered identifiers and observe small variations in total response time, which includes network latency, Fiber middleware processing, and CockroachDB query execution. By statistically analyzing these timings, the attacker can infer valid usernames or token prefixes, especially when the API endpoint does not enforce uniform delays or rate limits.

In a real-world scenario, an endpoint like /api/user/{username} might run a CockroachDB query to fetch a user record and then compare a stored API key with one provided in a header. If the comparison is not constant-time and the database query time is stable, the primary timing leak comes from the application code. An attacker can send many requests with guessed usernames and measure response times to identify valid usernames. Once a username is known, further attacks such as credential stuffing or privilege escalation become easier. This becomes more relevant when combined with other checks in middleBrick’s 12 security scans, such as Authentication and BOLA/IDOR, which highlight inconsistent authorization and data exposure risks.

middleBrick can detect such issues during an unauthenticated scan by analyzing authentication endpoints and looking for variable-time behaviors in responses. Its checks include Authentication, Input Validation, and BOLA/IDOR, which can surface endpoints where timing differences might aid enumeration. Because middleBrick tests the unauthenticated attack surface and runs 12 security checks in parallel, it can flag endpoints where response times vary with invalid inputs and provide prioritized findings with remediation guidance.

To mitigate timing-related risks in a Fiber application that uses CockroachDB, focus on ensuring constant-time operations at the application layer and designing queries that avoid branching on secret-dependent conditions. Below are concrete code examples that demonstrate secure patterns.

Constant-time token comparison

Instead of using a simple equality check or early-exit string comparison, use a constant-time comparison function. In Go, you can use subtle.ConstantTimeCompare from the standard library to compare byte slices in constant time.

import (
    "crypto/subtle"
    "net/http"
)

func validateAPIKey(provided, stored string) bool {
    if len(provided) != len(stored) {
        // Use a constant-time comparison helper to avoid leaking length
        return subtle.ConstantTimeCompare([]byte(provided), []byte(stored)) == 1
    }
    return subtle.ConstantTimeCompare([]byte(provided), []byte(stored)) == 1
}

Use this function after retrieving the stored key from CockroachDB. Do not return early based on mismatched lengths, and ensure the comparison always takes the same amount of time regardless of input.

Safe CockroachDB query with parameterized inputs

Always use parameterized queries to avoid SQL injection and ensure stable execution paths. With CockroachDB and the pgx driver in Fiber, prepare queries with placeholders and bind values explicitly.

import (
    "context"
    "github.com/jackc/pgx/v5"
    "github.com/gofiber/fiber/v2"
)

type User struct {
    ID       int64
    Username string
    APIKey   string
}

func getUserByUsername(ctx context.Context, conn *pgx.Conn, username string) (User, error) {
    var user User
    row := conn.QueryRow(ctx, "SELECT id, username, api_key FROM users WHERE username = $1", username)
    err := row.Scan(&user.ID, &user.Username, &user.APIKey)
    return user, err
}

func handler(c *fiber.Ctx) error {
    username := c.Params("username")
    user, err := getUserByUsername(c.Context(), dbConn, username)
    if err != nil {
        // Return a generic error and a constant-time response path
        return c.SendStatus(fiber.StatusUnauthorized)
    }
    // Do not expose which part failed; use the same status for not-found and server errors
    return c.JSON(fiber.Map{"id": user.ID, "username": user.Username})
}

This pattern ensures that query construction does not vary with input and that errors are handled in a way that does not leak information about existence or ownership. Avoid branching logic that returns different HTTP statuses based on whether a user exists; instead, use a uniform unauthorized response.

Uniform response times and rate limiting

To reduce timing noise observable to an attacker, ensure that all responses — whether the username exists, the key is wrong, or an error occurs — take approximately the same amount of time. Add a small, constant delay or perform a constant-time dummy computation before responding. Combine this with rate limiting to make statistical measurements harder.

import (
    "time"
    "github.com/gofiber/fiber/v2"
)

func uniformDelay(c *fiber.Ctx) error {
    // Constant-time dummy work to obscure timing differences
    dummy := make([]byte, 1024)
    for i := range dummy {
        dummy[i] = byte(i & 0xff)
    }
    time.Sleep(50 * time.Millisecond) // adjust to a safe baseline
    return c.Next()
}

Placing such middleware on authentication-sensitive routes can reduce the signal available to an attacker. Combine this approach with the secure query patterns above and validate inputs strictly to close the attack surface covered by middleBrick’s Input Validation and BOLA/IDOR checks.