Timing Attack in Fastapi with Cockroachdb

A timing attack in the combination of Fastapi and Cockroachdb arises when authentication or lookup operations use data-dependent branching or variable-time operations. 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 mismatching character, an attacker can measure round-trip times and infer how many initial characters match, eventually recovering the secret. This becomes relevant when Fastapi endpoints interact with Cockroachdb, because the database driver and query construction can introduce additional timing variance.

Consider a login endpoint that queries Cockroachdb for a user by username and then compares the provided password (or a derived token) in application code. A query like SELECT password_hash FROM users WHERE username = $1 is deterministic in execution time on Cockroachdb, but the subsequent comparison in Fastapi is not. An attacker can send many login requests while measuring response times; consistently longer responses may indicate a partial match, enabling an offline brute-force or dictionary attack against hashes. Even if Cockroachdb returns results quickly, the application-layer comparison dominates the timing behavior.

Another scenario involves ID-based lookups where object-level permissions are evaluated after retrieving a record. If the existence or ordering of rows affects branch decisions (e.g., looping over results or conditionally processing rows), subtle timing differences can correlate with data presence or ownership. Cockroachdb’s consistent latency under load does not eliminate these application-side leaks. In distributed deployments, network jitter is usually larger than database-side timing variance, so attackers often target the application logic rather than the database execution time. Tools such as middleBrick can detect these issues by scanning the unauthenticated attack surface of your Fastapi endpoints and flagging inconsistent response patterns that align with timing-based information leakage.

Middleware or instrumentation that standardizes response times is not always sufficient if the comparison logic or query path still exhibits data-dependent behavior. For instance, using constant-time comparison for tokens and avoiding early-exit loops when processing query results is essential. Frameworks like Fastapi do not automatically enforce constant-time practices, and Cockroachdb drivers return results as soon as they are available, which can amplify subtle timing differences in application code. MiddleBrick’s checks include input validation and property authorization tests that help surface timing-related inconsistencies across endpoints that rely on Cockroachdb for data retrieval.

To mitigate timing attacks in Fastapi when using Cockroachdb, ensure all sensitive comparisons are performed in constant time and that queries do not leak information via timing or error behavior. Below are concrete, realistic code examples for a secure login flow.

First, use a constant-time comparison for secrets such as password hashes or API tokens. Python’s hmac.compare_digest is suitable and avoids early-exit vulnerabilities:

import hmac
from fastapi import FastAPI, Depends, HTTPException, status
from pydantic import BaseModel
import asyncpg

app = FastAPI()

async def get_pool():
    return await asyncpg.create_pool(
        user='app_user',
        password='**',
        host='cockroachdb-host',
        port=26257,
        database='app_db',
        command_timeout=30
    )

class LoginRequest(BaseModel):
    username: str
    password: str  # In practice, use a hashed/stored representation or token

@app.post('/login')
async def login(body: LoginRequest):
    pool = await get_pool()
    async with pool.acquire() as conn:
        row = await conn.fetchrow('SELECT password_hash FROM users WHERE username = $1', body.username)
    await pool.close()
    if row is None:
        # Use constant-time comparison even when user is not found to avoid user enumeration
        hmac.compare_digest(b'fakehash', b'fakehash')
        raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail='Invalid credentials')
    stored_hash = row['password_hash'].encode('utf-8')
    provided_hash = body.password.encode('utf-8')
    if not hmac.compare_digest(stored_hash, provided_hash):
        raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail='Invalid credentials')
    return {'status': 'ok'}

This approach ensures that the comparison time does not depend on how many characters of the secret match. Additionally, query patterns should avoid leaking information through different SQL error messages or result set sizes. Use parameterized queries and handle missing rows uniformly, as shown above.

For authorization checks that involve row ownership, avoid branching based on row existence before performing constant-time work. Instead, fetch the row and apply permissions checks in a data-oblivious style where feasible. If you must branch, ensure that the timing does not reveal whether a row exists or is owned. middleBrick’s BOLA/IDOR and Property Authorization checks can help identify endpoints where authorization logic may introduce timing-sensitive paths when interacting with Cockroachdb.

Finally, prefer prepared statements and fixed-latency queries where possible, and validate that drivers and ORMs do not introduce variable-length operations dependent on data values. Combine these practices with runtime scanning using middleBrick to continuously monitor for timing-related anomalies across your Fastapi services that rely on Cockroachdb.