Crlf Injection in Express with Firestore

Crlf Injection occurs when an attacker can inject CRLF sequences (\r\n) into data that is later reflected into headers or logs. In an Express application using Firestore, this typically arises when user-controlled input is used to construct HTTP response headers, log entries, or Firestore document fields that are later read and interpreted by other systems.

Express does not inherently treat Firestore document fields as header values, but developers sometimes write patterns such as res.set(headerField, doc.data().someField) where someField originates from user input and is stored in Firestore. If an attacker manages to write a CRLF-injected value into Firestore—either directly or via an unvalidated endpoint that writes user input into the database—the malicious payload can later be used to inject additional headers or split log entries when the data is read and reflected.

The Firestore client libraries themselves do not introduce Crlf Injection; the risk comes from how application code uses Firestore data downstream. For example, an endpoint that creates a document with user-controlled metadata and then uses that metadata in a header can be abused: a stored value containing X-Inject: 1\r\nSet-Cookie: stolen=1 could cause the server to append an unintended header when the data is later read and used with res.set().

Attack patterns enabled by this combination include response splitting, header manipulation, and log forging. Response splitting can lead to cache poisoning or XSS in some contexts, while log injection can obscure forensic traces. CVE-2022-24999-like patterns (injection via uncontrolled data into HTTP responses) are relevant when Firestore data is used in constructing responses without validation.

Additionally, if an Express app uses Firestore in batch operations or admin contexts where document fields are concatenated into command strings or logging statements, CRLF injection can corrupt structured output and monitoring pipelines. Proper input validation and output encoding at the boundaries—never trusting data retrieved from Firestore—are essential to mitigate these risks.

Remediation focuses on preventing CRLF characters from being written into Firestore from user-controlled sources and ensuring that Firestore data is never directly reflected into HTTP headers without strict validation.

First, validate and sanitize any user input before writing to Firestore. Reject or encode CRLF sequences at the API layer:

const sanitizedValue = userInput.replace(/[\r\n]/g, '');
// or replace with a safe substitute:
const safeValue = userInput.replace(/[\r\n]/g, ' ');

Second, avoid using Firestore fields directly in HTTP response headers. If you must set headers based on document data, use a strict allowlist and normalization:

const allowedHeaders = new Set(['X-Custom-Source', 'X-Request-ID']);
const headerValue = doc.data().source;
if (allowedHeaders.has(headerValue) && !headerValue.includes('\r') && !headerValue.includes('\n')) {
  res.set(headerValue, 'normalized-value');
}

Third, when logging Firestore data, ensure log lines cannot be split by removing or encoding control characters:

const logData = JSON.stringify({
  id: doc.id,
  payload: doc.data().message.replace(/[\r\n]/g, ' ')
});
console.log(logData);

Fourth, enforce schema validation rules in Firestore (where supported) to reject malformed input. Combine this with runtime checks in Express routes:

if (/[\r\n]/.test(req.body.customField)) {
  return res.status(400).send('Invalid characters');
}
await db.collection('items').doc(id).set({ customField: req.body.customField });

Lastly, use the CLI tool to scan your endpoints and verify that no user-controlled Firestore fields are reflected into headers. Run middlebrick scan <url> to detect potential injection vectors in your unauthenticated attack surface.