Problem:
HTTP requests against the DocuWare Platform of a Cloud system return status code 403 - Forbidden with the response message “Request blocked by DocuWare firewall”.
Example:
curl https://{{url}}/docuware/platform/Organizations -H "Authorization: Bearer {{AccessToken}}" -H "Accept: application/json\r\n"
403 - Request blocked by DocuWare firewall
Root Cause:
This behaviour occurs as the DocuWare firewall rejects requests containing potential request-splitting attacks and can be caused by one or more request headers using CRLF to send multi-line strings.
.NET/ApplicationsInsights: Most likely your .NET / App Insights–style instrumentation is adding a legacy distributed‑tracing header. Older .NET/App Insights stacks propagate baggage in the non‑standard Correlation-Context header. Keys/values in that header are URL‑encoded. %0D%0A is the URL‑encoded value for CRLF, which many WAFs/firewalls flag as request‑splitting and will block.
The specific key you are most likely seeing is traceStartInfo, which is a baggage entry name. (It’s a Microsoft‑side diagnostic concept; you’ll see the same name in .NET tracing code paths.).
- The legacy .NET propagator (and older Application Insights SDKs, that rely on it) writes application baggage into the Correlation-Context request header, e.g. Correlation-Context: name1=value1,name2=value2… with URL‑encoded values. If a value contains CR/LF, it becomes %0D%0A, which the DocuWare firewall treats as suspicious.
- The industry standard today is W3C Trace Context + W3C Baggage, i.e. propagate tracing via traceparent/tracestate and send baggage in a separate baggage header (not Correlation-Context). Newer .NET versions defaults moved in that direction.
- Starting with .NET 10, the default propagator is W3C (uses baggage, not Correlation-Context). If you still see Correlation-Context, you’re likely on an older runtime, using older instrumentation, or explicitly opting into the legacy propagator.
More information on the Correlation-Context http header can be found here: https://github.com/AloisReitbauer/distributed-tracing/blob/master/correlation_context/HTTP_HEADER_FORMAT.md
General Solution:
Disallow multi-line strings in all HTTP headers by avoiding all CRLF values in HTTP headers.
.NET Solution A: Stop emitting Correlation-Context and switch to W3C
Upgrade your runtime/instrumentation so the default is the W3C propagator, or set it explicitly on app startup. This causes baggage to flow via the baggage header and tracing via traceparent/tracestate, eliminating the legacy Correlation-Context header.
If you’re instrumented with OpenTelemetry or Azure Monitor’s OTel distro, keep only the W3C propagators (TraceContext + Baggage). That avoids Correlation-Context entirely.
For further information, see here.
.NET Solution B: Keep legacy implementation, but sanitise what you put into baggage
If you must keep Correlation-Context for compatibility, ensure you never add CR or LF to baggage values. Search your code for something like Activity.Current?.AddBaggage("traceStartInfo", …). Strip \r/\n and avoid multi‑line strings.
.NET Solution C: Remove multi-line strings from header values
Make sure to sanitise all headers to remove CR\LF from any values of HTTP headers.
Application Insights JS Solution:
If the header originates from the browser via the Application Insights JS SDK, you can temporarily disable correlation headers or the scope where they are added. The SDK decides whether it may add correlation headers. Controlling these settings prevents emitting problematic headers to certain origins.
new ApplicationInsights({
config: {
// ..
disableCorrelationHeaders: true
}
});