Log Injection in Feathersjs with Jwt Tokens

Log injection occurs when an attacker can control or influence data that is written into application or system logs. In FeathersJS applications that rely on JWT tokens for authentication and identity, the risk is compounded because the token payload often contains user identifiers, roles, and claims that may be logged. If these values are written directly into logs without validation or sanitization, attackers can inject malicious payloads such as newlines, structured text, or script-like content. Newline injection can enable log forging or facilitate log poisoning attacks where one user’s actions are attributed to another. Structured payloads containing newline or carriage return characters can break log line boundaries, making it difficult for log aggregation tools to parse entries correctly and potentially obscuring related security events.

When JWT tokens are used, developers sometimes log claims such as sub, email, or role to provide context for each request. If the token’s claims are assumed trustworthy and logged verbatim, an attacker who can influence the token’s payload—perhaps by registering with an email that includes line breaks or by exploiting a weak identity provider flow—can craft input that corrupts log structure. For example, a newline (\n) or carriage return (\r) in an email or username claim can split a single logical log entry into multiple lines, which may break automated parsing and monitoring pipelines. In distributed systems where logs are aggregated centrally, a single poisoned log line can distort analytics, trigger noisy alerts, or interfere with detection rules that rely on consistent log formatting.

FeathersJS does not inherently log JWT claims; however, application-level code that extracts and logs these values creates the exposure. Consider a service hook that logs user identity for audit or debugging purposes. If the hook directly interpolates token claims into log messages without sanitization, it introduces an injection vector. Attackers probing the API can attempt to manipulate identity sources or registration data to include payloads designed to disrupt log processing. Because log injection is often a precursor to more severe issues—such as log forging, log-based security evasion, or disruption of monitoring responsiveness—treating log data as untrusted is essential even when the source appears to be an authenticated JWT token.

Another subtle risk involves structured logging formats such as JSON. If a JWT claim is placed into a structured log object without proper escaping, newline characters embedded in string fields can corrupt the JSON syntax when the log is serialized line-by-line. This can break log ingestion pipelines that expect one JSON object per line. Defensive coding practices in FeathersJS should therefore include canonicalizing and validating identity-related inputs, avoiding direct interpolation of user-controlled claims into logs, and applying consistent output encoding tailored to the logging format. Treating JWT-derived data as untrusted input reduces the likelihood that log injection undermines observability and incident response.

Remediation focuses on ensuring that JWT-derived data is never written to logs in a raw or unescaped form. Instead, sanitize and transform claims before they reach any logging statement. Below are concrete examples for a FeathersJS service hook that safely handles identity information without risking log injection.

// src/hooks/sanitize-logging.js
const escapeLogString = (value) => {
  if (typeof value !== 'string') return value;
  // Replace newlines and carriage returns to prevent log injection
  return value.replace(/[\r\n]+/g, ' ').trim();
};

module.exports = function sanitizeLoggingHook(options = {}) {
  return async context => {
    const { params } = context;
    const user = params.user || {};
    // JWT claims are often attached via an authentication strategy
    const safeUser = {
      id: escapeLogString(user.id ?? ''),
      email: escapeLogString(user.email ?? ''),
      role: escapeLogString(user.role ?? '')
    };
    // Use a structured logger that supports safe serialization
    context.params.logContext = {
      event: 'request_processed',
      service: context.path,
      userId: safeUser.id,
      email: safeUser.email,
      role: safeUser.role
    };
    return context;
  };
};

In this hook, the escapeLogString function removes newline and carriage return characters, which are common primitives for log injection. By applying this function to each JWT-derived claim before placing it into a log context, you ensure that log lines remain intact and parseable. The hook stores the sanitized values in context.params.logContext, which a structured logger can consume without directly interpolating raw user input.

// src/services/chat/chat.service.js
const { authenticate } = require('@feathersjs/authentication').hooks;
const sanitizeLoggingHook = require('../hooks/sanitize-logging');

module.exports = function (app) {
  const options = {
    name: 'chat',
    paginate: { default: 20, max: 50 }
  };

  app.use('/chat', {
    async find(params) {
      // Business logic here
      return [];
    },
    async create(data, params) {
      // Message creation logic
      return {};
    }
  });

  const chatService = app.service('chat');

  // Apply hooks that include authentication and logging safety
  chatService
    .hooks({
      before: {
        all: [authenticate('jwt'), sanitizeLoggingHook()],
        find: [],
        get: [],
        create: []
      },
      after: {
        all: [],
        find: [],
        get: [],
        create: []
      },
      error: {
        all: [],
        find: [],
        get: [],
        create: []
      }
    });
};

This service configuration combines JWT authentication with the sanitization hook. The authenticate('jwt') hook ensures that requests carry valid tokens and attaches user claims to params.user. The subsequent sanitizeLoggingHook processes these claims to remove line-breaking characters before any logging occurs. By centralizing sanitization in a reusable hook, you reduce the risk of accidentally logging raw JWT claims elsewhere in the codebase.

// src/utils/logger.js
const { createLogger, format, transports } = require('winston');

const safeLogger = createLogger({
  level: 'info',
  format: format.combine(
    format.timestamp(),
    format((info, opts) => {
      // Ensure that any residual fields are strings and newline-free
      if (info.userId && typeof info.userId === 'string') {
        info.userId = info.userId.replace(/[\r\n]+/g, ' ');
      }
      if (info.email && typeof info.email === 'string') {
        info.email = info.email.replace(/[\r\n]+/g, ' ');
      }
      return info;
    })()
  ),
  transports: [new transports.Console()]
});

module.exports = safeLogger;

Using a Winston logger with a formatting step that further sanitizes fields adds an extra layer of defense. Even if a sanitization hook is bypassed, the logger will normalize newline characters, preserving log integrity. This approach aligns with the principle that logs should be treated as untrusted output, especially when derived from external authentication mechanisms such as JWT tokens.

Finally, validate and constrain JWT claims at the authentication layer. Enforce email format rules and reject tokens containing suspicious characters during token issuance or verification. By combining input constraints, runtime sanitization, and structured logging practices, FeathersJS applications can safely incorporate JWT-based identity without exposing log injection vectors.