Crlf Injection in Fastapi with Firestore

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) characters into an HTTP header or a downstream system that interprets these sequences as line breaks. In a Fastapi application that interacts with Google Firestore, the risk arises when user-controlled input is reflected into Firestore document IDs, field values, or metadata that later influence HTTP responses or logs without proper sanitization.

Fastapi itself does not automatically sanitize inputs used to construct Firestore operations. If a route accepts a parameter such as a document ID or a field value and passes it directly to Firestore, an attacker can supply strings like admin%0d%0aSet-Cookie:%20session=evil. When the application uses this value in a context that later affects an HTTP response—such as logging the document ID into a response header or using it to build a redirect—CR and LF characters can cause header splitting. This can lead to cache poisoning, session fixation, or HTTP response splitting, which are common manifestations of Crlf Injection.

Moreover, when Firestore data is used to construct log entries or error messages that are output to a client or a monitoring system, injected CRLF sequences can fragment log lines and potentially enable log injection attacks. These fabricated log entries can obscure real events or trigger misinterpretation in log-based monitoring tools. Although Firestore does not interpret CRLF as a command delimiter in its own data model, the downstream usage of unsanitized data in HTTP or logging contexts creates the vulnerability chain.

The combination of Fastapi's dynamic routing and Firestore's flexible document schema increases the attack surface if developers assume that Firestore's schema validation provides security against injection. Firestore validates data types and constraints but does not treat CRLF as a prohibited character in strings. Therefore, the responsibility to sanitize and validate input before it reaches Firestore—and before it is echoed into any network or log context—falls on the application layer in Fastapi.

Remediation focuses on strict input validation, context-aware encoding, and avoiding direct reflection of user input into HTTP headers or logs. Below are concrete, Firestore-aware examples for Fastapi.

1. Validate and sanitize document IDs and field values

Reject or transform any user input that contains CRLF characters before using it in Firestore operations. Use a strict allowlist for document IDs, such as alphanumeric characters and a limited set of safe symbols.

import re
from fastapi import FastAPI, HTTPException
from google.cloud import firestore

app = FastAPI()
db = firestore.Client()

SAFE_ID_PATTERN = re.compile(r'^[a-zA-Z0-9_-]{1,100}$')

def is_safe_document_id(doc_id: str) -> bool:
    return bool(SAFE_ID_PATTERN.match(doc_id))

@app.post("/users/{user_input_id}")
async def create_user(user_input_id: str):
    if not is_safe_document_id(user_input_id):
        raise HTTPException(status_code=400, detail="Invalid document ID")
    doc_ref = db.collection("users").document(user_input_id)
    # Safe: user_input_id has been validated
    doc_ref.set({"name": "example", "email": "[email protected]"})
    return {"id": user_input_id}

2. Encode data before logging or echoing into responses

If you must include Firestore document IDs or field values in logs or HTTP responses, apply context-specific encoding. For HTTP headers, use token68 or percent-encode as appropriate; for logs, replace CRLF with safe placeholders.

import firebase_admin
from firebase_admin import credentials, firestore
from fastapi import FastAPI
import logging

cred = credentials.Certificate("path/to/serviceAccountKey.json")
firebase_admin.initialize_app(cred)
db = firestore.client()

logger = logging.getLogger("api")

@app.get("/items/{doc_id}")
async def get_item(doc_id: str):
    doc = db.collection("items").document(doc_id).get()
    if not doc.exists:
        raise HTTPException(status_code=404, detail="Not found")
    # Safe logging: replace CRLF before emitting
    safe_id = doc_id.replace("\r", "\\r").replace("\n", "\\n")
    logger.info(f"Retrieved item id={safe_id}")
    return {"id": doc_id, "data": doc.to_dict()}

3. Use Firestore transactions with validated inputs

When performing conditional writes, ensure that all data used in transaction updates has been validated. Avoid constructing Firestore field values from raw user input that may contain CRLF.

@app.post("/update-profile")
async def update_profile(user_id: str, bio: str):
    if "\r" in bio or "\n" in bio:
        raise HTTPException(status_code=400, detail="Bio contains invalid characters")
    doc_ref = db.collection("profiles").document(user_id)
    doc_ref.update({"bio": bio})
    return {"status": "updated"}

4. Leverage Firestore schema rules where applicable

While Firestore Security Rules cannot block CRLF at the protocol level, you can enforce string constraints to reject problematic characters at the database level as a secondary safeguard.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow write: if request.resource.data.name is string &&
                    !request.resource.data.name.matches('[\r\n]') &&
                    request.resource.data.name.size() < 200;
    }
  }
}