HTTP Header Checking Disabled¶

Scope and impact¶

In ASP.NET Framework / System.Web, httpRuntime.enableHeaderChecking controls encoding of certain control characters in outgoing headers. Disabling it removes a defense against header injection when untrusted text reaches a header. Actual exploitability also depends on the server and proxy; a disabled setting alone does not demonstrate response splitting.

Configuration example¶

Use the applicable alternative at application level in web.config, retaining other configuration.

Unsafe: disable the framework check.

<configuration>
  <system.web>
    <httpRuntime enableHeaderChecking="false" />
  </system.web>
</configuration>

Safer: preserve the default check.

<configuration>
  <system.web>
    <httpRuntime enableHeaderChecking="true" />
  </system.web>
</configuration>

The setting encodes, rather than generally rejects, affected characters: CR and LF become percent-encoded text. It does not cover the HTTP status line. See Microsoft's EnableHeaderChecking contract.

Validate the intended value¶

Prefer framework header APIs and fixed application-controlled values. For a selectable mode, match complete values against an explicit allowlist; substring matching is insufficient. A syntactically valid redirect destination still needs a destination policy. Do not treat newline encoding as URL validation, authorization or protection for response bodies.

In an isolated application test, exercise the actual server/proxy path with harmless control-character fixtures and confirm they cannot introduce another header. Verify ordinary values still work. Keep the feature enabled when another layer already rejects those fixtures.

This is a legacy System.Web configuration rule. ASP.NET Core has a different HTTP stack; review its header APIs and deployment behavior instead of copying this setting. See open redirects for destination validation and HTML injection for body output.