Repository navigation
Newly introduced CsrfTokenInterceptor is producing large amount of warning logs #1270
Description
Describe the Bug
We are consuming the com.sap.cloud.sdk.sdk-bom dependency in our CAP Java microservices. We recently upgraded to version 5.34.0 (from 5.33.0) and started to observe a large amount of warning logs of type: “Target system did not respond with a x-csrf-token header. The subsequent request may fail if a CSRF token is required.” Those seem to originate from the newly introduced CsrfTokenInterceptor.
Unfortunately, we could not find any additional information regarding this change in the release notes or similar. Apart from this, we have some concerns that this results in a big number of requests that are now emitted from this class to the request source to obtain the csrf header.
Best regards,
Felix Starke
Steps to Reproduce
As we are working on an SAP internal project, kindly reach out for further information or discussions.
Expected Behavior
Can you please clarify the need of having this Interceptor and this being an actual warning log. Furthermore, kindly clarify that the amount of HEAD-requests triggered by this is necessary.
Screenshots
No response
Used Versions
- Java and Maven version via
mvn --version: ... - SAP Cloud SDK version: 5.34.0
- Spring Boot or CAP version: Spring Boot 3.5.17 with CDS Services 4.9.4
Code Examples
No response
Stack Trace
No response
Log File
No response
Affected Development Phase
Production
Impact
Impaired
Timeline
No response
Activity
starkef commentedon Sep 4, 2026
@thiagob @cassiofariasmachado we got your contacts from @Jonas-Isr, could you kindly assist us on this?
adamandre79 commentedon Sep 14, 2026
Hello colleagues,
we see the same problem in our service.
Could you please give an update about the progress?
Thanks
André
beckermarc commentedon Sep 16, 2026
We also found that the always-enabled CSRF token interceptor causes a doubling of the HTTP connections that are required to process a request. This caused issues in one of our tests, where we deliberately reduced the HTTP connection pool to 1. Although this is not a realistic scenario, this of course implies that also in production the effective connection pool is halved by that change you did.
Maybe it can be additionally considered to implement the CSRF handling in a way that is not only OData-specific but that consumes only 1 connection at a time (e.g. by fetching the CSRF token, before the connection for the actual request is processed).
starkef commentedon Oct 12, 2026
Hi @ricardosrib, can you share an update on this case? So far we do not observe any updated behavior with 5.35.0.
Thanks and best regards, Felix
ricardosrib commentedon Oct 21, 2026
Hi @starkef,
Thanks for your patience, and apologies for the noise this has caused.
Quick status: the fix for this is implemented in #1281. It scopes the CsrfTokenInterceptor to OData clients only and makes it opt-in (disabled by default) on the general-purpose ApacheHttpClient5 client. So once it ships, non-OData targets will no longer trigger the extra HEAD request or the "did not respond with a x-csrf-token header" warning.
The reason you don't see any change in 5.35.0 is that #1281 was bundled with a larger change (#1275, migrating OData v2/v4 to Apache HttpClient 5), and both were temporarily reverted in #1292. We're re-introducing them together in #1294 and are still validating the changes internally. I'll update this issue with the target release as soon as it's confirmed, and will keep the issue open until then.
Can you confirm whether you're using the Cloud SDK's OData VDM to call external OData services, or are the warnings coming from non-OData HTTP calls?
This matters because #1281 fully resolves the issue for non-OData traffic. However, if your warnings are coming from OData VDM calls to a target that doesn't support CSRF tokens, the interceptor would still be active there by design. In this case, we'd need to look at a different solution for your specific case.
Thanks in advance for the clarification, and I'll keep you informed.
Best Regards