HIGH crlf injectionfirestore

Crlf Injection in Firestore

Firestore-Specific Remediation

The fix for CRLF injection in Firestore‑backed services is to ensure that any value originating from a Firestore document is properly sanitized before it becomes part of an HTTP header, query string, or log line. The principle is to treat all document data as untrusted and apply encoding or validation appropriate to the target context.

Recommended practices:

  • Header values: Use built‑in HTTP libraries that automatically percent‑encode or reject invalid characters. In Node.js, the http and https modules will throw if a header value contains \r\n. When constructing headers manually, strip or reject new‑line characters:
function safeHeaderValue(value) {
  if (typeof value !== 'string') return String(value);
  // Remove CR and LF characters
  return value.replace(/[\r\n]/g, '');
}

// Usage
const headers = {
  'X-Order-ID': safeHeaderValue(orderId)
};
  • Query strings: Use encodeURIComponent for each parameter value, which will convert \r\n to %0D%0A, preventing them from being interpreted as line terminators.
const query = new URLSearchParams({
  orderId: encodeURIComponent(orderId)
}).toString();
const url = `https://example.com/api?${query}`;
  • JSON bodies: When sending data as JSON, rely on JSON.stringify which properly escapes control characters, including \r\n, as \u000d\u000a. Avoid manual string concatenation.
// Safe
const body = JSON.stringify({ orderId, amount });
// Unsafe – do NOT do this
// const body = `{"orderId":"${orderId}","amount":${amount}}`;
  • Logging: If you stream Firestore changes to a logging service, ensure the logging library treats incoming text as raw data and does not interpret line breaks as separate log entries. Most structured logging libraries (e.g., Winston, Bunyan) handle this automatically when you pass an object rather than a formatted string.

By applying these defenses consistently across all outbound interactions triggered by Firestore events, you eliminate the vector for CRLF injection. middleBrick’s continuous monitoring (available on the Pro plan) can re‑scan your endpoints on a schedule and alert you if a regression introduces unsafe concatenation patterns.

How CRLF Injection Manifests in Firestore

Duplicate heading unintentionally added; please ignore.

Frequently Asked Questions

Can middleBrick detect CRLF injection in Firestore SDK calls made directly from a browser or mobile app?
middleBrick scans the exposed HTTP surface of your API. If your front‑end SDK calls a Cloud Function or REST endpoint that forwards Firestore data, the scanner will see the resulting requests and can detect header splitting there. Pure client‑only Firestore accesses (e.g., direct SDK reads/writes) are not reachable by the black‑box scan because they go through Google’s backend, not your custom server.
What severity does middleBrick assign to a confirmed CRLF injection finding in a Firestore‑backed endpoint?
The severity is based on the observed impact during the scan. If the injection leads to extra headers that can influence downstream systems (e.g., cache poisoning, credential leakage), middleBrick marks it as High. If the injection only appears in a benign context such as a log line that is safely parsed, it may be rated Medium. The report includes the exact evidence so you can assess the risk in your environment.