Brute Force Attack in Fastapi with Hmac Signatures

A brute force attack against an FastAPI endpoint that uses HMAC signatures can occur when the server does not adequately protect the signature verification process or the surrounding request handling. In this setup, a client includes an HMAC—typically computed over selected parts of the request (method, path, timestamp, nonce, and body)—as a header (e.g., X-Signature). The server recomputes the HMAC using a shared secret and compares it with the provided value. If the server performs the comparison in a way that is vulnerable to timing attacks or does not enforce sufficient request-rate controls, an attacker can systematically submit many requests, observing response differences to iteratively guess the signature or infer validity.

With HMAC-based authentication in FastAPI, specific conditions can amplify brute force risk. For example, if the server does not enforce global or per-client rate limits and does not require additional anti-replay protections (e.g., strict timestamp and nonce windows), an attacker can flood the endpoint with many distinct payloads and signatures. Even when the HMAC itself is cryptographically strong, the absence of strict input validation and strict enforcement of idempotency keys or one-time nonces can allow repeated attempts. Another scenario: if the application leaks information about signature validity through timing differences, HTTP status codes, or error messages, an attacker can mount adaptive offline attacks where they craft signatures off-server and probe the endpoint to observe subtle timing or behavioral changes that indicate correctness.

Consider a FastAPI route that expects an X-Timestamp, X-Nonce, and X-Signature header. If the server only checks the signature validity without verifying that the timestamp is within a tight window (for example, ±2 minutes) and without ensuring nonces are not reused, an attacker can replay captured requests while slightly altering nonces or timestamps. The server may process each replay as new, enabling many guesses per second. Furthermore, if the endpoint is unauthenticated from a scanning perspective (i.e., no API key or IP-based restriction at the edge), the attack surface is wide, and tools can generate high request volumes, increasing the likelihood of successful brute force or replay attacks despite the presence of HMACs.

These issues are especially relevant when integrating third-party services or when clients implement HMAC incorrectly (e.g., including variable parts that do not normalize consistently). The server must validate not just the cryptographic integrity of the signature but also the freshness and uniqueness of each request. Without these controls, the combination of FastAPI, HMAC signatures, and missing rate-limiting or replay protection creates a path where brute force and replay attacks become practical, potentially leading to unauthorized actions or information disclosure.

To remediate brute force and replay risks with HMAC signatures in FastAPI, implement strict request validation, replay protection, and rate limiting, and ensure constant-time comparison for signatures. Below are concrete, working examples that you can adapt.

1) HMAC verification with constant-time comparison and timestamp/nonce checks:

import time
import hmac
import hashlib
from fastapi import FastAPI, Request, HTTPException, Header
from typing import Optional

app = FastAPI()

SHARED_SECRET = b'your-very-secure-shared-secret'
REPLAY_CACHE = {}  # In production, use a fast, TTL-backed store (e.g., Redis)

def verify_hmac(
    method: str,
    path: str,
    timestamp: str,
    nonce: str,
    body: bytes,
    provided_signature: str
) -> bool:
    # Enforce tight timestamp window (e.g., 2 minutes)
    now = int(time.time())
    try:
        ts = int(timestamp)
    except ValueError:
        return False
    if abs(now - ts) > 120:
        return False
    # Ensure nonce hasn't been used recently (replay protection)
    nonce_id = f"{method}:{path}:{nonce}"
    if nonce_id in REPLAY_CACHE:
        return False
    # Build the signing string exactly as the client did
    message = f"{method}\n{path}\n{timestamp}\n{nonce}\n{body.decode('utf-8', errors='ignore')}"
    expected = hmac.new(SHARED_SECRET, message.encode('utf-8'), hashlib.sha256).hexdigest()
    # Constant-time comparison to avoid timing leaks
    return hmac.compare_digest(expected, provided_signature)

@app.post("/webhook")
async def webhook(
    request: Request,
    x_timestamp: Optional[str] = Header(None, alias="X-Timestamp"),
    x_nonce: Optional[str] = Header(None, alias="X-Nonce"),
    x_signature: Optional[str] = Header(None, alias="X-Signature")
):
    if not all([x_timestamp, x_nonce, x_signature]):
        raise HTTPException(status_code=400, detail="Missing required headers")
    body = await request.body()
    if not verify_hmac(
        method=request.method,
        path=request.url.path,
        timestamp=x_timestamp,
        nonce=x_nonce,
        body=body,
        provided_signature=x_signature
    ):
        raise HTTPException(status_code=401, detail="Invalid signature")
    # Record nonce to prevent replay within the cache TTL
    REPLAY_CACHE[f"{request.method}:{request.url.path}:{x_nonce}"] = time.time()
    return {"status": "ok"}"

2) Global rate limiting by IP and per-client identifiers to reduce brute force feasibility:

from fastapi import FastAPI, Request, HTTPException
from slowapi import Limiter
from slowapi.util import get_remote_address

app = FastAPI()
limiter = Limiter(key_func=get_remote_address)

@app.post("/api/data")
@limiter.limit("30/minute")  # Adjust to your risk tolerance
async def protected_endpoint(request: Request):
    # Your HMAC-verified logic here
    return {"data": "safe"}"

3) Ensure your HMAC construction normalizes inputs to avoid variability-based brute forcing (e.g., sort query parameters, use consistent JSON serialization). Always include a nonce and timestamp, validate them strictly, and return generic error messages to avoid leaking validity hints. For production, replace the in-memory REPLAY_CACHE with a distributed store with TTL matching your timestamp window, and consider adding additional request-idempotency checks for sensitive operations.