Header Injection in Fastapi with Jwt Tokens

Header Injection in a FastAPI application using JWT tokens occurs when untrusted input from HTTP headers is used to influence token handling, logging, or downstream service calls. FastAPI relies on standard request objects to access headers, and if header values are directly interpolated into log entries, forwarded requests, or used to dynamically select secrets or endpoints, an attacker can manipulate headers to leak sensitive information or alter behavior.

For example, an API may copy an Authorization header value into a backend call or include it in verbose logs. If the header is not strictly validated, an attacker can inject additional header lines (e.g., via newline characters) to inject extra headers such as X-Forwarded-For or X-Origin. This can lead to data exposure by revealing paths, internal hostnames, or tokens in logs, or enable SSRF by steering outbound requests. Even when JWT tokens are used for inbound authentication, the surrounding request handling must treat headers as untrusted to avoid indirect compromise of token context.

When OpenAPI/Swagger specs are analyzed alongside runtime behavior, discrepancies may reveal relaxed header constraints that are not enforced in the implementation. middleBrick checks such inconsistencies during its 12 parallel security checks, including Data Exposure and Input Validation. This is especially important for unauthenticated attack surface testing, where endpoints accepting public traffic may inadvertently expose token-related logic through header manipulation.

In a microservice chain, a FastAPI service that forwards requests to another service using values from headers (such as a routing hint or tenant identifier) can be abused if newline characters are allowed. An attacker may craft a header like X-Target-Service: accounts\nAuthorization: Bearer leaked_token, attempting to influence the downstream request. Even if JWT tokens are validated locally, poor header sanitization can bypass intended trust boundaries and contribute to data exposure or unauthorized actions, which middleBrick surfaces with severity and remediation guidance.

Because JWT tokens are often passed in the Authorization header as a bearer token, developers may mistakenly assume that once the token is validated, header values are safe to use. This assumption can lead to unsafe consumption patterns where headers are reused without normalization or strict schema enforcement. The LLM/AI Security checks in middleBrick specifically look for scenarios where system prompts or outputs might indirectly reference tokens derived from manipulated headers, ensuring that token handling remains isolated from header-driven logic.

Remediation focuses on strict header validation, avoiding header interpolation, and ensuring JWT token handling remains isolated from external input. Use a defined security policy for allowed headers and reject requests with unexpected or malformed headers.

Example: secure header validation and JWT extraction in FastAPI.

from fastapi import FastAPI, Request, HTTPException, Depends
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import re

app = FastAPI()
security = HTTPBearer()

# Strict allowlist of permitted headers
PERMITTED_HEADERS = {"authorization", "content-type", "accept"}

def validate_headers(request: Request):
    # Reject headers with newline or carriage return to prevent injection
    for name, value in request.headers.items():
        if re.search(r"[\r\n]", value):
            raise HTTPException(status_code=400, detail=f"Invalid header value: {name}")
        if name.lower() not in PERMITTED_HEADERS:
            # Optionally log and reject unexpected headers
            raise HTTPException(status_code=400, detail=f"Unexpected header: {name}")

async def get_current_token(request: Request, credentials: HTTPAuthorizationCredentials = Depends(security)):
    validate_headers(request)
    # credentials.credentials is the raw Authorization header value after "Bearer "
    token = credentials.credentials
    if not token.startswith("ey") and not token.startswith("ey"):
        # Basic sanity check for JWT structure
        raise HTTPException(status_code=401, detail="Invalid token format")
    return token

@app.get("/secure")
async def read_secure(token: str = Depends(get_current_token)):
    # Use token for authorization logic, do not mix with header values
    return {"status": "ok", "token_present": bool(token)}

This pattern ensures that header values are not used to construct dynamic behavior such as logging or routing. JWT tokens are extracted only via a dedicated security dependency, and validation rejects inputs containing newline characters that enable injection. The approach aligns with OWASP API Top 10 controls around Input Validation and Data Exposure.

Additionally, avoid forwarding raw headers to downstream services. If necessary, explicitly map only required headers rather than copying entire header dictionaries. Enforce strict schema checks and use typed models for any forwarded data. middleBrick’s GitHub Action can help enforce these rules in CI/CD pipelines by failing builds if scans detect risky header handling patterns.

For production deployments, combine these code-level practices with runtime monitoring. The Pro plan’s continuous monitoring can alert on abnormal header patterns over time, and the Web Dashboard provides per-category breakdowns to track improvements. Even without paid tiers, the CLI tool allows you to scan endpoints locally with middlebrick scan <url> to verify that header handling conforms to expectations.