Padding Oracle in Fastapi with Api Keys

A padding oracle occurs when an application reveals whether decryption padding is valid during decryption. In FastAPI, using API keys for authentication does not protect encrypted data handling; if you encrypt or sign sensitive data (e.g., session tokens, API keys, or JWTs) with a block cipher in an insecure mode and expose an endpoint that returns distinct error messages for padding failures versus other errors, you create a padding oracle surface.

Consider a FastAPI endpoint that accepts an encrypted payload in a header or body, decrypts it using a symmetric cipher such as AES-CBC, and then uses the decrypted data. If the server responds with a 400 Bad Request for invalid padding and a 401 Unauthorized for invalid authentication, an attacker can perform adaptive chosen-ciphertext attacks by submitting modified ciphertexts and observing the HTTP status codes. The presence of API keys does not mitigate this; API keys may identify the caller, but if the decryption logic leaks padding validity, an unauthenticated attacker can still exploit the oracle to recover plaintext or forge tokens.

For example, an endpoint that decrypts a cookie value with AES-CBC and then validates an API key in a header can be abused: the API key check may occur after decryption, and if the server returns different responses for padding errors (e.g., malformed token) versus authentication failures, the distinction becomes an oracle. This can lead to recovery of sensitive information such as authentication tokens or API keys, potentially enabling privilege escalation or account takeover. The vulnerability is not about the API key mechanism itself, but about how errors are handled after decryption.

Even when using higher-level frameworks that provide encryption utilities, incorrect implementation choices — such as using PKCS7 padding validation that throws distinguishable exceptions, or including encrypted data within JWTs without proper integrity protections — can reintroduce padding oracle risks. In FastAPI, ensure that decryption routines use constant-time comparison and do not expose any information about padding validity through status codes or response bodies.

To prevent padding oracle issues in FastAPI when using API keys, focus on error handling and cryptographic hygiene. Never expose different error paths for padding failures versus authentication failures, and use authenticated encryption with associated data (AEAD) where possible.

Example 1: Using HTTPException uniformly to avoid information leakage:

from fastapi import FastAPI, Request, HTTPException, Depends
from fastapi.security import APIKeyHeader
import secrets

app = FastAPI()
api_key_header = APIKeyHeader(name="X-API-Key")

def get_api_key(request: Request):
    return request.headers.get("X-API-Key")

def verify_api_key(api_key: str):
    expected = secrets.compare_digest(api_key, "my-secret-key")
    if not expected:
        # Always use the same HTTP status to avoid leaking error details
        raise HTTPException(status_code=401, detail="Unauthorized")
    return api_key

@app.post("/data")
async def get_data(api_key: str = Depends(verify_api_key)):
    return {"message": "success"}

Example 2: If you must decrypt data, use AES-GCM (AEAD) so there is no padding oracle surface, and ensure errors are uniform:

from fastapi import FastAPI, HTTPException
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
import secrets

app = FastAPI()

def decrypt_data(ciphertext: bytes, key: bytes) -> bytes:
    if len(ciphertext) < 12:
        raise ValueError("ciphertext too short")
    nonce = ciphertext[:12]
    data = ciphertext[12:]
    aesgcm = AESGCM(key)
    try:
        return aesgcm.decrypt(nonce, data, associated_data=None)
    except Exception:
        # Always raise a generic error to avoid padding/oracle-like behavior
        raise ValueError("decryption failed")

@app.post("/secure")
async def secure_endpoint(request: Request):
    api_key = request.headers.get("X-API-Key")
    expected_key = "my-secret-key"
    if not secrets.compare_digest(api_key, expected_key):
        raise HTTPException(status_code=401, detail="Unauthorized")

    encrypted = request.headers.get("X-Encrypted")
    if not encrypted:
        raise HTTPException(status_code=400, detail="Bad request")

    try:
        key = expected_key.encode()  # derive properly in practice
        plaintext = decrypt_data(encrypted.encode(), key)
        return {"plaintext": plaintext.decode()}
    except Exception:
        # Use a generic 400 to avoid leaking padding or decryption details
        raise HTTPException(status_code=400, detail="Bad request")

Key remediation steps:

• Use AEAD ciphers (AES-GCM, ChaCha20-Poly1305) to eliminate padding oracles.
• Ensure all authentication and decryption error paths return the same HTTP status code and generic message.
• Use constant-time comparison for API key validation (e.g., secrets.compare_digest).
• Do not include stack traces or internal details in responses.
• Validate and bound input lengths before processing.