The Curious Case of the Unexpected Headers

Updated June 25th, 2019: The scriptFile and scriptFileType headers mentioned below are no longer left behind by the Script step. The variable and data store headers are still returned to outside callers, though.

TL;DR: Some integration flow steps leave behind headers, that contain information about the internals of the integration flow. If you don’t want to leak that information to the outside world, you need to actively remove the headers in question.

The other day, I hooked up an HTTPS sender channel to a simple Cloud Integration integration flow to do some testing. The integration flow reads a variable and executes a Groovy script. Not very exciting at all, it must be said, but it nevertheless led to a finding, that was curious indeed.

When I called the integration flow’s endpoint in Postman, I noticed something unexpected in the HTTP response headers: The name of the Groovy script, and the name and contents of the variable. Here are the headers in question:

• scriptFile → script1.groovy
• scriptFileType → groovy
• MyVariable → Testing123
• SapDataStoreId → MyVariable

(The variable is called MyVariable, and it contains the string Testing123.)

I proceeded to remove all steps except the script step and the Content Modifier step, that reads the variable. I did this in order to make sure, that those two steps had in fact added the headers of their own accord. This turned out to be the case. Now, why these headers are left behind, is less clear at the moment. They might be implementation artifacts, that are not cleaned up.

Further investigation showed, that reading from (Get step) and writing to (Write step) a data store also results in the SapDataStoreId header being added. In those cases, the header contains the ID of the data store entry.

Is this a problem? Probably not in most cases, but Cloud Integration developers should be aware, that these headers can possibly leak information, that we do not expect an outside party to be able to view. Particularly variables and data store entry IDs can potentially contain sensitive information, that should not leave the Cloud Integration tenant.

Fortunately, we can remove these headers, but we need to do so actively. Keep in mind that the Headers tab of the Content Modifier step is not only used to add headers, but also to remove them. In this example, the SapDataStoreId header is removed:

For more detail on how to remove headers, please see this blog post by Praveen Tirumareddy.

If you have noticed other unexpected headers added by integration flow steps, please comment below, and I’ll update this blog post with your discoveries (and attribute them to you, of course).

In case you are interested in more Victorian-era sleuthing, I highly recommend the original Sherlock Holmes books by Arthur Conan Doyle, or the classic Granada Television series featuring the wonderful Jeremy Brett as Holmes.

My fellow SAP Mentor Eng Swee Yeoh provides additional insight into these curious headers in his comment below. Eng Swee’s research shows, that they are indeed used by Cloud Integration internally, and then not cleaned up afterwards.

In addition, Eng Swee’s results indicate that the script step uses a third header: functionName. I tried setting this header before a Script step, and the script engine does indeed try to execute a function, whose name matches the value of this header. This means that if you happen to have an unrelated header named functionName in your integration flow, any subsequent Script steps will very likely fail.

Interestingly, the functionName header is not returned to the caller. Eng Swee’s code snippet below shows how this particular header is actively removed.