The Tell-Tale Heartbeat: Timing Side-Channels in FastAPI API Key

In the world of API security, we often obsess over complex cryptographic failures or massive injection flaws. But sometimes, the most elegant vulnerabilities are born from good intentions. Enter fastapi-api-key, a Python library designed to handle API key management for FastAPI applications. It does what it says on the tin: verifies keys, manages scopes, and generally keeps the riff-raff out.

The developers, seemingly aware of brute-force risks, decided to implement a countermeasure. If someone sends an invalid key, the server shouldn't just reject it; it should stall. The logic is sound in principle: make the attacker wait, and you destroy their throughput. It's a tar pit for bots.

But here is the catch: they only applied the tar pit to the failures. If you presented a valid key, the server would enthusiastically usher you in without delay. This created a binary signal: Fast response = Valid Key. Slow response = Invalid Key. It’s like playing poker against an opponent who pauses for exactly 10 seconds every time they have a bad hand, but slaps their cards down instantly when they have a Royal Flush. You don't need to see their cards to know when to fold.

The vulnerability, tracked as CWE-208 (Observable Timing Discrepancy), resided in the verify_key method of the AbstractApiKeyService class. The code logic was deceptively simple: try to verify the key, and if it fails (raises an exception), sleep for a random interval before raising the error.

This is a textbook side-channel. In a perfect world, a secure comparison functions in 'constant time'—meaning it takes the exact same amount of CPU cycles to reject a fake key as it does to accept a real one. By explicitly injecting asyncio.sleep only into the exception handler, the developers introduced a massive temporal disparity.

While the delay was randomized (jittered), the absence of a delay on the success path created a statistical canyon. A valid request might return in 50ms (processing time). An invalid request might return in 250ms (processing time + sleep). Even across a noisy network (the internet), this 200ms gap is a neon sign blinking 'ACCESS GRANTED' to anyone with a stopwatch and a basic understanding of statistics.

Let's look at the diff. This is where the logic flaw becomes undeniable. In versions prior to 1.1.0, the code looked something like this (simplified for dramatic effect):

# THE VULNERABLE PATTERN
async def verify_key(self, api_key: str, ...):
    try:
        # If this works, we return IMMEDIATELY. Fast.
        return await self._verify_key(api_key, required_scopes)
    except Exception as e:
        # If this fails, we wait. Slow.
        wait = self._system_random.uniform(self.rrd, self.rrd * 2)
        await asyncio.sleep(wait)
        raise e

The fix in version 1.1.0 (Commit 310b2c5c...) was to ensure that everyone waits, regardless of whether they are a VIP or an intruder. It democratizes the suffering.

# THE PATCHED PATTERN
async def verify_key(self, api_key: str, ...):
    try:
        # Verify, but don't return yet
        result = await self._verify_key(api_key, required_scopes)
    except Exception as exc:
        # Wait on failure
        await self._apply_delay()
        raise exc
 
    # Wait on success too! 
    # Now both paths take (Processing + Delay)
    await self._apply_delay()
    return result

By moving the delay logic (now encapsulated in _apply_delay) to execute in both the success path and the exception path, the timing signature is flattened. The server is now equally slow for everyone, destroying the oracle.

How does a hacker actually use this? You might think, "The internet is noisy; latency fluctuates." That is true. A single request is unreliable. But we aren't sending a single request. We are sending hundreds.

The Attack Strategy

1. Baseline: The attacker sends 100 requests with a known invalid key (e.g., AAAAAA). They calculate the average response time. Let's say it's 300ms (network + processing + sleep).
2. Targeting: The attacker has a list of potential key IDs they want to verify (perhaps leaked from logs or predictable sequence IDs).
3. Sampling: For each target ID, they send 50 probes.
4. Analysis:
   • Target A averages 310ms. Result: INVALID.
   • Target B averages 60ms. Result: VALID.

Because the sleep function was using uniform(rrd, rrd * 2), the jitter was substantial, but the minimum sleep time was essentially a floor. The success path would consistently perform under that floor. A standard Z-test or even a simple threshold check would reveal the valid keys with high confidence.

> [!NOTE] > This vulnerability doesn't recover the secret part of the key if the key is a long random string. However, if the system uses KeyID:Secret format, this allows enumeration of valid KeyIDs, drastically reducing the search space for an offline or online brute-force of the secret component.

The CVSS score is a modest 3.7 (Low), mostly because the Attack Complexity is rated High (due to network noise). Don't let that fool you. In a targeted attack against a high-value API, this is a serious leak.

Information Disclosure: Knowing which users or accounts exist on a platform is the first step in a targeted campaign. If I know Company_A_Prod_Key exists, I focus my phishing or brute-force efforts there.

Denial of Wallet: Since the server is forced to sleep on invalid requests, an attacker can flood the server with garbage keys to exhaust thread pools or open connections, leveraging the application's own defense mechanism to cause a Denial of Service (DoS). By fixing the timing leak, the developers also inadvertently solidified the latency penalty for legitimate users, which is a trade-off often required for security.