Crlf Injection in Flask with Firestore

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) characters into an HTTP response header. In a Flask application that integrates with Google Cloud Firestore, this typically happens when user-controlled data—such as a document ID, query parameter, or Firestore field value—is reflected into headers like Location, or used to compose redirect URLs without proper sanitization.

Consider a Flask route that retrieves a Firestore document and redirects to a derived resource. If the document ID or a field value contains \r\n sequences and the app directly uses that value to build a Location header, the injected CRLF can split the header and inject new headers or a crafted body. For example:

from flask import Flask, request, redirect
from google.cloud import firestore

app = Flask(__name__)
db = firestore.Client()

@app.route("/redirect")
def redirect_to_document():
    doc_id = request.args.get("id", "")
    # Unsafe: doc_id may contain \r\n
    return redirect(f"/doc/{doc_id}")

If an attacker supplies ?id=abc\r\nX-Content-Type-Options:nosniff, the Location header can be split, and a new header is injected. This can facilitate response splitting, cache poisoning, or XSS when the response is later rendered in a browser context.

Because Firestore document IDs and field values are often used in application logic and exposed to clients, they become an effective injection vector. An attacker might store a crafted value in Firestore (e.g., via a public document or an otherwise compromised write path) and then trigger a Flask route that uses that value in a header. The risk is compounded if the Flask app also sets cookies or other headers based on Firestore data, because the injected CRLF can terminate a header line and begin a new one, bypassing intended security controls.

Moreover, if the application uses Firestore-generated IDs or paths in redirects or JSON responses that include user-controlled origins, the CRLF injection can lead to session fixation or open redirects. The attack surface is not limited to the initial request; if any Firestore field is reflected into headers or initial lines of an HTTP response, the vulnerability persists across the data flow.

Remediation centers on strict validation and encoding of any data derived from Firestore before it is placed into HTTP headers, cookies, or redirect targets. Never trust document IDs or field values, even if they originate from internal writes or are perceived as non-user input.

First, validate identifiers to ensure they do not contain control characters. For document IDs used in redirects, enforce an allowlist or reject sequences containing \r or \n:

from flask import Flask, request, redirect, abort
from google.cloud import firestore
import re

app = Flask(__name__)
db = firestore.Client()

def is_safe_doc_id(doc_id: str) -> bool:
    # Reject CR or LF and common path traversal patterns
    return re.match(r"^[a-zA-Z0-9\-_~]+$", doc_id) is not None

@app.route("/doc")
def view_document():
    doc_id = request.args.get("id", "")
    if not is_safe_doc_id(doc_id):
        abort(400, "Invalid document identifier")
    doc_ref = db.collection("docs").document(doc_id)
    doc = doc_ref.get()
    if not doc.exists:
        abort(404)
    return f"Viewing document: {doc_id}"