Crlf Injection in Strapi with Basic Auth

Crlf Injection occurs when user-controlled data is reflected in HTTP headers without sanitization, allowing an attacker to inject newline characters (CRLF: \r\n) to append or split header lines. In Strapi, when Basic Authentication is used for an endpoint and a username or password value is reflected in a response header (for example via a custom header or an error message), an attacker can supply CRLF sequences to inject additional headers such as Set-Cookie or Location. This becomes a security boundary issue because the injected headers may bypass intended access controls or enable session fixation or open redirects.

Consider a Strapi custom route that echoes a user-supplied parameter into a header while Basic Auth credentials are validated. If the username is directly concatenated into a header value and the response is returned without validation, a payload like admin%0D%0aX-Injected:%20true (where %0D%0a encodes CRLF) can create a second header line. Because Basic Auth typically relies on the server to validate credentials before application logic runs, the injected header may be processed after authentication, leading to unintended behavior. For instance, an injected Location header could cause a redirect to a malicious site, or an injected Set-Cookie could set a session-related cookie without proper scope or security attributes.

In the context of middleBrick’s 12 security checks, Crlf Injection is flagged under Input Validation and Data Exposure. The scanner tests unauthenticated attack surfaces and, when Basic Auth endpoints are included in the scan target, it probes for header-splitting by submitting CRLF sequences in parameters that could flow into headers. If the response contains duplicated or split headers, middleBrick reports a high-severity finding and references relevant attack patterns such as response splitting. The tool also cross-references findings with the OpenAPI spec, confirming which endpoints declare header usage and whether user input is reflected. This helps prioritize remediation where authentication and header reflection intersect.

Real-world impact aligns with OWASP API Top 10 categories such as API1:2023 – Broken Object Level Authorization and API5:2023 – Broken Function Level Authorization, because injected headers can manipulate authorization flows. Although middleBrick detects and reports these patterns, it does not fix the code; it provides remediation guidance to properly sanitize and validate inputs before they reach header construction logic.

Remediation focuses on ensuring that any user-controlled data that could reach HTTP headers is strictly validated and sanitized. Do not directly interpolate username, password, or any derived values into header names or values. Instead, treat header construction as a separate security boundary and encode or remove characters that enable line folding.

For Strapi controllers that use Basic Auth, validate credentials using a constant-time comparison where possible and avoid reflecting untrusted input in headers. Below are two Strapi code examples illustrating risky behavior and a secure alternative.

Risky example: reflecting user input into a custom header

// ❌ Risky: username reflected into a custom header without sanitization
module.exports = {
  customAction: async (ctx) => {
    const { username } = ctx.request.body; // user-controlled
    const authUser = await strapi.entityService.findOne('api::user.user', username);
    const basicHeader = ctx.request.headers['authorization'] || '';
    // Some logic that uses basicHeader and username
    ctx.set('X-User-Name', username); // Vulnerable to CRLF injection
    ctx.body = { ok: true };
  },
};

Secure example: sanitizing and avoiding header injection

// ✅ Secure: strip or encode CRLF characters and avoid reflecting untrusted input
const sanitizeHeaderValue = (value) => {
  if (typeof value !== 'string') return value;
  return value.replace(/[\r\n]+/g, '');
};

module.exports = {
  customAction: async (ctx) => {
    const { username } = ctx.request.body;
    const authUser = await strapi.entityService.findOne('api::user.user', { where: { username } });
    const basicHeader = ctx.request.headers['authorization'] || '';

    const safeUsername = sanitizeHeaderValue(username);
    // Only use safeUsername for non-header purposes, e.g., logging
    strapi.log.debug(`Processing user: ${safeUsername}`);

    // Do not set headers with untrusted input; if you must, sanitize rigorously
    ctx.set('X-Request-Status', 'processed');
    ctx.body = { ok: true };
  },
};

Additionally, ensure that any custom authentication middleware or plugins that integrate with Strapi’s auth layer do not concatenate user input into headers. Use framework-provided mechanisms for session management and avoid setting cookies or redirects based on raw user input. When using middleBrick’s CLI to scan strapi endpoints with Basic Auth, you can run middlebrick scan <url> to detect header-splitting issues and then apply the above patterns to close the gap.

If your workflow involves CI/CD, the middleBrick GitHub Action can add API security checks and fail builds if a high-severity Crlf Injection finding appears. This helps catch regressions before deployment while keeping your pipeline aligned with frameworks like OWASP API Top 10 and compliance mappings such as PCI-DSS and SOC2.