Log Injection in Firestore

The most effective remediation is to ensure that any data originating from Firestore (or any user‑supplied input) is never concatenated directly into a log string. Instead, treat log entries as structured data and let the logging library handle serialization.

Using a structured logger such as pino or winston with JSON output prevents injection because the logger writes each field as a separate JSON key/value pair, escaping characters as needed.

Here is the same endpoint rewritten with safe logging:

const pino = require('pino')();
const admin = require('firebase-admin');
admin.initializeApp();

app.get('/users/:id', async (req, res) => {
  const userDoc = await admin.firestore()
    .collection('users')
    .doc(req.params.id)
    .get();

  // Safe: pass the data as an object, not a concatenated string
  pino.info({ userId: req.params.id, userData: userDoc.data() }, 'Fetched user');

  res.json(userDoc.data());
});

If a simple console.log must be used, escape newlines and control characters before inserting the data:
function escapeForLog(str) {
  return String(str)
    .replace(/[\r\n]/g, '\\n')   // turn newline into escaped \n
    .replace(/[\x00-\x1f\x7f]/g, ch => {
      return '\\u' + ch.charCodeAt(0).toString(16).padStart(4, '0');
    });
}

app.get('/users/:id', async (req, res) => {
  const userDoc = await admin.firestore()
    .collection('users')
    .doc(req.params.id)
    .get();

  const safeData = escapeForLog(JSON.stringify(userDoc.data()));
  console.log(`Fetched user ${req.params.id}: ${safeData}`);

  res.json(userDoc.data());
});

Beyond code changes, consider configuring Firestore security rules to limit what data can be read by unauthenticated clients, reducing the chance that malicious input reaches the log in the first place. A rule that only allows reading of specific fields (e.g., allow read: if request.auth != null && resource.data.keys().hasOnly(['name', 'email'])) prevents attackers from writing arbitrary binary payloads into fields that would later be logged.
Finally, integrate the check into your development workflow:

  
Add the middleBrick GitHub Action to run on pull requests, setting a failure threshold (e.g., score < B).
  
Use the middleBrick CLI in local pre‑commit hooks to catch regressions early.
  
Monitor the Dashboard for score drift over time; a sudden drop may indicate a new logging pathway has been introduced.

By treating log output as structured data and sanitizing any user‑controlled content before it reaches the log, you eliminate the injection vector while retaining the diagnostic value of your logs.